docker pull över ett VPN: daemonen har sitt eget nätverk

Din laptop är på företagets VPN, curl når det interna registryt och ändå dör docker pull fortfarande med en EOF. Den kombinationen är ingen motsägelse. Kommandot du skrev körs i ditt skal, men överföringen körs i den daemon som Docker CLI har valt, och den daemonen kan ligga på en helt annan värd. Det är dess nätverksväg som måste fungera, och det är dess proxyinställningar som gäller.

Börja med att identifiera motorn, inte vägen

Kör docker context show och docker version. Versionsutskriften visar en klientdel och en serverdel, och serverblocket berättar vad som svarade: en lokal inbyggd motor, den virtuella maskinen i Docker Desktop eller en daemon på en fjärrmaskin. docker context inspect visar ändpunkten för den valda kontexten om du vill vara säker, och inget av dessa kommandon ändrar något.

En miljövariabel som DOCKER_HOST kan tyst peka CLI:t mot en annan motor än den du antar, och det är den vanliga förklaringen till en laptop som verkar vara på VPN:et medan pullen reser någon annanstans.

Daemonen har sin egen nätverksidentitet

En fjärrmotor behöver sin egen godkända väg till det privata registryt. Att ansluta laptopens VPN-klient ger den laptopen en väg; det ger inte en daemon i ett labb eller ett molnundernät samma privata adress. Om motorn är Docker Desktop sker pullen inuti dess virtuella maskin, som har sin egen nätverks- och proxykonfiguration, skild från miljön i ditt skal.

Därför är en lyckad curl på värden ett bevis om värden och inget mer.

Ta reda på vilket utbyte med registryt som tog slut

En image-pull är en sekvens: autentisering, hämtning av manifestet och sedan blob-överföringar som ofta omdirigeras till objektlagring eller en CDN-ändpunkt. En lyckad docker login bevisar bara det första steget, och en token kan vara helt giltig medan den omdirigerade blob-värden inte går att nå från daemonens nätverk. Anteckna den exakta tiden, image-referensen och den första användbara händelsen från daemonens eller klientens logg innan du ändrar något.

EOF ensamt anger ingen orsak. Det kan vara en avbruten anslutning, en proxy som tappade strömmen, en timeout eller ett MTU-problem, och att gissa mellan dem utan den tidsstämplade händelsen är hur folk till slut bygger om en frisk motor. Behandla byte-förskjutningen i klientutskriften som data, eftersom en överföring som stannar vid samma storlek varje gång är ett annat djur än en som aldrig börjar. Registrera båda utfallen och jämför dem mellan försök.

Konfigurera komponenten som överför

För en inbyggd Linux-motor hör proxyn hemma i tjänstens miljö, inte i ditt skal. En drop-in-fil under /etc/systemd/system/docker.service.d/ med HTTP_PROXY, HTTPS_PROXY och NO_PROXY-poster, följd av systemctl daemon-reload och en omstart, är den dokumenterade ordningen. Docker Desktop exponerar samma värden via sina egna inställningar, och att redigera en skalprofil rör ingen av dem.

Om registryt måste nås direkt över VPN:et behöver daemonen en resolver, en väg och ett medvetet proxy-undantag, inte bara ett undantag. NO_PROXY-matchning är en strängjämförelse per komponent, och ett undantag utan en underliggande väg ger ett fel som ser ut som ett proxyproblem.

När företagets TLS-inspektion ligger i den godkända vägen installerar du dess verifierade rot via arbetsflödet för motorn eller Desktop. Att lägga till registryt i insecure-registries är en annan ändring som stänger av valideringen, och det är inte en konfiguration av ett trust store.

Upprepa en kontrollerad pull och kontrollera vad som ändrades

Ändra en gräns, starta om komponenten som äger den och upprepa samma pull från samma kontext. Verifiera image-referensen och digesten som blir resultatet, inte frånvaron av ett fel, eftersom ett cachat lager kan göra att ett andra försök går igenom mycket mindre av vägen än det första. Behåll överföringarna som faktiskt skedde i ärendet, eftersom de är den enda registreringen av vad det nya försöket egentligen testade.

Byggsteg och körande containrar har sina egna nätverkskontexter, så behandla dem som separata frågor när själva pullen fungerar.