docker pull tra VPN: la daemon havas sian propran reton

Via tekkomputilo estas en la entreprena VPN, curl atingas la internan registry, kaj tamen docker pull ankoraŭ fiaskas per EOF. Tiu kombino ne estas kontraŭdiro. La komando, kiun vi tajpis, ruliĝas en via shell, sed la transigo ruliĝas en tiu daemon, kiun la Docker CLI elektis, kaj tiu daemon povas esti sur tute alia gastiganto. Ĝia reta vojo estas tiu, kiu devas funkcii, kaj ĝiaj proxy-agordoj estas tiuj, kiuj validas.

Komencu per identigo de la motoro, ne de la vojo

Rulu docker context show kaj docker version. La versia eligo presas sekcion de kliento kaj sekcion de servilo, kaj la servila bloko diras al vi, kiu respondis: loka denaska motoro, la virtuala maŝino Docker Desktop, aŭ daemon sur fora maŝino. docker context inspect montros la finpunkton de la elektita kunteksto, se vi volas esti certa, kaj neniu el ĉi tiuj komandoj ŝanĝas ion.

Mediovariablo kiel DOCKER_HOST povas silente celi la CLI al alia motoro ol tiu, kiun vi supozas, kio estas la kutima klarigo por tekkomputilo, kiu ŝajnas esti en la VPN dum la tirĉerpo vojaĝas aliloken.

La daemon havas sian propran retan identecon

Fora motoro bezonas sian propran aprobitan vojon al la privata registry. Konekti la VPN-klienton de via tekkomputilo donas al tiu tekkomputilo vojon; ĝi ne donas al daemon sidanta en laboratorio aŭ nuba subreto la saman privatan adreson. Se la motoro estas Docker Desktop, la tirĉerpo okazas ene de ĝia virtuala maŝino, kiu havas sian propran retan kaj proxy-agordon aparte de la medio de via shell.

Tial sukcesa curl sur la gastiganto estas pruvo pri la gastiganto kaj nenio pli.

Trovu, kiu interŝanĝo kun la registry finiĝis

Tirĉerpo de bildo estas sinsekvo: aŭtentikigo, akiro de la manifesto, poste transigoj de blob, kiuj ofte alidirektiĝas al objekta stokado aŭ al finpunkto de CDN. Sukcesa docker login pruvas nur la unuan paŝon, kaj ĵetono povas esti tute valida dum la alidirektita blob-gastiganto estas neatingebla el la reto de la daemon. Notu la precizan tempon, la bildan referencon kaj la unuan utilan eventon el la protokolo de la daemon aŭ kliento antaŭ ol vi ŝanĝos ion.

EOF sola ne nomas kaŭzon. Ĝi povas esti tranĉita konekto, proxy, kiu faligis la fluon, tempolimo aŭ problemo pri MTU, kaj diveni inter ili sen la tempomarkita evento estas kiel homoj finas rekonstrui sanan motoron. Traktu la bajtan ofseton en la klienta eligo kiel datumon, ĉar transigo, kiu haltas ĉe la sama grandeco ĉiufoje, estas alia besto ol tiu, kiu neniam komenciĝas. Registru ambaŭ rezultojn kaj komparu ilin inter provoj.

Agordi la komponenton, kiu transigas

Por denaska Linux-motoro, la proxy apartenas al la serva medio, ne al via shell. Drop-in dosiero sub /etc/systemd/system/docker.service.d/ kun enskriboj HTTP_PROXY, HTTPS_PROXY kaj NO_PROXY, sekvata de systemctl daemon-reload kaj restartigo, estas la dokumentita aranĝo. Docker Desktop montras la samajn valorojn per siaj propraj agordoj, kaj redakti shell-profilo ne tuŝas iun ajn el ili.

Se la registry devas esti atingata rekte tra la VPN, la daemon bezonas solvilon, vojon kaj intencan proxy-eskludon, ne nur eskludon. Kongruigo de NO_PROXY estas ĉena komparo por ĉiu komponento, kaj escepto sen suba vojo produktas fiaskon, kiu aspektas kiel proxy-problemo.

Kiam entreprena TLS-inspektado staras sur la aprobita vojo, instalu ĝian kontrolitan radikon per la laborfluo de la motoro aŭ de Desktop. Aldoni la registry al insecure-registries estas alia ŝanĝo, kiu malŝaltas validigon, kaj ĝi ne estas agordo de fido-akumulo.

Ripetu unu kontrolitan tirĉerpon kaj kontrolu, kio ŝanĝiĝis

Ŝanĝu unu limon, restartigu la komponenton, kiu posedas ĝin, kaj ripetu la saman tirĉerpon el la sama kunteksto. Kontrolu la rezultan bildan referencon kaj digest, ne la foreston de eraro, ĉar kaŝmemorita tavolo povas igi duan provon trairi multe malpli da la vojo ol la unua. Konservu en la bileto la transigojn, kiuj efektive okazis, ĉar ili estas la sola registro pri tio, kion la ripeto vere testis.

Konstruaj paŝoj kaj rulantaj ujoj havas siajn proprajn retajn kuntekstojn, do traktu ilin kiel apartajn demandojn, kiam la tirĉerpo mem funkcias.