docker pull cez VPN: daemon má vlastnú sieť

Váš notebook je v podnikovej sieti VPN, curl sa dostane do interného registry a napriek tomu docker pull stále padá na EOF. Táto kombinácia nie je rozpor. Príkaz, ktorý ste napísali, beží vo vašom shelli, ale prenos prebieha v tom daemone, ktorý si vybral Docker CLI, a ten daemon môže byť na úplne inom hoste. Pracovať musí práve jeho sieťová cesta a platia práve jeho nastavenia proxy.

Začnite identifikáciou enginu, nie trasy

Spustite docker context show a docker version. Výstup verzie vypíše sekciu klienta a sekciu servera a blok servera vám povie, kto odpovedal: lokálny natívny engine, virtuálny stroj Docker Desktop alebo daemon na vzdialenom počítači. docker context inspect ukáže koncový bod zvoleného kontextu, ak si chcete byť istí, a žiadny z týchto príkazov nič nemení.

Premenná prostredia ako DOCKER_HOST môže ticho nasmerovať CLI na iný engine, než aký predpokladáte, a to je zvyčajné vysvetlenie notebooku, ktorý vyzerá byť na VPN, kým pull putuje inam.

Daemon má vlastnú sieťovú identitu

Vzdialený engine potrebuje vlastnú schválenú cestu k privátnemu registry. Pripojenie VPN klienta na notebooku dáva tomuto notebooku trasu; nedáva daemonu v laboratóriu alebo cloudovej podsieti rovnakú privátnu adresu. Ak je enginom Docker Desktop, pull prebieha v jeho virtuálnom stroji, ktorý má vlastnú sieťovú konfiguráciu a konfiguráciu proxy oddelenú od prostredia vášho shellu.

Preto je úspešný curl na hoste dôkazom o hoste a ničím viac.

Zistite, ktorá výmena s registry sa skončila

Pull image je sled: autentifikácia, získanie manifestu a potom prenosy blobov, ktoré sa často presmerúvajú do objektového úložiska alebo na koncový bod CDN. Úspešný docker login dokazuje len prvý krok a token môže byť úplne platný, kým je presmerovaný blob host z daemonovej siete nedostupný. Pred akoukoľvek zmenou si poznačte presný čas, referenciu image a prvú užitočnú udalosť z logu daemona alebo klienta.

EOF samo o sebe neuvádza príčinu. Môže to byť prerušené spojenie, proxy, ktorá zahodila tok, vypršanie času alebo problém s MTU, a hádanie medzi nimi bez udalosti s časovou značkou je spôsob, akým ľudia prestavujú zdravý engine. Berte bajtový offset vo výstupe klienta ako dáta, pretože prenos, ktorý sa zakaždým zastaví na rovnakej veľkosti, je iné zviera ako ten, ktorý sa nikdy nezačne. Zaznamenajte oba výsledky a porovnajte ich medzi pokusmi.

Nakonfigurujte komponent, ktorý prenáša

Pre natívny Linux engine patrí proxy do prostredia služby, nie do vášho shellu. Drop-in súbor pod /etc/systemd/system/docker.service.d/ so záznamami HTTP_PROXY, HTTPS_PROXY a NO_PROXY, po ktorom nasleduje systemctl daemon-reload a reštart, je dokumentované usporiadanie. Docker Desktop vystavuje rovnaké hodnoty cez vlastné nastavenia a úprava profilu shellu neovplyvní ani jedno z nich.

Ak sa má registry dosahovať priamo cez VPN, daemon potrebuje resolver, trasu a zámerné vylúčenie proxy, nie len vylúčenie. Párovanie NO_PROXY je porovnávanie reťazcov pre každý komponent a výnimka bez podkladovej trasy vytvára zlyhanie, ktoré vyzerá ako problém s proxy.

Keď je podniková inšpekcia TLS na schválenej ceste, nainštalujte jej overený koreň cez pracovný postup enginu alebo Desktopu. Pridanie registry do insecure-registries je iná zmena, ktorá vypína validáciu, a nie je to konfigurácia úložiska dôvery.

Zopakujte jeden riadený pull a skontrolujte, čo sa zmenilo

Zmeňte jednu hranicu, reštartujte komponent, ktorý ju vlastní, a zopakujte ten istý pull z toho istého kontextu. Overte výslednú referenciu image a digest, nie neprítomnosť chyby, pretože kešovaná vrstva môže spôsobiť, že druhý pokus prejde oveľa menšiu časť cesty než prvý. Uchovajte v tikete prenosy, ktoré skutočne prebehli, pretože sú jediným záznamom o tom, čo opakovanie naozaj otestovalo.

Kroky zostavenia a bežiace kontajnery majú vlastné sieťové kontexty, takže ich berte ako samostatné otázky, keď samotný pull funguje.