docker pull über ein VPN: Der Daemon hat sein eigenes Netzwerk

Ihr Laptop ist im Unternehmens-VPN, curl erreicht die interne Registry, und trotzdem stirbt docker pull mit einem EOF. Diese Kombination ist kein Widerspruch. Der Befehl, den Sie eingegeben haben, läuft in Ihrer Shell, aber die Übertragung läuft in dem Daemon, den die Docker CLI ausgewählt hat, und dieser Daemon kann auf einem ganz anderen Host liegen. Sein Netzwerkpfad ist der, der funktionieren muss, und seine Proxy-Einstellungen sind die, die gelten.

Beginnen Sie mit der Identifizierung der Engine, nicht der Route

Führen Sie docker context show und docker version aus. Die Versionsausgabe zeigt einen Client-Abschnitt und einen Server-Abschnitt, und der Server-Block sagt Ihnen, wer geantwortet hat: eine lokale native Engine, die virtuelle Maschine von Docker Desktop oder ein Daemon auf einem entfernten Rechner. docker context inspect zeigt den Endpunkt des ausgewählten Kontexts, wenn Sie sicher sein wollen, und keiner dieser Befehle ändert etwas.

Eine Umgebungsvariable wie DOCKER_HOST kann die CLI still auf eine andere Engine zeigen lassen als die, die Sie annehmen, was die übliche Erklärung für einen Laptop ist, der im VPN zu sein scheint, während der Pull woandershin läuft.

Der Daemon hat seine eigene Netzwerkidentität

Eine entfernte Engine braucht ihren eigenen genehmigten Pfad zur privaten Registry. Den VPN-Client Ihres Laptops zu verbinden gibt diesem Laptop eine Route; es gibt einem Daemon in einem Labor oder einem Cloud-Subnetz nicht dieselbe private Adresse. Ist die Engine Docker Desktop, findet der Pull in ihrer virtuellen Maschine statt, die ihre eigene Netzwerk- und Proxy-Konfiguration hat, getrennt von der Umgebung Ihrer Shell.

Deshalb ist ein erfolgreicher curl auf dem Host ein Beleg über den Host und nichts weiter.

Finden Sie heraus, welcher Registry-Austausch geendet hat

Ein Image-Pull ist eine Abfolge: Authentifizierung, Abruf des Manifests, dann Blob-Übertragungen, die oft auf Objektspeicher oder einen CDN-Endpunkt umgeleitet werden. Ein erfolgreiches docker login beweist nur den ersten Schritt, und ein Token kann völlig gültig sein, während der umgeleitete Blob-Host aus dem Netzwerk des Daemons nicht erreichbar ist. Notieren Sie die genaue Zeit, die Image-Referenz und das erste nützliche Ereignis aus dem Daemon- oder Client-Log, bevor Sie etwas ändern.

EOF allein nennt keine Ursache. Es kann eine abgebrochene Verbindung sein, ein Proxy, der den Strom verworfen hat, ein Timeout oder ein MTU-Problem, und das Raten zwischen ihnen ohne das zeitgestempelte Ereignis ist der Weg, auf dem Leute eine gesunde Engine neu aufbauen. Behandeln Sie den Byte-Offset in der Client-Ausgabe als Daten, denn eine Übertragung, die jedes Mal bei derselben Größe stoppt, ist ein anderes Tier als eine, die nie beginnt. Halten Sie beide Ergebnisse fest und vergleichen Sie sie über Versuche hinweg.

Konfigurieren Sie die Komponente, die überträgt

Bei einer nativen Linux-Engine gehört der Proxy in die Dienstumgebung, nicht in Ihre Shell. Eine Drop-in-Datei unter /etc/systemd/system/docker.service.d/ mit Einträgen für HTTP_PROXY, HTTPS_PROXY und NO_PROXY, gefolgt von systemctl daemon-reload und einem Neustart, ist die dokumentierte Anordnung. Docker Desktop stellt dieselben Werte über seine eigenen Einstellungen bereit, und das Bearbeiten eines Shell-Profils berührt keines von beiden.

Soll die Registry direkt über das VPN erreicht werden, braucht der Daemon einen Resolver, eine Route und einen bewussten Proxy-Ausschluss statt nur eines Ausschlusses. NO_PROXY-Abgleich ist ein Zeichenkettenvergleich pro Komponente, und eine Ausnahme ohne zugrunde liegende Route erzeugt einen Fehler, der wie ein Proxy-Problem aussieht.

Wenn die Unternehmens-TLS-Inspektion im genehmigten Pfad liegt, installieren Sie ihre geprüfte Wurzel über den Engine- oder Desktop-Workflow. Die Registry zu insecure-registries hinzuzufügen ist eine andere Änderung, die die Validierung abschaltet, und es ist keine Trust-Store-Konfiguration.

Wiederholen Sie einen kontrollierten Pull und prüfen Sie, was sich geändert hat

Ändern Sie eine Grenze, starten Sie die Komponente neu, der sie gehört, und wiederholen Sie denselben Pull aus demselben Kontext. Prüfen Sie die resultierende Image-Referenz und den Digest statt der Abwesenheit eines Fehlers, denn eine zwischengespeicherte Ebene kann einen zweiten Versuch weit weniger des Pfades durchlaufen lassen als den ersten. Halten Sie die Übertragungen, die tatsächlich stattgefunden haben, im Ticket fest, denn sie sind der einzige Nachweis dafür, was der erneute Versuch wirklich getestet hat.

Build-Schritte und laufende Container haben ihre eigenen Netzwerkkontexte, also behandeln Sie sie als getrennte Fragen, sobald der Pull selbst funktioniert.