docker pull sa pamamagitan ng VPN: may sariling network ang daemon

Ang laptop mo ay nasa corporate VPN, naaabot ng curl ang panloob na registry, at namamatay pa rin ang docker pull na may EOF. Ang kombinasyong ito ay hindi kontradiksyon. Ang command na tina-type mo ay tumatakbo sa shell mo, ngunit ang transfer ay tumatakbo sa daemon na pinili ng Docker CLI, at ang daemon na iyon ay maaaring nasa ibang host nang lubusan. Ang network path nito ang dapat gumana, at ang mga setting ng proxy nito ang nalalapat.

Magsimula sa pagkilala sa engine, hindi sa ruta

Patakbuhin ang docker context show at docker version. Ang output ng version ay nagpi-print ng seksyon ng kliyente at seksyon ng server, at sinasabi ng bloke ng server kung ano ang sumagot: lokal na native engine, ang virtual machine ng Docker Desktop, o isang daemon sa isang malayong makina. Ipapakita ng docker context inspect ang endpoint ng napiling konteksto kung gusto mong makasiguro, at wala sa mga command na ito ang nagbabago ng anuman.

Ang environment variable na tulad ng DOCKER_HOST ay maaaring tahimik na magturo sa CLI sa ibang engine kaysa sa inaakala mo, at iyon ang karaniwang paliwanag para sa laptop na mukhang nasa VPN habang ang pull ay pumupunta sa ibang lugar.

May sariling pagkakakilanlang network ang daemon

Ang malayong engine ay nangangailangan ng sarili nitong aprubadong landas patungo sa pribadong registry. Ang pagkonekta sa VPN client ng laptop mo ay nagbibigay ng ruta sa laptop na iyon; hindi nito binibigyan ang isang daemon sa laboratoryo o cloud subnet ng parehong pribadong address. Kung ang engine ay Docker Desktop, ang pull ay nangyayari sa loob ng virtual machine nito, na may sariling networking at proxy configuration na hiwalay sa environment ng shell mo.

Kaya nga ang matagumpay na curl sa host ay ebidensya tungkol sa host at wala nang iba.

Alamin kung aling palitan sa registry ang natapos

Ang pag-pull ng image ay isang pagkakasunod-sunod: authentication, pagkuha ng manifest, at pagkatapos ay mga paglilipat ng blob na madalas na nire-redirect sa object storage o sa isang CDN endpoint. Ang matagumpay na docker login ay nagpapatunay lamang sa unang hakbang, at ang token ay maaaring ganap na wasto habang ang nire-redirect na blob host ay hindi maabot mula sa network ng daemon. Itala ang eksaktong oras, ang reference ng image at ang unang kapaki-pakinabang na kaganapan mula sa log ng daemon o kliyente bago ka magbago ng anuman.

Ang EOF nang nag-iisa ay hindi nagsasabi ng dahilan. Maaaring ito ay naputol na koneksyon, proxy na nagbaba ng stream, timeout o problema sa MTU, at ang paghula sa pagitan nila nang walang kaganapang may timestamp ay kung paano nauuwi ang mga tao sa muling pagbuo ng malusog na engine. Ituring ang byte offset sa output ng kliyente bilang data, dahil ang paglilipat na humihinto sa parehong laki tuwing may ibang hayop kaysa sa isa na hindi kailanman nagsisimula. Itala ang parehong resulta at ihambing ang mga ito sa mga pagtatangka.

I-configure ang komponent na naglilipat

Para sa native na Linux engine, ang proxy ay kabilang sa environment ng serbisyo, hindi sa shell mo. Ang drop-in file sa ilalim ng /etc/systemd/system/docker.service.d/ na may mga entry na HTTP_PROXY, HTTPS_PROXY at NO_PROXY, na sinusundan ng systemctl daemon-reload at restart, ay ang dokumentadong kaayusan. Inilalantad ng Docker Desktop ang parehong mga halaga sa pamamagitan ng sarili nitong mga setting, at ang pag-edit ng profile ng shell ay hindi humahawak sa alinman sa dalawa.

Kung ang registry ay dapat maabot nang direkta sa VPN, kailangan ng daemon ng resolver, ruta at sadyang pagbubukod sa proxy, hindi lamang pagbubukod. Ang pagtutugma ng NO_PROXY ay paghahambing ng string bawat komponent, at ang pagbubukod na walang pinagbabatayang ruta ay gumagawa ng pagkabigo na mukhang problema sa proxy.

Kapag ang enterprise TLS inspection ay nasa aprubadong landas, i-install ang verified root nito sa pamamagitan ng workflow ng engine o Desktop. Ang pagdaragdag ng registry sa insecure-registries ay ibang pagbabago na nagpapatay sa validation, at hindi ito configuration ng trust store.

Ulitin ang isang kontroladong pull at tingnan kung ano ang nagbago

Baguhin ang isang hangganan, i-restart ang komponent na nagmamay-ari nito, at ulitin ang parehong pull mula sa parehong konteksto. I-verify ang resultang reference ng image at digest, hindi ang kawalan ng error, dahil ang naka-cache na layer ay maaaring gawing mas maliit na bahagi ng landas ang dinadaanan ng ikalawang pagtatangka kaysa sa una. Itago sa ticket ang mga paglilipat na aktwal na nangyari, dahil iyon lamang ang talaan ng tunay na sinubukan ng muling pagtatangka.

Ang mga hakbang ng build at ang mga tumatakbong container ay may sariling mga konteksto ng network, kaya ituring ang mga ito bilang magkakahiwalay na tanong kapag gumana na ang pull mismo.