docker pull over eit VPN: daemonen har sitt eige nettverk

Laptopen din er på bedrifts-VPN-et, curl når den interne registryen, og likevel døyr docker pull framleis med ein EOF. Denne kombinasjonen er ingen motsetning. Kommandoen du skreiv, køyrer i skalet ditt, men overføringa køyrer i den daemonen Docker CLI har valt, og den daemonen kan liggje på ein heilt annan vert. Det er nettverksstien hans som må verke, og det er proxyinnstillingane hans som gjeld.

Byrja med å identifisere motoren, ikkje ruta

Køyr docker context show og docker version. Versjonsutskrifta viser ein klientdel og ein serverdel, og serverblokka fortel deg kva som svara: ein lokal innebygd motor, den virtuelle maskina til Docker Desktop, eller ein daemon på ein ekstern maskin. docker context inspect viser endepunktet til den valde konteksten dersom du vil vere sikker, og ingen av desse kommandoane endrar noko.

Ein miljøvariabel som DOCKER_HOST kan stille peike CLI-et mot ein annan motor enn den du føreset, og det er den vanlege forklaringa på ein laptop som ser ut til å vere på VPN-et medan pullen reiser ein annan stad.

Daemonen har sin eigen nettverksidentitet

Ein ekstern motor treng sin eigen godkjende sti til den private registryen. Å kople til VPN-klienten på laptopen gir den laptopen ei rute; det gir ikkje ein daemon i eit laboratorium eller eit nettsky-under-nett den same private adressa. Viss motoren er Docker Desktop, skjer pullen inne i den virtuelle maskina hans, som har sin eigen nettverks- og proxykonfigurasjon skild frå miljøet i skalet ditt.

Derfor er ein vellukka curl på verten eit bevis om verten og ikkje noko meir.

Finn ut kva registry-utveksling som tok slutt

Ein image-pull er ein sekvens: autentisering, henting av manifestet, og deretter blob-overføringar som ofte blir omdirigerte til objektlagring eller eit CDN-endepunkt. Ein vellukka docker login beviser berre det første trinnet, og eit token kan vere heilt gyldig medan den omdirigerte blob-verten er utilgjengeleg frå nettverket til daemonen. Noter det nøyaktige tidspunktet, image-referansen og den første nyttige hendinga frå loggen til daemonen eller klienten før du endrar noko.

EOF åleine nemner ingen årsak. Det kan vere ei avbroten tilkopling, ein proxy som sleppte straumen, eit tidsavbrot eller eit MTU-problem, og å gjette mellom dei utan den tidsstempla hendinga er korleis folk endar med å byggje ein frisk motor på nytt. Handsame byte-forskyvinga i klientutskrifta som data, fordi ei overføring som stoppar på same storleik kvar gong er eit anna dyr enn ei som aldri startar. Registrer båe utfalla og samanlikn dei på tvers av forsøk.

Konfigurer komponenten som overfører

For ein innebygd Linux-motor høyrer proxyen heime i tenestemiljøet, ikkje i skalet ditt. Ei drop-in-fil under /etc/systemd/system/docker.service.d/ med HTTP_PROXY, HTTPS_PROXY og NO_PROXY-oppføringar, etterfølgd av systemctl daemon-reload og ein omstart, er den dokumenterte ordninga. Docker Desktop eksponerer dei same verdiane gjennom sine eigne innstillingar, og redigering av ein skalprofil rører ingen av dei.

Viss registryen må ein nå direkte over VPN-et, treng daemonen ein resolver, ei rute og ei medviten proxy-utelukking, ikkje berre ei utelukking. NO_PROXY-samsvar er ein strengsamanlikning per komponent, og eit unntak utan ei underliggjande rute gir ein feil som ser ut som eit proxyproblem.

Når bedrifta si TLS-inspeksjon ligg i den godkjende stien, installer den verifiserte rota hans via arbeidsflyten til motoren eller Desktop. Å leggje registryen til insecure-registries er ei anna endring som slår av valideringa, og det er ikkje ein konfigurasjon av eit tillitslager.

Gjenta ein kontrollert pull og sjekk kva som endra seg

Endre éi grense, start komponenten som eig henne på nytt, og gjenta den same pullen frå same kontekst. Verifiser image-referansen og digesten som kjem ut, ikkje fråværet av ein feil, fordi eit bufra lag kan gjere at eit nytt forsøk går gjennom langt mindre av stien enn det første. Ta vare på overføringane som faktisk skjedde i saka, sidan dei er den einaste registreringa av kva det nye forsøket eigentleg testa.

Byggesteg og køyrande behaldarar har sine eigne nettverkskontekstar, så handsame dei som separate spørsmål når pullen sjølv verkar.