docker pull over en VPN: daemonen har sitt eget nettverk

Laptopen din er på bedrifts-VPN-en, curl når den interne registryen, og likevel dør docker pull fortsatt med en EOF. Denne kombinasjonen er ingen motsetning. Kommandoen du skrev, kjører i skallet ditt, men overføringen kjører i den daemonen Docker CLI har valgt, og den daemonen kan ligge på en helt annen vert. Det er dens nettverkssti som må virke, og det er dens proxyinnstillinger som gjelder.

Begynn med å identifisere motoren, ikke ruten

Kjør docker context show og docker version. Versjonsutskriften viser en klientdel og en serverdel, og serverblokken forteller deg hva som svarte: en lokal innebygd motor, den virtuelle maskinen til Docker Desktop, eller en daemon på en ekstern maskin. docker context inspect viser endepunktet til den valgte konteksten hvis du vil være sikker, og ingen av disse kommandoene endrer noe.

En miljøvariabel som DOCKER_HOST kan stille peke CLI-et mot en annen motor enn den du antar, og det er den vanlige forklaringen på en laptop som ser ut til å være på VPN-en mens pullen reiser et annet sted.

Daemonen har sin egen nettverksidentitet

En ekstern motor trenger sin egen godkjente sti til den private registryen. Å koble til VPN-klienten på laptopen gir den laptopen en rute; det gir ikke en daemon i et laboratorium eller et nettsky-under-nett den samme private adressen. Hvis motoren er Docker Desktop, skjer pullen inne i dens virtuelle maskin, som har sin egen nettverks- og proxykonfigurasjon atskilt fra miljøet i skallet ditt.

Derfor er en vellykket curl på verten et bevis om verten og ikke noe mer.

Finn ut hvilken registry-utveksling som tok slutt

En image-pull er en sekvens: autentisering, henting av manifestet, og deretter blob-overføringer som ofte omdirigeres til objektlagring eller et CDN-endepunkt. En vellykket docker login beviser bare det første trinnet, og et token kan være helt gyldig mens den omdirigerte blob-verten er utilgjengelig fra nettverket til daemonen. Noter det nøyaktige tidspunktet, image-referansen og den første nyttige hendelsen fra loggen til daemonen eller klienten før du endrer noe.

EOF alene navngir ingen årsak. Det kan være en avbrutt tilkobling, en proxy som slapp strømmen, en tidsavbrudd eller et MTU-problem, og å gjette mellom dem uten den tidsstemplede hendelsen er hvordan folk ender med å bygge en frisk motor på nytt. Behandle byte-forskyvningen i klientutskriften som data, fordi en overføring som stopper på samme størrelse hver gang er et annet dyr enn en som aldri starter. Registrer begge utfallene og sammenlign dem på tvers av forsøk.

Konfigurer komponenten som overfører

For en innebygd Linux-motor hører proxyen hjemme i tjenestemiljøet, ikke i skallet ditt. En drop-in-fil under /etc/systemd/system/docker.service.d/ med HTTP_PROXY, HTTPS_PROXY og NO_PROXY-oppføringer, etterfulgt av systemctl daemon-reload og en omstart, er den dokumenterte ordningen. Docker Desktop eksponerer de samme verdiene gjennom sine egne innstillinger, og redigering av en skallprofil berører ingen av dem.

Hvis registryen må nås direkte over VPN-en, trenger daemonen en resolver, en rute og en bevisst proxy-utelukkelse, ikke bare en utelukkelse. NO_PROXY-samsvar er en strengsammenligning per komponent, og et unntak uten en underliggende rute gir en feil som ser ut som et proxyproblem.

Når bedriftens TLS-inspeksjon ligger i den godkjente stien, installer dens verifiserte rot via arbeidsflyten til motoren eller Desktop. Å legge registryen til insecure-registries er en annen endring som slår av valideringen, og det er ikke en konfigurasjon av et tillitslager.

Gjenta en kontrollert pull og sjekk hva som endret seg

Endre én grense, start komponenten som eier den på nytt, og gjenta den samme pullen fra samme kontekst. Verifiser image-referansen og digesten som kommer ut, ikke fraværet av en feil, fordi et bufret lag kan gjøre at et nytt forsøk går gjennom langt mindre av stien enn det første. Ta vare på overføringene som faktisk skjedde i saken, siden de er den eneste registreringen av hva det nye forsøket egentlig testet.

Byggetrinn og kjørende beholdere har sine egne nettverkskontekster, så behandle dem som separate spørsmål når pullen selv virker.