docker pull VPN:n yli: daemonilla on oma verkko
Pull ajetaan daemonissa, ei shellissäsi. Tarkista konteksti, anna tuolle moottorille oma reitti tai proxy ja lue sitten, mikä registry-vaihto päättyi.
Kannettavasi on yrityksen VPN:ssä, curl tavoittaa sisäisen registryn, ja silti docker pull kuolee EOF-virheeseen. Tämä yhdistelmä ei ole ristiriita. Kirjoittamasi komento ajetaan shellissäsi, mutta siirto ajetaan siinä daemonissa, jonka Docker CLI on valinnut, ja se daemon voi olla aivan toisella isäntäkoneella. Sen verkkopolun on toimittava, ja sen proxy-asetukset ovat ne, jotka pätevät.
Aloita tunnistamalla moottori, ei reitti
Aja docker context show ja docker version. Version tuloste tulostaa asiakasosion ja palvelinosion, ja palvelinlohko kertoo, mikä vastasi: paikallinen natiivi moottori, Docker Desktopin virtuaalikone tai daemon etäkoneella. docker context inspect näyttää valitun kontekstin päätepisteen, jos haluat olla varma, eikä mikään näistä komennoista muuta mitään.
Ympäristömuuttuja kuten DOCKER_HOST voi hiljaa ohjata CLI:n toiseen moottoriin kuin oletat, mikä on tavallinen selitys kannettavalle, joka näyttää olevan VPN:ssä samalla kun pull matkaa muualle.
Daemonilla on oma verkkoidentiteettinsä
Etämoottori tarvitsee oman hyväksytyn polkunsa yksityiseen registryyn. Kannettavasi VPN-asiakasohjelman yhdistäminen antaa kyseiselle kannettavalle reitin; se ei anna laboratoriossa tai pilven aliverkossa olevalle daemonille samaa yksityistä osoitetta. Jos moottori on Docker Desktop, pull tapahtuu sen virtuaalikoneen sisällä, jolla on oma verkko- ja proxykokoonpanonsa erillään shellisi ympäristöstä.
Siksi onnistunut curl isäntäkoneella on todiste isäntäkoneesta eikä mistään muusta.
Selvitä, mikä registry-vaihto päättyi
Kuvan pull on sarja: todennus, manifestin nouto ja sitten blob-siirrot, jotka usein ohjataan objektivarastoon tai CDN-päätepisteeseen. Onnistunut docker login todistaa vain ensimmäisen vaiheen, ja token voi olla täysin kelvollinen samalla kun uudelleenohjattu blob-isäntä ei ole tavoitettavissa daemonin verkosta. Kirjaa tarkka aika, kuvan viite ja ensimmäinen hyödyllinen tapahtuma daemonin tai asiakkaan lokista ennen kuin muutat mitään.
EOF yksinään ei nimeä syytä. Se voi olla katkennut yhteys, virran pudottanut proxy, aikakatkaisu tai MTU-ongelma, ja näiden välillä arvaaminen ilman aikaleimattua tapahtumaa on se tapa, jolla ihmiset päätyvät rakentamaan terveen moottorin uudelleen. Käsittele asiakkaan tulosteen tavusiirtymää datana, sillä siirto, joka pysähtyy joka kerta samaan kokoon, on eri eläin kuin se, joka ei koskaan ala. Kirjaa molemmat tulokset ja vertaa niitä yritysten välillä.
Määritä komponentti, joka siirtää
Natiiville Linux-moottorille proxy kuuluu palveluympäristöön, ei shelliisi. Drop-in-tiedosto polun /etc/systemd/system/docker.service.d/ alla merkinnöillä HTTP_PROXY, HTTPS_PROXY ja NO_PROXY, jota seuraa systemctl daemon-reload ja uudelleenkäynnistys, on dokumentoitu järjestely. Docker Desktop tarjoaa samat arvot omien asetustensa kautta, eikä shell-profiilin muokkaaminen kosketa kumpaakaan.
Jos registryyn on päästävä suoraan VPN:n kautta, daemon tarvitsee resolverin, reitin ja tarkoituksellisen proxy-poissulkemisen, ei pelkkää poissulkemista. NO_PROXY-sovitus on merkkijonojen vertailu komponenteittain, ja poikkeus ilman taustalla olevaa reittiä tuottaa virheen, joka näyttää proxy-ongelmalta.
Kun yrityksen TLS-tarkastus on hyväksytyllä polulla, asenna sen vahvistettu juuri moottorin tai Desktopin työnkulun kautta. Registryn lisääminen insecure-registries-luetteloon on eri muutos, joka poistaa validoinnin käytöstä, eikä se ole luottamusvaraston kokoonpano.
Toista yksi hallittu pull ja tarkista, mikä muuttui
Muuta yhtä rajaa, käynnistä uudelleen komponentti, joka sen omistaa, ja toista sama pull samasta kontekstista. Vahvista tuloksena oleva kuvan viite ja digest, älä virheen puuttumista, sillä välimuistiin tallennettu kerros voi saada toisen yrityksen kulkemaan paljon pienemmän osan polusta kuin ensimmäinen. Pidä lipukkeessa ne siirrot, jotka todella tapahtuivat, sillä ne ovat ainoa kirjaus siitä, mitä uusintayritys todella testasi.
Build-vaiheilla ja käynnissä olevilla konttiilla on omat verkkokontekstinsa, joten kohtele niitä erillisinä kysymyksinä, kun itse pull toimii.