docker pull over en VPN: daemonen har sit eget netværk

Din bærbare computer er på virksomhedens VPN, curl når det interne registry, og alligevel dør docker pull med en EOF. Den kombination er ikke en modsætning. Den kommando, du skrev, kører i din shell, men overførslen kører i den daemon, som Docker CLI har valgt, og den daemon kan være på en helt anden vært. Det er dens netværkssti, der skal virke, og det er dens proxyindstillinger, der gælder.

Begynd med at identificere motoren, ikke ruten

Kør docker context show og docker version. Versionsoutputtet udskriver en klientdel og en serverdel, og serverblokken fortæller dig, hvad der svarede: en lokal indbygget motor, Docker Desktop-virtuelmaskinen eller en daemon på en fjern maskine. docker context inspect viser endepunktet for den valgte kontekst, hvis du vil være sikker, og ingen af disse kommandoer ændrer noget.

En miljøvariabel som DOCKER_HOST kan stille pege CLI'en mod en anden motor, end den du antager, hvilket er den sædvanlige forklaring på en bærbar computer, der ser ud til at være på VPN'en, mens pull'et rejser et andet sted hen.

Daemonen har sin egen netværksidentitet

En fjern motor har brug for sin egen godkendte sti til det private registry. At tilslutte din bærbare computers VPN-klient giver den bærbare computer en rute; det giver ikke en daemon i et laboratorium eller et cloud-undernet den samme private adresse. Hvis motoren er Docker Desktop, sker pull'et inde i dens virtuelle maskine, som har sin egen netværks- og proxykonfiguration, der er adskilt fra din shells miljø.

Derfor er et vellykket curl på værten et bevis om værten og intet mere.

Find ud af, hvilken registry-udveksling der sluttede

Et image-pull er en sekvens: autentificering, hentning af manifestet og derefter blob-overførsler, som ofte omdirigeres til objektlager eller et CDN-endepunkt. Et vellykket docker login beviser kun det første skridt, og et token kan være fuldstændig gyldigt, mens den omdirigerede blob-vært er utilgængelig fra daemonens netværk. Notér det præcise tidspunkt, image-referencen og den første brugbare hændelse fra daemonens eller klientens log, før du ændrer noget.

EOF alene angiver ingen årsag. Det kan være en afbrudt forbindelse, en proxy, der tabte strømmen, en timeout eller et MTU-problem, og at gætte mellem dem uden den tidsstemplede hændelse er, hvordan folk ender med at genopbygge en sund motor. Behandl byteforskydningen i klientoutputtet som data, fordi en overførsel, der stopper ved samme størrelse hver gang, er et andet dyr end en, der aldrig starter. Registrer begge udfald og sammenlign dem på tværs af forsøg.

Konfigurer den komponent, der overfører

For en indbygget Linux-motor hører proxyen til i tjenestemiljøet, ikke i din shell. En drop-in-fil under /etc/systemd/system/docker.service.d/ med HTTP_PROXY, HTTPS_PROXY og NO_PROXY-poster, efterfulgt af systemctl daemon-reload og en genstart, er den dokumenterede ordning. Docker Desktop eksponerer de samme værdier via sine egne indstillinger, og redigering af en shell-profil rører ikke nogen af dem.

Hvis registry'et skal nås direkte over VPN'en, har daemonen brug for en resolver, en rute og en bevidst proxy-udelukkelse snarere end en udelukkelse alene. NO_PROXY-matchning er en strengsammenligning pr. komponent, og en undtagelse uden en underliggende rute giver en fejl, der ligner et proxyproblem.

Når virksomhedens TLS-inspektion ligger i den godkendte sti, skal du installere dens verificerede rod via motorens eller Desktops arbejdsgang. At tilføje registry'et til insecure-registries er en anden ændring, der deaktiverer validering, og det er ikke en konfiguration af et certifikatlager.

Gentag et kontrolleret pull, og kontroller, hvad der ændrede sig

Ændr én grænse, genstart den komponent, der ejer den, og gentag det samme pull fra den samme kontekst. Verificér den resulterende image-referencen og digest i stedet for fraværet af en fejl, fordi et cachelagret lag kan få et andet forsøg til at gennemløbe langt mindre af stien, end det første gjorde. Gem de overførsler, der faktisk fandt sted, i sagen, da de er den eneste registrering af, hvad gentagelsen reelt testede.

Build-trin og kørende containere har deres egne netværkskontekster, så behandl dem som separate spørgsmål, når selve pull'et virker.