docker pull přes VPN: daemon má vlastní síť

Váš notebook je v podnikové síti VPN, curl se dostane do interního registry, a přesto docker pull stále padá na EOF. Tahle kombinace není rozpor. Příkaz, který jste napsali, běží ve vašem shellu, ale přenos probíhá v tom daemonu, který si vybral Docker CLI, a ten daemon může být úplně na jiném hostu. Pracovat musí jeho síťová cesta a platí jeho nastavení proxy.

Začněte identifikací enginu, ne trasy

Spusťte docker context show a docker version. Výstup verze vypíše sekci klienta a sekci serveru a blok serveru vám řekne, kdo odpověděl: místní nativní engine, virtuální stroj Docker Desktop, nebo daemon na vzdáleném počítači. docker context inspect ukáže endpoint zvoleného kontextu, pokud si chcete být jistí, a žádný z těchto příkazů nic nemění.

Proměnná prostředí, jako je DOCKER_HOST, může tiše nasměrovat CLI na jiný engine, než jaký předpokládáte, což je obvyklé vysvětlení notebooku, který vypadá, že je na VPN, zatímco pull putuje jinam.

Daemon má vlastní síťovou identitu

Vzdálený engine potřebuje vlastní schválenou cestu k privátnímu registry. Připojení VPN klienta na notebooku dává tomuto notebooku trasu; nedává daemonu v laboratoři nebo cloudové podsíti stejnou privátní adresu. Pokud je enginem Docker Desktop, pull probíhá uvnitř jeho virtuálního stroje, který má vlastní síťovou konfiguraci a konfiguraci proxy oddělenou od prostředí vašeho shellu.

Proto je úspěšný curl na hostu důkazem o hostu a ničím víc.

Zjistěte, která výměna s registry skončila

Pull image je sled: autentizace, získání manifestu a pak přenosy blobů, které se často přesměrovávají do objektového úložiště nebo na endpoint CDN. Úspěšný docker login dokazuje jen první krok a token může být naprosto platný, zatímco přesměrovaný blob host je z daemonovy sítě nedostupný. Před jakoukoli změnou si poznamenejte přesný čas, referenci image a první užitečnou událost z logu daemonu nebo klienta.

EOF samo o sobě nepojmenuje příčinu. Může to být přerušené spojení, proxy, která zahodila proud, vypršení času nebo problém s MTU, a hádání mezi nimi bez události s časovým razítkem je způsob, jak lidé přestavují zdravý engine. Berte bajtový offset ve výstupu klienta jako data, protože přenos, který se pokaždé zastaví na stejné velikosti, je jiné zvíře než ten, který nikdy nezačne. Zaznamenejte oba výsledky a porovnejte je mezi pokusy.

Nakonfigurujte komponentu, která přenáší

Pro nativní Linux engine patří proxy do prostředí služby, ne do vašeho shellu. Drop-in soubor pod /etc/systemd/system/docker.service.d/ se záznamy HTTP_PROXY, HTTPS_PROXY a NO_PROXY, po němž následuje systemctl daemon-reload a restart, je dokumentované uspořádání. Docker Desktop vystavuje stejné hodnoty přes vlastní nastavení a úprava profilu shellu neovlivní ani jedno z nich.

Pokud se má registry dosahovat přímo přes VPN, daemon potřebuje resolver, trasu a záměrné vyloučení proxy, ne jen vyloučení. Párování NO_PROXY je porovnávání řetězců pro každou komponentu a výjimka bez podkladové trasy vytváří selhání, které vypadá jako problém s proxy.

Když je podniková inspekce TLS na schválené cestě, nainstalujte její ověřený kořenový certifikát přes workflow enginu nebo Desktopu. Přidání registry do insecure-registries je jiná změna, která vypíná validaci, a není to konfigurace úložiště důvěry.

Zopakujte jeden řízený pull a zkontrolujte, co se změnilo

Změňte jednu hranici, restartujte komponentu, která ji vlastní, a zopakujte stejný pull ze stejného kontextu. Ověřte výslednou referenci image a digest, ne nepřítomnost chyby, protože kešovaná vrstva může způsobit, že druhý pokus projde mnohem menší část cesty než první. Uchovejte v tiketu přenosy, které skutečně proběhly, protože jsou jediným záznamem o tom, co retry opravdu otestoval.

Kroky sestavení a běžící kontejnery mají vlastní síťové kontexty, takže je berte jako samostatné otázky, jakmile samotný pull funguje.