docker pull przez VPN: daemon ma własną sieć

Twój laptop jest w firmowej sieci VPN, curl dociera do wewnętrznego registry, a mimo to docker pull nadal kończy się błędem EOF. Ta kombinacja nie jest sprzecznością. Wpisane polecenie działa w twojej powłoce, ale transfer odbywa się w tym daemonie, który wybrał Docker CLI, a ten daemon może być na zupełnie innym hoście. To jego ścieżka sieciowa musi działać i to jego ustawienia proxy obowiązują.

Zacznij od zidentyfikowania silnika, a nie trasy

Uruchom docker context show i docker version. Wynik wersji wypisuje sekcję klienta i sekcję serwera, a blok serwera mówi, co odpowiedziało: lokalny natywny silnik, maszyna wirtualna Docker Desktop albo daemon na zdalnej maszynie. docker context inspect pokaże punkt końcowy wybranego kontekstu, jeśli chcesz mieć pewność, i żadne z tych poleceń niczego nie zmienia.

Zmienna środowiskowa taka jak DOCKER_HOST może po cichu skierować CLI do innego silnika niż ten, który zakładasz, i to jest zwykłe wyjaśnienie laptopa, który wygląda na podłączony do VPN, podczas gdy pobieranie trafia gdzie indziej.

Daemon ma własną tożsamość sieciową

Zdalny silnik potrzebuje własnej zatwierdzonej ścieżki do prywatnego registry. Podłączenie klienta VPN laptopa daje temu laptopowi trasę; nie daje daemonowi w laboratorium ani w podsieci chmurowej tego samego prywatnego adresu. Jeśli silnikiem jest Docker Desktop, pobieranie odbywa się w jego maszynie wirtualnej, która ma własną konfigurację sieci i proxy, oddzielną od środowiska twojej powłoki.

Dlatego udany curl na hoście jest dowodem o hoście i niczym więcej.

Ustal, która wymiana z registry się zakończyła

Pobieranie obrazu to sekwencja: uwierzytelnianie, pobranie manifestu, a następnie transfery blobów, które często są przekierowywane do magazynu obiektów lub punktu końcowego CDN. Udany docker login dowodzi tylko pierwszego kroku, a token może być całkowicie ważny, gdy przekierowany host blobów jest nieosiągalny z sieci daemona. Przed zmianą czegokolwiek zapisz dokładny czas, referencję obrazu i pierwsze użyteczne zdarzenie z logu daemona lub klienta.

Sam EOF nie wskazuje żadnej przyczyny. Może to być przerwane połączenie, proxy, które porzuciło strumień, przekroczenie czasu lub problem z MTU, a zgadywanie między nimi bez zdarzenia ze znacznikiem czasu jest sposobem, w jaki ludzie kończą z przebudową zdrowego silnika. Traktuj przesunięcie bajtów w wyjściu klienta jako dane, bo transfer, który za każdym razem zatrzymuje się na tym samym rozmiarze, to inne zwierzę niż ten, który nigdy się nie zaczyna. Zapisz oba wyniki i porównaj je między próbami.

Skonfiguruj komponent, który wykonuje transfer

Dla natywnego silnika Linux proxy należy do środowiska usługi, a nie do twojej powłoki. Plik drop-in pod /etc/systemd/system/docker.service.d/ z wpisami HTTP_PROXY, HTTPS_PROXY i NO_PROXY, a po nim systemctl daemon-reload i restart, to udokumentowany układ. Docker Desktop udostępnia te same wartości przez własne ustawienia, a edycja profilu powłoki nie dotyka żadnego z nich.

Jeśli do registry trzeba dotrzeć bezpośrednio przez VPN, daemon potrzebuje resolvera, trasy i celowego wykluczenia proxy, a nie tylko wykluczenia. Dopasowanie NO_PROXY to porównanie ciągów dla każdego komponentu, a wyjątek bez leżącej u podstaw trasy daje awarię, która wygląda jak problem z proxy.

Gdy firmowa inspekcja TLS znajduje się na zatwierdzonej ścieżce, zainstaluj jej zweryfikowany korzeń przez przepływ pracy silnika lub Desktop. Dodanie registry do insecure-registries to inna zmiana, która wyłącza walidację, i nie jest to konfiguracja magazynu zaufania.

Powtórz jedno kontrolowane pobieranie i sprawdź, co się zmieniło

Zmień jedną granicę, uruchom ponownie komponent, który ją posiada, i powtórz to samo pobieranie z tego samego kontekstu. Sprawdź wynikową referencję obrazu i digest, a nie brak błędu, ponieważ warstwa w pamięci podręcznej może sprawić, że druga próba przejdzie znacznie mniejszą część ścieżki niż pierwsza. Zachowaj w zgłoszeniu transfery, które faktycznie miały miejsce, bo są jedynym zapisem tego, co powtórzenie naprawdę przetestowało.

Kroki budowania i działające kontenery mają własne konteksty sieciowe, więc traktuj je jako osobne pytania, gdy samo pobieranie już działa.