docker pull oor 'n VPN: die daemon het sy eie netwerk

Jou skootrekenaar is op die korporatiewe VPN, curl bereik die interne registry, en docker pull sterf steeds met 'n EOF. Daardie kombinasie is nie 'n teenstrydigheid nie. Die opdrag wat jy getik het, loop in jou shell, maar die oordrag loop in watter daemon die Docker CLI ook al gekies het, en daardie daemon kan heel op 'n ander gasheer wees. Dit is sy netwerkpad wat moet werk, en dit is sy proxy-instellings wat geld.

Begin deur die enjin te identifiseer, nie die roete nie

Voer docker context show en docker version uit. Die weergawe-uitvoer druk 'n kliëntafdeling en 'n bedienerafdeling, en die bedienerblok vertel jou wat geantwoord het: 'n plaaslike inheemse enjin, die Docker Desktop virtuele masjien, of 'n daemon op 'n afgeleë masjien. docker context inspect sal die eindpunt van die gekose konteks wys as jy seker wil wees, en nie een van hierdie opdragte verander iets nie.

'n Omgewingsveranderlike soos DOCKER_HOST kan die CLI stilweg na 'n ander enjin wys as die een wat jy aanneem, wat die gewone verklaring is vir 'n skootrekenaar wat op die VPN blyk te wees terwyl die trekking elders heen gaan.

Die daemon het sy eie netwerkidentiteit

'n Afgeleë enjin het sy eie goedgekeurde pad na die private registry nodig. Om jou skootrekenaar se VPN-kliënt te koppel gee daardie skootrekenaar 'n roete; dit gee nie 'n daemon in 'n laboratorium of 'n wolksubnet dieselfde private adres nie. As die enjin Docker Desktop is, gebeur die trekking binne sy virtuele masjien, wat sy eie netwerk- en proxy-konfigurasie het wat apart is van jou shell se omgewing.

Dit is waarom 'n suksesvolle curl op die gasheer bewyse oor die gasheer is en niks meer nie.

Vind watter registry-uitruiling geëindig het

'n Beeldtrekking is 'n reeks: verifikasie, manifesverkryging, dan blob-oordragte wat dikwels na objekberging of 'n CDN-eindpunt herlei. 'n Suksesvolle docker login bewys net die eerste stap, en 'n teken kan heeltemal geldig wees terwyl die herleide blob-gasheer onbereikbaar is vanaf die daemon se netwerk. Let op die presiese tyd, die beeldverwysing en die eerste nuttige gebeurtenis uit die daemon- of kliëntlog voordat jy iets verander.

EOF op sigself noem geen oorsaak nie. Dit kan 'n afgekapte verbinding wees, 'n proxy wat die stroom laat val het, 'n tydsverloop, of 'n MTU-probleem, en om tussen hulle te raai sonder die tydgestempelde gebeurtenis is hoe mense 'n gesonde enjin herbou. Behandel die byte-offset in die kliëntuitvoer as data, want 'n oordrag wat elke keer by dieselfde grootte stop is 'n ander dier as een wat nooit begin nie. Teken albei uitkomste aan en vergelyk hulle oor pogings heen.

Konfigureer die komponent wat oordra

Vir 'n inheemse Linux-enjin hoort die proxy in die diensomgewing, nie in jou shell nie. 'n Drop-in-lêer onder /etc/systemd/system/docker.service.d/ met HTTP_PROXY, HTTPS_PROXY en NO_PROXY inskrywings, gevolg deur systemctl daemon-reload en 'n herbegin, is die gedokumenteerde reëling. Docker Desktop bied dieselfde waardes deur sy eie instellings, en die redigering van 'n shell-profiel raak nie een van hulle nie.

As die registry direk oor die VPN bereik moet word, het die daemon 'n resolver, 'n roete en 'n doelbewuste proxy-uitsluiting nodig eerder as net 'n uitsluiting. NO_PROXY-passing is 'n stringvergelyking per komponent, en 'n vrystelling sonder 'n onderliggende roete lewer 'n fout op wat soos 'n proxy-probleem lyk.

Wanneer ondernemings-TLS-inspeksie in die goedgekeurde pad sit, installeer sy geverifieerde wortel deur die enjin- of Desktop-werkvloei. Om die registry by insecure-registries te voeg is 'n ander verandering wat validering afskakel, en dit is nie 'n trust store-konfigurasie nie.

Herhaal een beheerde trekking en kyk wat verander het

Verander een grens, herbegin die komponent wat dit besit, en herhaal dieselfde trekking vanuit dieselfde konteks. Verifieer die resulterende beeldverwysing en digest eerder as die afwesigheid van 'n fout, want 'n gekaste laag kan maak dat 'n tweede poging veel minder van die pad oefen as wat die eerste een gedoen het. Hou die oordragte wat werklik plaasgevind het in die kaartjie, want hulle is die enigste rekord van wat die herpoging werklik getoets het.

Bou-stappe en lopende houers het hul eie netwerkkontekste, so behandel hulle as aparte vrae sodra die trekking self werk.