docker pull prek VPN: daemon ima svoje omrežje

Vaš prenosnik je v podjetniškem VPN, curl doseže notranji registry, pa vendar docker pull še vedno odpove z EOF. Ta kombinacija ni protislovje. Ukaz, ki ste ga vnesli, se izvaja v vaši lupini, prenos pa poteka v tistem daemonu, ki ga je izbral Docker CLI, in ta daemon je lahko na povsem drugem gostitelju. Delovati mora prav njegova omrežna pot in veljajo prav njegove nastavitve proxyja.

Začnite z prepoznavanjem pogona, ne poti

Zaženite docker context show in docker version. Izhod različice natisne razdelek odjemalca in razdelek strežnika, blok strežnika pa vam pove, kaj je odgovorilo: lokalni izvorni pogon, navidezni stroj Docker Desktop ali daemon na oddaljenem stroju. docker context inspect bo pokazal končno točko izbranega konteksta, če želite biti prepričani, in noben od teh ukazov ne spremeni ničesar.

Okoljska spremenljivka, kot je DOCKER_HOST, lahko tiho usmeri CLI na drug pogon, kot ga predvidevate, in to je običajna razlaga za prenosnik, ki je videti v VPN, medtem ko vlečenje potuje drugam.

Daemon ima svojo omrežno identiteto

Oddaljeni pogon potrebuje svojo odobreno pot do zasebnega registryja. Povezava odjemalca VPN na prenosniku da temu prenosniku pot; daemonu v laboratoriju ali v oblaku podomrežju pa ne da istega zasebnega naslova. Če je pogon Docker Desktop, vlečenje poteka v njegovem navideznem stroju, ki ima svojo omrežno in proxy konfiguracijo, ločeno od okolja vaše lupine.

Zato je uspešen curl na gostitelju dokaz o gostitelju in nič več.

Ugotovite, katera izmenjava z registryjem se je končala

Vlečenje slike je zaporedje: preverjanje pristnosti, pridobitev manifesta in nato prenosi blobov, ki so pogosto preusmerjeni v shrambo objektov ali na končno točko CDN. Uspešen docker login dokazuje le prvi korak, žeton pa je lahko popolnoma veljaven, medtem ko je preusmerjeni gostitelj blobov nedosegljiv iz omrežja daemona. Preden karkoli spremenite, zabeležite točen čas, sklic na sliko in prvi koristen dogodek iz dnevnika daemona ali odjemalca.

EOF sam po sebi ne navaja vzroka. Lahko je prekinjena povezava, proxy, ki je spustil tok, potek časa ali težava z MTU, in ugibanje med njimi brez dogodka s časovnim žigom je pot, po kateri ljudje obnavljajo zdrav pogon. Bajtni odmik v izhodu odjemalca obravnavajte kot podatek, ker je prenos, ki se vsakič ustavi pri enaki velikosti, druga žival od tistega, ki se nikoli ne začne. Zabeležite oba izida in ju primerjajte med poskusi.

Konfigurirajte komponento, ki prenaša

Pri izvornem pogonu Linux proxy spada v okolje storitve, ne v vašo lupino. Datoteka drop-in pod /etc/systemd/system/docker.service.d/ z vnosi HTTP_PROXY, HTTPS_PROXY in NO_PROXY, ki ji sledita systemctl daemon-reload in ponovni zagon, je dokumentirana ureditev. Docker Desktop iste vrednosti izpostavlja prek svojih nastavitev, urejanje profila lupine pa se ne dotakne nobenega od obeh.

Če je treba registry doseči neposredno prek VPN, daemon potrebuje razreševalnik, pot in namerno izključitev proxyja, ne le izključitve. Ujemanje NO_PROXY je primerjava nizov za vsako komponento, izjema brez osnovne poti pa povzroči napako, ki je videti kot težava s proxyjem.

Ko je podjetniška preveritev TLS na odobreni poti, namestite njeno preverjeno korenino prek delovnega toka pogona ali Desktopa. Dodajanje registryja v insecure-registries je druga sprememba, ki izklopi preverjanje, in ni konfiguracija shrambe zaupanja.

Ponovite eno nadzorovano vlečenje in preverite, kaj se je spremenilo

Spremenite eno mejo, znova zaženite komponento, ki ji pripada, in ponovite isto vlečenje iz istega konteksta. Preverite dobljeni sklic na sliko in digest, ne odsotnosti napake, ker lahko predpomnjena plast povzroči, da drugi poskus prevozi veliko manjši del poti kot prvi. V zahtevku shranite prenose, ki so se resnično zgodili, saj so edini zapis o tem, kaj je ponovni poskus v resnici preizkusil.

Koraki gradnje in delujoči vsebniki imajo svoje omrežne kontekste, zato jih obravnavajte kot ločena vprašanja, ko samo vlečenje deluje.