Montarea volumului Docker eșuează după conectarea VPN: verificați demonul

Aproape fiecare text despre această problemă dă vina pe volum, și exact de aceea remedierea durează atât de mult. Aveai un bind mount care funcționa, VPN-ul corporativ s-a conectat și docker compose up acum eșuează cu o cale sursă lipsă, un director gol sau o montare pe care motorul refuză să o creeze. În mediile pe care le-am curățat, fișierul Compose nu fusese modificat și calea era corectă. Ce s-a schimbat a fost care demon a primit cererea, iar eroarea de montare a fost doar primul loc unde această diferență a devenit vizibilă.

Volumul nu s-a mișcat niciodată; cererea s-a mișcat

Opțiunea -v /srv/app:/app nu este o copie de director făcută de shell-ul tău. Clientul o transformă într-o cerere API, iar demonul care răspunde rezolvă /srv/app față de propriul sistem de fișiere. Când ambele părți rulează pe același nucleu, acea cale este cea pe care o vezi în managerul de fișiere. Când endpoint-ul se schimbă, același șir este căutat pe o mașină care nu a auzit niciodată de directorul proiectului tău, iar demonul fie raportează sursa ca lipsă, fie creează în tăcere un director gol în locul ei.

Acesta este și motivul pentru care un volum numit continuă să funcționeze, în timp ce un bind mount nu. -v appdata:/app numește stocare pe care demonul o deține, așa că nicio cale de gazdă nu trebuie să existe într-un anumit loc. Dacă schimbarea unui serviciu dintr-un bind mount într-un volum numit face eroarea să dispară, nu ai rezolvat problema. Ai confirmat că clientul și demonul nu sunt de acord cu privire la sistemul de fișiere căruia îi aparține calea, iar acel dezacord revine în momentul în care ai din nou nevoie de un director real de gazdă.

Tipărește endpoint-ul înainte de a atinge montarea

Mai multe setări pot îndrepta clientul către un endpoint și nu sunt întotdeauna de acord: --context opțiunea, DOCKER_CONTEXT, DOCKER_HOST în shell-ul curent, și contextul salvat în configurația clientului. În loc să raționezi despre prioritate, tipărește-le pe toate și compară răspunsurile.

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

Configurația clientului se află în ~/.docker/config.json pe Linux și macOS și în %USERPROFILE%\.docker\config.json pe Windows, iar o valoare exportată în terminalul curent o înlocuiește pe cea salvată doar pentru acea sesiune. Dacă endpoint-ul este un nume de gazdă în loc de un socket local, rezolvarea numelor și rutele decid unde ajunge, și exact pe acelea le rescrie un client VPN. Un tunel care adaugă o rută sau schimbă resolverul poate trimite un nume care însemna cândva acest laptop către o adresă din interiorul rețelei corporative.

Compară starea, nu configurația. Rulează docker ps -a și docker images cu tunelul oprit, apoi din nou cu el pornit. O listă diferită de containere este o dovadă mai puternică decât orice fișier de configurare, pentru că arată că un alt demon a răspuns cererii tale.

Întreabă demonul dacă calea există acolo

Odată ce știi la ce demon ai ajuns, pune-l să se uite la director. --mount forma eșuează cu un mesaj mai clar decât opțiunea scurtă, pentru că validează sursa înainte de a porni containerul:

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

Dacă raportează sursa ca lipsă, creeaz-o pe mașina care a răspuns, sau îndreaptă serviciul către un volum numit și copiază datele acolo. Ce nu ar trebui să faci este să recreezi volume și să reinstalezi motorul înainte de această verificare. Acele acțiuni schimbă mediul suficient pentru a ascunde nepotrivirea, lăsând-o totuși pe loc.

Încă o cale rulează cu totul altundeva: descărcarea unei imagini este treaba demonului, nu a clientului. O descărcare reușită dovedește doar că demonul poate ajunge la un registry, iar un bind mount funcțional doar că o cale a fost rezolvată. Testează fiecare cale acolo unde se execută de fapt, altfel vei petrece o după-amiază cu cea greșită.

Numele de intranet eșuează dintr-un alt motiv

A doua jumătate a aceluiași raport este de obicei că containerul nu poate ajunge la intranet.corp.example. Acesta este un mecanism separat, nu o a doua problemă de volum. Un container primește /etc/resolv.conf la pornire, generat din setările resolverului demonului, așa că un server DNS pe care VPN-ul l-a adăugat după crearea containerului nu va apărea acolo până când containerul nu este recreat.

Resolverul încorporat al Docker pe o rețea definită de utilizator transmite interogările externe către serverele configurate ale gazdei, ceea ce ajută când VPN-ul rescrie resolverul gazdei și dăunează când DNS-ul divizat trimite o zonă internă către un server pe care demonul nu îl mai vede. O mapare îngustă și explicită ocolește discuția pentru nume care nu se schimbă niciodată:

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

Aceasta scrie o intrare în fișierul hosts al containerului, așa că containerul nu află niciodată nimic despre tunel, și îngheață și adresa. Când gazda internă se mută, intrarea rămâne greșită până când cineva editează fișierul Compose. Folosește-o pentru un dispozitiv fix sau o bază de date fixată, și lasă DNS-ul să gestioneze numele care se mișcă.

Ce schimbă de fapt o reinstalare

Reinstalarea Docker Desktop recreează VM-ul, socket-ul și lista de contexte, iar montarea începe să funcționeze din nou. Acel rezultat este real și nu te învață nimic, motiv pentru care aceeași defecțiune revine după următoarea actualizare VPN. Reinstalarea a înlocuit endpoint-ul pe care clientul îl folosea; nu a împăcat calea pe care o numește proiectul tău cu sistemul de fișiere pe care demonul îl citește de fapt.

Ordinea mea de lucru este scurtă. Confirmă ce endpoint va folosi clientul. Confirmă care demon a răspuns comparând listele de containere. Roagă acel demon să listeze calea sursă. Abia apoi editează montarea, adaugă o intrare hosts sau schimbă un tip de volum. Dacă întreții fișierul Compose pentru o echipă care lucrează prin VPN, preferă volumele numite pentru datele pe care demonul ar trebui să le dețină, ca o cale de gazdă să nu devină niciodată parte din contract.