docker pull per VPN: daemon turi savo tinklą
Pull vykdomas daemone, o ne jūsų shell. Patikrinkite kontekstą, suteikite tam varikliui savo maršrutą arba proxy, tada perskaitykite, kuri registry mainų dalis baigėsi.
Jūsų nešiojamas kompiuteris yra įmonės VPN, curl pasiekia vidinį registry, o docker pull vis tiek žlunga su EOF. Šis derinys nėra prieštaravimas. Įvesta komanda vykdoma jūsų shell, bet perdavimas vykdomas tame daemon, kurį pasirinko Docker CLI, ir tas daemon gali būti visai kitame hoste. Būtent jo tinklo kelias turi veikti, ir būtent jo proxy nustatymai galioja.
Pradėkite nuo variklio, o ne maršruto nustatymo
Paleiskite docker context show ir docker version. Versijos išvestis išspausdina kliento sekciją ir serverio sekciją, o serverio blokas pasako, kas atsakė: vietinis natūralus variklis, Docker Desktop virtualioji mašina arba daemon nuotolinėje mašinoje. docker context inspect parodys pasirinkto konteksto galinį tašką, jei norite būti tikri, ir nė viena iš šių komandų nieko nekeičia.
Tokia aplinkos kintamoji kaip DOCKER_HOST gali tyliai nukreipti CLI į kitą variklį, nei jūs manote, ir tai yra įprastas paaiškinimas, kodėl nešiojamas kompiuteris atrodo esąs VPN, o pull keliauja kitur.
Daemon turi savo tinklo tapatybę
Nuotoliniam varikliui reikia savo patvirtinto kelio į privatų registry. Prisijungus nešiojamojo kompiuterio VPN klientą, tas kompiuteris gauna maršrutą; tai nesuteikia laboratorijoje ar debesijos posegmenyje esančiam daemon to paties privataus adreso. Jei variklis yra Docker Desktop, pull vyksta jo virtualiojoje mašinoje, kuri turi savo tinklo ir proxy konfigūraciją, atskirą nuo jūsų shell aplinkos.
Todėl sėkmingas curl hoste yra įrodymas apie hostą ir nieko daugiau.
Išsiaiškinkite, kuri registry mainų dalis baigėsi
Image pull yra seka: autentifikavimas, manifest gavimas, tada blob perdavimai, kurie dažnai nukreipiami į objektų saugyklą ar CDN galinį tašką. Sėkmingas docker login įrodo tik pirmą žingsnį, o token gali būti visiškai galiojantis, kol nukreiptas blob hostas nepasiekiamas iš daemon tinklo. Prieš ką nors keisdami užsirašykite tikslų laiką, image nuorodą ir pirmą naudingą įvykį iš daemon ar kliento žurnalo.
EOF vienas pats neįvardija jokios priežasties. Tai gali būti nutrauktas ryšys, srautą numetęs proxy, laiko limitas ar MTU problema, o spėliojimas tarp jų be įvykio su laiko žyma yra būdas, kuriuo žmonės pradeda perstatyti sveiką variklį. Traktuokite baitų poslinkį kliento išvestyje kaip duomenis, nes perdavimas, kuris kiekvieną kartą sustoja ties tuo pačiu dydžiu, yra visai kitas žvėris nei tas, kuris niekada neprasideda. Užrašykite abu rezultatus ir palyginkite juos tarp bandymų.
Sukonfigūruokite komponentą, kuris perduoda
Natūraliam Linux varikliui proxy priklauso paslaugos aplinkai, o ne jūsų shell. Drop-in failas po /etc/systemd/system/docker.service.d/ su HTTP_PROXY, HTTPS_PROXY ir NO_PROXY įrašais, po kurių seka systemctl daemon-reload ir paleidimas iš naujo, yra dokumentuota tvarka. Docker Desktop pateikia tas pačias reikšmes per savo nustatymus, o shell profilio redagavimas neliečia nė vieno iš jų.
Jei registry turi būti pasiekiamas tiesiogiai per VPN, daemon reikia resolver, maršruto ir sąmoningo proxy pašalinimo, o ne vien pašalinimo. NO_PROXY atitikimas yra eilučių palyginimas kiekvienam komponentui, o išimtis be pagrindinio maršruto sukuria gedimą, kuris atrodo kaip proxy problema.
Kai įmonės TLS patikra yra patvirtintame kelyje, įdiekite jos patikrintą šaknį per variklio ar Desktop darbo eigą. Registry įtraukimas į insecure-registries yra kitas pakeitimas, išjungiantis validaciją, ir tai nėra pasitikėjimo saugyklos konfigūracija.
Pakartokite vieną kontroliuojamą pull ir patikrinkite, kas pasikeitė
Pakeiskite vieną ribą, paleiskite iš naujo komponentą, kuriam ji priklauso, ir pakartokite tą patį pull iš to paties konteksto. Patikrinkite gautą image nuorodą ir digest, o ne klaidos nebuvimą, nes podėlyje saugomas sluoksnis gali lemti, kad antras bandymas pereis daug mažesnę kelio dalį nei pirmas. Laikykite biliete tuos perdavimus, kurie tikrai įvyko, nes jie yra vienintelis įrašas apie tai, ką pakartojimas iš tikrųjų išbandė.
Build žingsniai ir veikiantys konteineriai turi savo tinklo kontekstus, todėl traktuokite juos kaip atskirus klausimus, kai pats pull veikia.