docker pull preko VPN-a: daemon ima vlastitu mrežu

Vaš laptop je na korporativnoj VPN mreži, curl doseže interni registry, a docker pull ipak pada s EOF. Ta kombinacija nije proturječje. Naredba koju ste upisali izvršava se u vašem shellu, ali prijenos se odvija u onom daemonu koji je Docker CLI odabrao, a taj daemon može biti na posve drugom hostu. Njegova mrežna putanja je ona koja mora raditi, a njegove proxy postavke su one koje se primjenjuju.

Počnite identifikacijom enginea, a ne rute

Pokrenite docker context show i docker version. Izlaz verzije ispisuje odjeljak klijenta i odjeljak servera, a blok servera vam kaže tko je odgovorio: lokalni nativni engine, virtualna mašina Docker Desktopa ili daemon na udaljenom stroju. docker context inspect će pokazati endpoint odabranog konteksta ako želite biti sigurni, i nijedna od ovih naredbi ništa ne mijenja.

Varijabla okruženja poput DOCKER_HOST može tiho usmjeriti CLI na drugi engine od onog koji pretpostavljate, što je uobičajeno objašnjenje za laptop koji izgleda kao da je na VPN-u dok pull putuje negdje drugdje.

Daemon ima vlastiti mrežni identitet

Udaljeni engine treba vlastitu odobrenu putanju do privatnog registryja. Povezivanje VPN klijenta na vašem laptopu daje tom laptopu rutu; ono ne daje daemonu koji sjedi u laboratoriju ili cloud podmreži istu privatnu adresu. Ako je engine Docker Desktop, pull se odvija unutar njegove virtualne mašine, koja ima vlastitu mrežnu i proxy konfiguraciju odvojenu od okruženja vašeg shella.

Zato je uspješan curl na hostu dokaz o hostu i ništa više.

Utvrdite koja je razmjena s registryjem završila

Pull slike je slijed: autentifikacija, dohvaćanje manifesta, zatim prijenosi blobova koji se često preusmjeravaju na object storage ili CDN endpoint. Uspješan docker login dokazuje samo prvi korak, a token može biti potpuno valjan dok je preusmjereni blob host nedostupan s daemonove mreže. Zabilježite točno vrijeme, referencu slike i prvi koristan događaj iz daemonovog ili klijentskog loga prije nego što bilo što promijenite.

EOF sam po sebi ne imenuje uzrok. To može biti prekinuta veza, proxy koji je ispustio tok, istek vremena ili problem s MTU-om, a nagađanje između njih bez događaja s vremenskom oznakom je način na koji ljudi obnavljaju zdrav engine. Tretirajte bajtni offset u izlazu klijenta kao podatak, jer prijenos koji se svaki put zaustavi na istoj veličini je posve druga životinja od onog koji nikad ne počne. Zabilježite oba ishoda i usporedite ih kroz pokušaje.

Konfigurirajte komponentu koja prenosi

Za nativni Linux engine proxy pripada okruženju servisa, ne vašem shellu. Drop-in datoteka pod /etc/systemd/system/docker.service.d/ s unosima HTTP_PROXY, HTTPS_PROXY i NO_PROXY, nakon koje slijede systemctl daemon-reload i restart, dokumentirani je raspored. Docker Desktop izlaže iste vrijednosti kroz vlastite postavke, a uređivanje shell profila ne dira nijednu od njih.

Ako registry treba dosezati izravno preko VPN-a, daemon treba resolver, rutu i namjerno izuzeće proxyja, a ne samo izuzeće. Podudaranje NO_PROXY usporedba je nizova po komponenti, a izuzeće bez temeljne rute proizvodi kvar koji izgleda kao problem s proxyjem.

Kad korporativna TLS inspekcija stoji na odobrenoj putanji, instalirajte njezin provjereni korijen kroz tijek rada enginea ili Desktopa. Dodavanje registryja u insecure-registries druga je promjena koja isključuje validaciju i nije konfiguracija trust storea.

Ponovite jedan kontrolirani pull i provjerite što se promijenilo

Promijenite jednu granicu, restartajte komponentu koja ju posjeduje i ponovite isti pull iz istog konteksta. Provjerite dobivenu referencu slike i digest, a ne odsutnost greške, jer keširani sloj može učiniti da drugi pokušaj prođe kroz mnogo manji dio putanje nego prvi. Zadržite u ticketu prijenose koji su se stvarno dogodili, jer su oni jedini zapis o tome što je ponovni pokušaj doista testirao.

Koraci gradnje i pokrenuti kontejneri imaju vlastite mrežne kontekste, pa ih tretirajte kao odvojena pitanja kad sam pull proradi.