A Docker-kötet csatolása meghiúsul a VPN csatlakozása után: ellenőrizze a daemont

A probléma szinte minden leírása a kötetet hibáztatja, és éppen ezért tart ilyen sokáig a javítás. Volt egy működő bind mountja, a vállalati VPN csatlakozott, és docker compose up most hiányzó forrásútvonallal, üres könyvtárral vagy olyan csatolással hiúsul meg, amelyet a motor nem hajlandó létrehozni. Azokban a környezetekben, amelyeket rendbe tettem, a Compose-fájl nem változott, és az útvonal helyes volt. Az változott meg, hogy melyik daemon kapta a kérést, és a csatolási hiba csak az első hely volt, ahol ez a különbség láthatóvá vált.

A kötet soha nem mozdult el; a kérés mozdult el

A -v /srv/app:/app kapcsoló nem a shell által végzett könyvtármásolás. A kliens API-kéréssé alakítja, és a válaszoló daemon a saját fájlrendszeréhez képest oldja fel a /srv/app útvonalat. Ha mindkét oldal ugyanazon a kernelen fut, ez az az útvonal, amelyet a fájlkezelőben lát. Amikor az endpoint megváltozik, ugyanazt a karakterláncot egy olyan gépen keresi, amely soha nem hallott a projektkönyvtáráról, és a daemon vagy hiányzóként jelenti a forrást, vagy csendben létrehoz egy üres könyvtárat a helyén.

Ezért működik tovább a nevesített kötet, míg a bind mount nem. -v appdata:/app olyan tárolót nevez meg, amely a daemon tulajdonában van, így egyetlen gazdagép-útvonalnak sem kell léteznie egy adott helyen. Ha egy szolgáltatás bind mountról nevesített kötetre váltása eltünteti a hibát, nem javította ki a problémát. Megerősítette, hogy a kliens és a daemon nem ért egyet abban, melyik fájlrendszerhez tartozik az útvonal, és ez a nézeteltérés abban a pillanatban visszatér, amikor ismét valódi gazdagép-könyvtárra van szüksége.

Írja ki az endpointot, mielőtt hozzányúl a csatoláshoz

Több beállítás is egy endpointra irányíthatja a klienst, és ezek nem mindig értenek egyet: a --context kapcsoló, DOCKER_CONTEXT, DOCKER_HOST az aktuális shellben, valamint a klienskonfigurációban mentett kontextus. Ahelyett, hogy az elsőbbségről elmélkedne, írja ki mindet, és hasonlítsa össze a válaszokat.

docker context show
docker context ls
docker version
docker info --format "{{.Name}} {{.OperatingSystem}} {{.ServerVersion}}"

A klienskonfiguráció itt található: ~/.docker/config.json Linuxon és macOS-en, valamint itt: %USERPROFILE%\.docker\config.json Windowson, és az aktuális terminálban exportált érték csak arra a munkamenetre írja felül a mentettet. Ha az endpoint gazdagépnév helyi socket helyett, akkor a névfeloldás és az útvonalak döntik el, hol landol, és ezeket írja át pontosan egy VPN-kliens. Egy alagút, amely útvonalat ad hozzá vagy lecseréli a feloldót, elküldheti azt a nevet, amely korábban ezt a laptopot jelentette, a vállalati hálózaton belüli címre.

Állapotot hasonlítson, ne konfigurációt. Futtassa a docker ps -a és a docker images parancsot lezárt alagúttal, majd újra nyitottal. Egy eltérő konténerlista erősebb bizonyíték bármely konfigurációs fájlnál, mert megmutatja, hogy egy másik daemon válaszolt a kérésére.

Kérdezze meg a daemont, létezik-e ott az útvonal

Ha tudja, melyik daemonhoz ért el, nézesse meg vele a könyvtárat. A --mount forma világosabb üzenettel hiúsul meg, mint a rövid kapcsoló, mert a konténer indítása előtt ellenőrzi a forrást:

docker run --rm --mount type=bind,source=/srv/app,target=/app alpine ls -la /app

Ha hiányzóként jelenti a forrást, hozza létre azon a gépen, amely válaszolt, vagy irányítsa a szolgáltatást nevesített kötetre, és másolja át az adatokat. Amit nem szabad tennie, az a kötetek újralétrehozása és a motor újratelepítése ezen ellenőrzés előtt. Ezek a műveletek eléggé megváltoztatják a környezetet ahhoz, hogy elrejtsék az eltérést, miközben a helyén hagyják.

Egy további útvonal egészen máshol fut: az image lehúzása daemonmunka, nem kliensmunka. A sikeres lehúzás csak azt bizonyítja, hogy a daemon elér egy registryt, a működő bind mount pedig csak azt, hogy egy útvonal feloldódott. Minden útvonalat ott teszteljen, ahol valóban végrehajtódik, különben egy délutánt a rosszal tölt el.

Az intranetes nevek más okból hiúsulnak meg

Ugyanazon jelentés második fele általában az, hogy a konténer nem éri el a intranet.corp.examplecímet. Ez külön mechanizmus, nem második kötetprobléma. A konténer a /etc/resolv.conf fájlt indításkor kapja meg, a daemon feloldóbeállításaiból generálva, így a VPN által a konténer létrehozása után hozzáadott DNS-kiszolgáló nem jelenik meg benne, amíg a konténert újra nem hozzák létre.

A Docker beépített feloldója egy felhasználó által meghatározott hálózaton a külső lekérdezéseket a gazdagépen beállított kiszolgálókhoz továbbítja, ami segít, amikor a VPN átírja a gazdagép feloldóját, és árt, amikor a megosztott DNS egy belső zónát olyan kiszolgálóhoz küld, amelyet a daemon már nem lát. Egy szűk, explicit leképezés megkerüli a vitát azoknál a neveknél, amelyek soha nem változnak:

services:
  web:
    extra_hosts:
      - "intranet.corp.example:10.20.30.40"

Ez bejegyzést ír a konténer hosts fájljába, így a konténer semmit nem tud meg az alagútról, és a címet is befagyasztja. Amikor a belső gazdagép elmozdul, a bejegyzés hibás marad, amíg valaki nem szerkeszti a Compose-fájlt. Fix készülékhez vagy rögzített adatbázishoz használja, és hagyja, hogy a DNS kezelje a mozgó neveket.

Mit változtat valójában az újratelepítés

A Docker Desktop újratelepítése újralétrehozza a VM-et, a socketet és a kontextuslistát, és a csatolás újra működni kezd. Ez az eredmény valódi, és semmire nem tanít, ezért tér vissza ugyanaz a hiba a következő VPN-frissítés után. Az újratelepítés lecserélte azt az endpointot, amelyet a kliens használt; nem hangolta össze a projektje által megnevezett útvonalat azzal a fájlrendszerrel, amelyet a daemon valójában olvas.

A munkamenetem rövid. Erősítse meg, melyik endpointot fogja használni a kliens. Erősítse meg, melyik daemon válaszolt, a konténerlisták összehasonlításával. Kérje meg azt a daemont, hogy listázza a forrásútvonalat. Csak ezután szerkessze a csatolást, adjon hozzá hosts-bejegyzést, vagy változtasson kötettípust. Ha olyan csapat számára tartja karban a Compose-fájlt, amely VPN-en keresztül dolgozik, részesítse előnyben a nevesített köteteket azoknál az adatoknál, amelyek a daemon tulajdonában kell legyenek, hogy egy gazdagép-útvonal soha ne váljon a szerződés részévé.