docker pull í gegnum VPN: daemoninn hefur sitt eigið net

Fartölvan þín er á fyrirtækja-VPN, curl nær innri registry og samt sem áður deyr docker pull með EOF. Þessi samsetning er ekki mótsögn. Skipunin sem þú slóst inn keyrir í skelinni þinni, en flutningurinn keyrir í þeim daemon sem Docker CLI hefur valið, og sá daemon getur verið á allt öðrum vélum. Það er netleið hans sem verður að virka, og það eru proxy-stillingar hans sem gilda.

Byrjaðu á að greina vélina, ekki leiðina

Keyrðu docker context show og docker version. Úttak útgáfunnar prentar kafla fyrir biðlara og kafla fyrir þjón, og þjónakaflinn segir þér hvað svaraði: staðbundin innbyggð vél, sýndarvélin Docker Desktop eða daemon á fjarvél. docker context inspect sýnir endapunkt valsins sem er valinn ef þú vilt vera viss, og engin þessara skipana breytir neinu.

Umhverfisbreyta eins og DOCKER_HOST getur hljóðlaust beint CLI að annarri vél en þeirri sem þú gerir ráð fyrir, og það er venjulega skýringin á fartölvu sem virðist vera á VPN á meðan pullið fer annað.

Daemoninn hefur sína eigin netauðkenni

Fjarvél þarf sína eigin samþykktu leið að einkaregistry. Að tengja VPN-biðlara fartölvunnar gefur þeirri fartölvu leið; það gefur daemon sem situr í rannsóknarstofu eða skýjaundirneti ekki sama einkaaðsetur. Ef vélin er Docker Desktop fer pullið fram í sýndarvél hennar, sem hefur sína eigin net- og proxystillingar aðskildar frá umhverfi skeljarinnar þinnar.

Þess vegna er árangursríkt curl á vélinni sönnun um vélina og ekkert meira.

Finndu hvaða skipti við registry enduðu

Pull á mynd er röð: auðkenning, sækja manifest og síðan blob-flutningar sem oft eru vísað áfram í hlutageymslu eða CDN-endapunkt. Árangursríkt docker login sannar aðeins fyrsta skrefið, og tákn getur verið fullkomlega gilt á meðan hinn endurbeindi blob-vél er óaðgengileg úr neti daemonsins. Skráðu nákvæman tíma, myndartilvísun og fyrsta gagnlega atburð úr loggi daemonsins eða biðlarans áður en þú breytir neinu.

EOF eitt og sér nefnir enga orsök. Það getur verið rofin tenging, proxy sem missti strauminn, tímamörk eða MTU-vandamál, og að giska á milli þeirra án tímasetts atburðar er leiðin sem fólk endar á að endurreisa heilbrigða vél. Meðhöndla bætarhliðrunina í úttaki biðlarans sem gögn, því flutningur sem stöðvast á sama stærð í hvert sinn er annað dýr en sá sem byrjar aldrei. Skráðu bæði útkomurnar og berðu þær saman milli tilrauna.

Stilltu íhlutinn sem flytur

Fyrir innbyggða Linux-vél á proxy heima í umhverfi þjónustunnar, ekki í skelinni þinni. Drop-in skrá undir /etc/systemd/system/docker.service.d/ með færslum HTTP_PROXY, HTTPS_PROXY og NO_PROXY, og síðan systemctl daemon-reload og endurræsing, er skjalfesta fyrirkomulagið. Docker Desktop birtir sömu gildi í gegnum eigin stillingar, og að breyta skeljarprófíl snertir hvorugt.

Ef registry á að nást beint í gegnum VPN þarf daemoninn leysir, leið og viljandi proxy-undanþágu, ekki undanþágu eina. NO_PROXY samsvörun er strengjasamanburður fyrir hvern íhlut, og undanþága án undirliggjandi leiðar framleiðir bilun sem lítur út eins og proxy-vandamál.

Þegar fyrirtækja-TLS-skoðun er á samþykktu leiðinni skaltu setja upp staðfesta rót hennar í gegnum vinnuflæði vélarinnar eða Desktop. Að bæta registry við insecure-registries er önnur breyting sem slökkvir á sannprófun, og það er ekki stilling á traustgeymslu.

Endurtaktu eitt stýrt pull og athugaðu hvað breyttist

Breyttu einni mörk, endurræstu íhlutinn sem á hana og endurtaktu sama pull úr sama samhengi. Staðfestu myndartilvísunina og digestið sem verður til, ekki fjarveru villu, því skyggt lag getur gert aðra tilraun kleift að fara mun minni hluta leiðarinnar en sú fyrsta. Geymdu flutningana sem raunverulega áttu sér stað í miðanum, því þeir eru eina skráin um hvað endurtakan prófaði í raun.

Build-skref og keyrandi gámar hafa sín eigin netsamhengi, svo meðhöndlaðu þau sem aðskildar spurningar þegar pullið sjálft virkar.