Docker-volummontering mislykkes etter at VPN kobler til: sjekk daemonen

Nesten hver beskrivelse av dette problemet gir volumet skylden, og det er nettopp derfor rettelsen tar så lang tid. Du hadde en bind-mount som virket, bedrifts-VPN-en koblet til, og docker compose up mislykkes nå med en manglende kildebane, en tom mappe eller en montering som motoren nekter å opprette. I miljøene jeg har ryddet opp i, var Compose-filen ikke endret og stien var riktig. Det som endret seg, var hvilken daemon som mottok forespørselen, og monteringsfeilen var bare det første stedet hvor denne forskjellen ble synlig.

Volumet flyttet seg aldri; forespørselen gjorde det

Et -v /srv/app:/app flagg er ikke en mappekopi som skallet ditt utfører. Klienten gjør det om til en API-forespørsel, og daemonen som svarer, løser opp /srv/app mot sitt eget filsystem. Når begge sider kjører på samme kjerne, er det den stien du ser i filbehandleren. Når endepunktet endres, slås den samme strengen opp på en maskin som aldri har hørt om prosjektmappen din, og daemonen rapporterer enten kilden som manglende eller oppretter stille en tom mappe i stedet.

Det er også derfor et navngitt volum fortsetter å virke mens en bind-mount ikke gjør det. -v appdata:/app navngir lagring som daemonen eier, så ingen vertssti trenger å finnes på et bestemt sted. Hvis det å bytte en tjeneste fra bind-mount til et navngitt volum får feilen til å forsvinne, har du ikke løst problemet. Du har bekreftet at klienten og daemonen er uenige om hvilket filsystem stien tilhører, og den uenigheten kommer tilbake i det øyeblikket du igjen trenger en ekte vertsmappe.

Skriv ut endepunktet før du rører monteringen

Flere innstillinger kan peke klienten mot et endepunkt, og de er ikke alltid enige: et --context flagg, DOCKER_CONTEXT, DOCKER_HOST i gjeldende skall, og konteksten som er lagret i klientkonfigurasjonen. I stedet for å resonnere om prioritet, skriv ut alle og sammenlign svarene.

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

Klientkonfigurasjonen ligger i ~/.docker/config.json på Linux og macOS og i %USERPROFILE%\.docker\config.json på Windows, og en verdi som eksporteres i gjeldende terminal overstyrer den lagrede bare for den økten. Hvis endepunktet er et vertsnavn i stedet for en lokal socket, avgjør navneoppslag og ruter hvor det lander, og det er nettopp det en VPN-klient skriver om. En tunnel som legger til en rute eller bytter ut resolvere, kan sende et navn som før betydde denne laptopen til en adresse inne i bedriftsnettet.

Sammenlign tilstand i stedet for konfigurasjon. Kjør docker ps -a og docker images med tunnelen nede, og deretter igjen med den oppe. En annen containerliste er sterkere bevis enn noen konfigurasjonsfil, fordi den viser at en annen daemon svarte på forespørselen din.

Spør daemonen om stien finnes der

Når du vet hvilken daemon du nådde, få den til å se på mappen. --mount formen mislykkes med en klarere melding enn det korte flagget, fordi den validerer kilden før den starter containeren:

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

Hvis den rapporterer kilden som manglende, opprett den på maskinen som svarte, eller pek tjenesten mot et navngitt volum og kopier dataene dit. Det du ikke bør gjøre, er å gjenopprette volumer og reinstalere motoren før denne sjekken. De handlingene endrer miljøet nok til å skjule avviket mens det blir stående.

Én sti til går helt andre steder: å hente et image er daemonarbeid, ikke klientarbeid. En vellykket henting beviser bare at daemonen kan nå et registry, og en fungerende bind-mount bare at en sti ble løst opp. Test hver sti der den faktisk utføres, ellers bruker du en ettermiddag på den gale.

Intranettnavn mislykkes av en annen grunn

Den andre halvdelen av samme rapport er vanligvis at containeren ikke når intranet.corp.example. Det er en separat mekanisme, ikke et andre volumproblem. En container får sin /etc/resolv.conf når den starter, generert fra daemonens resolver-innstillinger, så en DNS-server som VPN-en la til etter at containeren ble opprettet, vises ikke der før containeren gjenskapes.

Docker sin innebygde resolver på et brukerdefinert nettverk videresender eksterne oppslag til vertens konfigurerte servere, noe som hjelper når VPN-en skriver om vertens resolver og skader når delt DNS sender en intern sone til en server som daemonen ikke lenger ser. En smal, eksplisitt mapping omgår diskusjonen for navn som aldri endres:

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

Dette skriver en oppføring i containerens hosts-fil, så containeren lærer aldri noe om tunnelen, og det fryser også adressen. Når den interne verten flytter seg, blir oppføringen stående feil til noen redigerer Compose-filen. Bruk det for en fast enhet eller en fastlåst database, og la DNS håndtere navn som flytter seg.

Hva en reinstallasjon faktisk endrer

Reinstallasjon av Docker Desktop gjenskaper VM-en, socketen og kontekstlisten, og monteringen begynner å virke igjen. Det resultatet er ekte og lærer ingenting, og derfor kommer den samme feilen tilbake etter neste VPN-oppdatering. Reinstallasjonen erstattet endepunktet klienten brukte; den forlikte ikke stien prosjektet ditt navngir med filsystemet daemonen faktisk leser.

Arbeidsrekkefølgen min er kort. Bekreft hvilket endepunkt klienten vil bruke. Bekreft hvilken daemon som svarte ved å sammenligne containerlister. Be den daemonen liste kildebanen. Først da redigerer du monteringen, legger til en hosts-oppføring eller endrer en volumtype. Hvis du vedlikeholder Compose-filen for et team som jobber over VPN, foretrekk navngitte volumer for data daemonen bør eie, slik at en vertssti aldri blir en del av kontrakten.