docker pull printr-un VPN: daemonul are propria rețea

Laptopul tău este în VPN-ul corporativ, curl ajunge la registry-ul intern și totuși docker pull eșuează în continuare cu un EOF. Această combinație nu este o contradicție. Comanda pe care ai tastat-o rulează în shell-ul tău, dar transferul rulează în daemonul pe care CLI-ul Docker l-a selectat, iar acel daemon poate fi pe un cu totul alt host. Calea lui de rețea este cea care trebuie să funcționeze, iar setările lui de proxy sunt cele care se aplică.

Începe prin a identifica motorul, nu ruta

Rulează docker context show și docker version. Ieșirea versiunii tipărește o secțiune de client și o secțiune de server, iar blocul serverului îți spune cine a răspuns: un motor nativ local, mașina virtuală Docker Desktop sau un daemon pe o mașină la distanță. docker context inspect va afișa punctul final al contextului selectat dacă vrei să fii sigur, iar niciuna dintre aceste comenzi nu schimbă nimic.

O variabilă de mediu precum DOCKER_HOST poate direcționa în tăcere CLI-ul către alt motor decât cel pe care îl presupui, iar aceasta este explicația obișnuită pentru un laptop care pare să fie în VPN în timp ce descărcarea pleacă în altă parte.

Daemonul are propria identitate de rețea

Un motor la distanță are nevoie de propria cale aprobată către registry-ul privat. Conectarea clientului VPN al laptopului oferă o rută acelui laptop; nu oferă aceeași adresă privată unui daemon care stă într-un laborator sau într-o subrețea de cloud. Dacă motorul este Docker Desktop, descărcarea are loc în mașina lui virtuală, care are propria configurație de rețea și de proxy, separată de mediul shell-ului tău.

De aceea un curl reușit pe host este o dovadă despre host și nimic mai mult.

Află care schimb cu registry-ul s-a încheiat

Descărcarea unei imagini este o succesiune: autentificare, obținerea manifestului și apoi transferuri de blob care sunt adesea redirecționate către stocare de obiecte sau către un punct final CDN. Un docker login reușit dovedește doar primul pas, iar un token poate fi perfect valid în timp ce hostul de blob redirecționat este inaccesibil din rețeaua daemonului. Notează ora exactă, referința imaginii și primul eveniment util din jurnalul daemonului sau al clientului înainte de a schimba ceva.

EOF singur nu numește nicio cauză. Poate fi o conexiune trunchiată, un proxy care a scăpat fluxul, un timp de așteptare depășit sau o problemă de MTU, iar ghicitul între ele fără evenimentul cu marcă de timp este modul în care oamenii ajung să reconstruiască un motor sănătos. Tratează deplasarea de octeți din ieșirea clientului ca pe o dată, pentru că un transfer care se oprește mereu la aceeași dimensiune este alt animal decât unul care nu începe niciodată. Înregistrează ambele rezultate și compară-le între încercări.

Configurează componenta care transferă

Pentru un motor Linux nativ, proxy-ul aparține mediului serviciului, nu shell-ului tău. Un fișier drop-in sub /etc/systemd/system/docker.service.d/ cu intrări HTTP_PROXY, HTTPS_PROXY și NO_PROXY, urmat de systemctl daemon-reload și de o repornire, este aranjamentul documentat. Docker Desktop expune aceleași valori prin propriile setări, iar editarea unui profil de shell nu atinge niciuna dintre ele.

Dacă registry-ul trebuie atins direct prin VPN, daemonul are nevoie de un resolver, de o rută și de o excludere deliberată de proxy, nu doar de o excludere. Potrivirea NO_PROXY este o comparație de șiruri pentru fiecare componentă, iar o excepție fără rută subiacentă produce o defecțiune care arată ca o problemă de proxy.

Când inspecția TLS corporativă se află pe calea aprobată, instalează rădăcina ei verificată prin fluxul de lucru al motorului sau al Desktop. Adăugarea registry-ului la insecure-registries este o altă modificare care dezactivează validarea și nu este o configurare de magazin de încredere.

Repetă o descărcare controlată și verifică ce s-a schimbat

Schimbă o singură graniță, repornește componenta care o deține și repetă aceeași descărcare din același context. Verifică referința imaginii și digestul rezultate, nu absența unei erori, pentru că un strat din cache poate face ca a doua încercare să parcurgă mult mai puțin din cale decât prima. Păstrează în tichet transferurile care au avut loc cu adevărat, pentru că ele sunt singura înregistrare a ceea ce a testat de fapt reîncercarea.

Pașii de build și containerele care rulează au propriile contexte de rețea, așa că tratează-le ca întrebări separate odată ce descărcarea în sine funcționează.