docker pull via een VPN: de daemon heeft zijn eigen netwerk

Je laptop zit op het bedrijfs-VPN, curl bereikt de interne registry, en toch sterft docker pull nog steeds met een EOF. Die combinatie is geen tegenspraak. De opdracht die je typte draait in je shell, maar de overdracht draait in de daemon die de Docker CLI heeft gekozen, en die daemon kan op een heel andere host staan. Het is zijn netwerkpad dat moet werken, en het zijn zijn proxy-instellingen die gelden.

Begin met het identificeren van de engine, niet de route

Voer docker context show en docker version uit. De versie-uitvoer toont een clientgedeelte en een servergedeelte, en het serverblok vertelt je wat er antwoordde: een lokale native engine, de virtuele machine van Docker Desktop, of een daemon op een externe machine. docker context inspect toont het eindpunt van de geselecteerde context als je zeker wilt zijn, en geen van deze opdrachten verandert iets.

Een omgevingsvariabele zoals DOCKER_HOST kan de CLI stilzwijgend naar een andere engine wijzen dan degene die je aanneemt, en dat is de gebruikelijke verklaring voor een laptop die op het VPN lijkt te zitten terwijl de pull ergens anders heen gaat.

De daemon heeft zijn eigen netwerkidentiteit

Een externe engine heeft zijn eigen goedgekeurde pad naar de private registry nodig. De VPN-client van je laptop verbinden geeft die laptop een route; het geeft een daemon in een lab of een cloud-subnet niet hetzelfde private adres. Als de engine Docker Desktop is, gebeurt de pull in zijn virtuele machine, die zijn eigen netwerk- en proxyconfiguratie heeft, gescheiden van de omgeving van je shell.

Daarom is een geslaagde curl op de host een bewijs over de host en niets meer.

Zoek uit welke uitwisseling met de registry is geëindigd

Een image-pull is een reeks: authenticatie, ophalen van het manifest en dan blob-overdrachten die vaak worden omgeleid naar objectopslag of een CDN-eindpunt. Een geslaagde docker login bewijst alleen de eerste stap, en een token kan volledig geldig zijn terwijl de omgeleide blob-host onbereikbaar is vanaf het netwerk van de daemon. Noteer de exacte tijd, de image-referentie en de eerste nuttige gebeurtenis uit de log van de daemon of de client voordat je iets verandert.

EOF alleen noemt geen oorzaak. Het kan een afgebroken verbinding zijn, een proxy die de stream liet vallen, een time-out of een MTU-probleem, en gissen tussen die mogelijkheden zonder de getimede gebeurtenis is hoe mensen een gezonde engine opnieuw bouwen. Behandel de byte-offset in de clientuitvoer als data, want een overdracht die elke keer bij dezelfde grootte stopt is een ander dier dan een die nooit begint. Leg beide uitkomsten vast en vergelijk ze tussen pogingen.

Configureer het onderdeel dat overdraagt

Voor een native Linux-engine hoort de proxy in de serviceomgeving, niet in je shell. Een drop-in-bestand onder /etc/systemd/system/docker.service.d/ met vermeldingen voor HTTP_PROXY, HTTPS_PROXY en NO_PROXY, gevolgd door systemctl daemon-reload en een herstart, is de gedocumenteerde opzet. Docker Desktop biedt dezelfde waarden via zijn eigen instellingen, en het bewerken van een shell-profiel raakt geen van beide.

Als de registry rechtstreeks via het VPN moet worden bereikt, heeft de daemon een resolver, een route en een bewuste proxy-uitsluiting nodig, niet alleen een uitsluiting. NO_PROXY-overeenkomst is een tekenreeksvergelijking per onderdeel, en een uitzondering zonder onderliggende route levert een fout op die op een proxyprobleem lijkt.

Wanneer bedrijfs-TLS-inspectie in het goedgekeurde pad zit, installeer dan de geverifieerde root ervan via de workflow van de engine of Desktop. De registry toevoegen aan insecure-registries is een andere wijziging die de validatie uitschakelt, en het is geen configuratie van een truststore.

Herhaal één gecontroleerde pull en controleer wat er is veranderd

Wijzig één grens, herstart het onderdeel dat die grens bezit, en herhaal dezelfde pull vanuit dezelfde context. Controleer de resulterende image-referentie en digest in plaats van de afwezigheid van een fout, want een gecachte laag kan ervoor zorgen dat een tweede poging veel minder van het pad doorloopt dan de eerste. Bewaar de overdrachten die daadwerkelijk hebben plaatsgevonden in de ticket, want die zijn het enige verslag van wat de nieuwe poging echt heeft getest.

Buildstappen en draaiende containers hebben hun eigen netwerkcontexten, dus behandel ze als aparte vragen zodra de pull zelf werkt.