Docker-volummontering mislukkast etter at VPN koplar til: sjekk daemonen

Nesten kvar skildring av dette problemet gir volumet skulda, og det er nettopp derfor rettinga tek så lang tid. Du hadde ei bind-montering som virka, bedrifts-VPN-en kopla til, og docker compose up mislukkast no med ein manglande kjeldebane, ei tom mappe eller ei montering som motoren nektar å lage. I miljøa eg har rydda opp i, var Compose-fila ikkje endra og stien var riktig. Det som endra seg, var kva daemon som fekk førespurnaden, og monteringsfeilen var berre den første staden der denne skilnaden vart synleg.

Volumet flytta seg aldri; førespurnaden gjorde det

Eit -v /srv/app:/app flagg er ikkje ein mappekopi som skalet ditt utfører. Klienten gjer det om til ein API-førespurnad, og daemonen som svarar, løyser opp /srv/app mot sitt eige filsystem. Når begge sider køyrer på same kjerne, er det den stien du ser i filhandsamaren. Når endepunktet endrar seg, blir den same strengen slått opp på ei maskin som aldri har høyrt om prosjektmappa di, og daemonen rapporterer anten kjelda som manglande eller lagar stille ei tom mappe i staden.

Det er også derfor eit namngjeve volum held fram med å verke medan ei bind-montering ikkje gjer det. -v appdata:/app namngjev lagring som daemonen eig, så ingen vertssti treng å finnast på ein bestemt stad. Viss det å bytte ein teneste frå bind-montering til eit namngjeve volum får feilen til å forsvinne, har du ikkje løyst problemet. Du har stadfesta at klienten og daemonen er usamde om kva filsystem stien høyrer til, og den usemja kjem tilbake i det augneblinken du igjen treng ei ekte vertsmappe.

Skriv ut endepunktet før du rører monteringa

Fleire innstillingar kan peike klienten mot eit endepunkt, og dei er ikkje alltid samde: eit --context flagg, DOCKER_CONTEXT, DOCKER_HOST i gjeldande skjel, og konteksten som er lagra i klientkonfigurasjonen. I staden for å resonnere om prioritet, skriv ut alle og samanlikn svara.

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

Klientkonfigurasjonen ligg i ~/.docker/config.json på Linux og macOS og i %USERPROFILE%\.docker\config.json på Windows, og ein verdi som blir eksportert i gjeldande terminal overstyrer den lagra berre for den økta. Viss endepunktet er eit vertsnamn i staden for ein lokal socket, avgjer namneoppslag og ruter kvar det landar, og det er nettopp det ein VPN-klient skriv om. Ein tunnel som legg til ei rute eller byter ut resolvaren, kan sende eit namn som før tydde denne laptopen til ei adresse inne i bedriftsnettet.

Samanlikn tilstand i staden for konfigurasjon. Køyr docker ps -a og docker images med tunnelen nede, og deretter igjen med han oppe. Ei anna containerliste er sterkare prov enn kva konfigurasjonsfil som helst, fordi ho viser at ein annan daemon svara på førespurnaden din.

Spør daemonen om stien finst der

Når du veit kva daemon du nådde, få han til å sjå på mappa. --mount forma mislukkast med ei klarare melding enn det korte flagget, fordi ho validerer kjelda før ho startar containeren:

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

Viss han rapporterer kjelda som manglande, lag henne på maskina som svara, eller peik tenesta mot eit namngjeve volum og kopier dataa dit. Det du ikkje bør gjere, er å gjenopprette volum og reinstalere motoren før denne sjekken. Dei handlingane endrar miljøet nok til å skjule avviket medan det blir ståande.

Éin sti til går heilt andre stader: å hente eit image er daemonarbeid, ikkje klientarbeid. Ei vellukka henting provar berre at daemonen kan nå eit registry, og ei fungerande bind-montering berre at ein sti vart løyst opp. Test kvar sti der han faktisk blir utført, elles brukar du ein ettermiddag på den gale.

Intranettnamn mislukkast av ein annan grunn

Den andre halvdelen av same rapporten er vanlegvis at containeren ikkje når intranet.corp.example. Det er ein separat mekanisme, ikkje eit andre volumproblem. Ein container får sin /etc/resolv.conf når han startar, generert frå resolver-innstillingane til daemonen, så ein DNS-server som VPN-en la til etter at containeren vart laga, viser seg ikkje der før containeren blir gjenskapt.

Den innebygde resolvaren til Docker på eit brukardefinert nettverk sender eksterne oppslag vidare til dei konfigurerte tenarane til verten, noko som hjelper når VPN-en skriv om resolvaren til verten og skadar når delt DNS sender ei intern sone til ein tenar som daemonen ikkje lenger ser. Ein smal, eksplisitt mapping omgår diskusjonen for namn som aldri endrar seg:

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

Dette skriv ein oppføring i hosts-fila til containeren, så containeren lærer aldri noko om tunnelen, og det frys også adressa. Når den interne verten flyttar seg, blir oppføringa ståande feil til nokon redigerer Compose-fila. Bruk det for ein fast eining eller ein fastlåst database, og la DNS handsame namn som flyttar seg.

Kva ein reinstallasjon faktisk endrar

Reinstallasjon av Docker Desktop gjenopprettar VM-en, socketen og kontekstlista, og monteringa byrjar å verke igjen. Det resultatet er ekte og lærer ingenting, og derfor kjem den same feilen tilbake etter neste VPN-oppdatering. Reinstallasjonen erstatta endepunktet klienten brukte; han forlikte ikkje stien prosjektet ditt namngjev med filsystemet daemonen faktisk les.

Arbeidsrekkjefølgja mi er kort. Stadfest kva endepunkt klienten vil bruke. Stadfest kva daemon som svara ved å samanlikne containerlister. Be den daemonen liste kjeldebanen. Først då redigerer du monteringa, legg til ei hosts-oppføring eller endrar ein volumtype. Viss du vedlikeheld Compose-fila for eit team som jobbar over VPN, føretrekk namngjevne volum for data daemonen bør eige, slik at ein vertssti aldri blir ein del av kontrakten.