docker pull caur VPN: daemonam ir savs tīkls

Jūsu portatīvais dators ir uzņēmuma VPN, curl sasniedz iekšējo registry, un tomēr docker pull joprojām cieš neveiksmi ar EOF. Šī kombinācija nav pretruna. Ievadītā komanda darbojas jūsu shell, bet pārsūtīšana notiek tajā daemon, kuru izvēlējās Docker CLI, un tas daemon var atrasties pavisam citā hostā. Tieši tā tīkla ceļam ir jādarbojas, un tieši tā proxy iestatījumi ir spēkā.

Sāciet ar dzinēja, nevis maršruta noteikšanu

Palaidiet docker context show un docker version. Versijas izvade izdrukā klienta sadaļu un servera sadaļu, un servera bloks pasaka, kas atbildēja: vietējais native dzinējs, Docker Desktop virtuālā mašīna vai daemon attālinātā mašīnā. docker context inspect parādīs izvēlētā konteksta galapunktu, ja vēlaties pārliecināties, un neviena no šīm komandām neko nemaina.

Tāds vides mainīgais kā DOCKER_HOST var klusi novirzīt CLI uz citu dzinēju, nekā jūs pieņemat, un tas ir ierastais skaidrojums, kāpēc portatīvais dators šķiet esam VPN, kamēr pull dodas citur.

Daemon ir sava tīkla identitāte

Attālinātam dzinējam vajadzīgs savs apstiprināts ceļš uz privāto registry. Portatīvā datora VPN klienta pievienošana dod šim datoram maršrutu; tas nedod laboratorijā vai mākoņa apakštīklā esošajam daemon to pašu privāto adresi. Ja dzinējs ir Docker Desktop, pull notiek tā virtuālajā mašīnā, kurai ir sava tīkla un proxy konfigurācija, kas atšķiras no jūsu shell vides.

Tāpēc veiksmīgs curl uz hosta ir pierādījums par hostu un nekas vairāk.

Noskaidrojiet, kura apmaiņa ar registry beidzās

Image pull ir secība: autentifikācija, manifest iegūšana, pēc tam blob pārsūtīšana, kas bieži tiek novirzīta uz objektu krātuvi vai CDN galapunktu. Veiksmīgs docker login pierāda tikai pirmo soli, un token var būt pilnīgi derīgs, kamēr novirzītais blob hosts nav sasniedzams no daemon tīkla. Pirms kaut ko mainīt pierakstiet precīzu laiku, image atsauci un pirmo noderīgo notikumu no daemon vai klienta žurnāla.

EOF vien pats nenosauc nevienu cēloni. Tas var būt pārtraukts savienojums, plūsmu nometis proxy, taimauts vai MTU problēma, un minēšana starp tiem bez notikuma ar laika zīmi ir veids, kā cilvēki pārbūvē veselīgu dzinēju. Uztveriet baitu nobīdi klienta izvadē kā datus, jo pārsūtīšana, kas katru reizi apstājas pie tā paša izmēra, ir pavisam cits zvērs nekā tā, kas nekad nesākas. Pierakstiet abus rezultātus un salīdziniet tos starp mēģinājumiem.

Konfigurējiet komponentu, kas pārsūta

Native Linux dzinējam proxy pieder servisa videi, nevis jūsu shell. Drop-in fails zem /etc/systemd/system/docker.service.d/ ar HTTP_PROXY, HTTPS_PROXY un NO_PROXY ierakstiem, kam seko systemctl daemon-reload un restartēšana, ir dokumentētais izkārtojums. Docker Desktop nodrošina tās pašas vērtības ar saviem iestatījumiem, un shell profila rediģēšana neaizskar nevienu no tiem.

Ja registry jāsasniedz tieši pa VPN, daemon vajag resolver, maršrutu un apzinātu proxy izslēgšanu, nevis tikai izslēgšanu. NO_PROXY atbilstība ir virkņu salīdzināšana katram komponentam, un izņēmums bez pamatā esoša maršruta rada kļūdu, kas izskatās kā proxy problēma.

Kad uzņēmuma TLS pārbaude atrodas apstiprinātajā ceļā, instalējiet tās pārbaudīto sakni, izmantojot dzinēja vai Desktop darbplūsmu. Registry pievienošana insecure-registries ir cita izmaiņa, kas izslēdz validāciju, un tā nav uzticības krātuves konfigurācija.

Atkārtojiet vienu kontrolētu pull un pārbaudiet, kas mainījās

Mainiet vienu robežu, restartējiet komponentu, kuram tā pieder, un atkārtojiet to pašu pull no tā paša konteksta. Pārbaudiet iegūto image atsauci un digest, nevis kļūdas neesamību, jo kešatmiņā saglabātais slānis var likt otrajam mēģinājumam veikt daudz mazāku ceļa daļu nekā pirmajam. Saglabājiet biļetē tos pārsūtīšanas gadījumus, kas tiešām notika, jo tie ir vienīgais ieraksts par to, ko atkārtojums patiešām pārbaudīja.

Build soļiem un darbojošiem konteineriem ir savi tīkla konteksti, tāpēc uzskatiet tos par atsevišķiem jautājumiem, kad pats pull darbojas.