docker pull kupitia VPN: daemon ina mtandao wake

Kompyuta yako mpito iko kwenye VPN ya kampuni, curl inafikia rejista ya ndani, na bado docker pull inashindwa kwa EOF. Mchanganyiko huu si ukinzani. Amri uliyoandika inaendeshwa kwenye shell yako, lakini uhamishaji unaendeshwa ndani ya daemon ambayo Docker CLI imeichagua, na daemon hiyo inaweza kuwa kwenye mwenyeji mwingine kabisa. Njia yake ya mtandao ndiyo lazima ifanye kazi, na mipangilio yake ya proksi ndiyo inayotumika.

Anza kwa kutambua injini, si njia

Endesha docker context show na docker version. Matokeo ya toleo huchapisha sehemu ya mteja na sehemu ya seva, na kizuizi cha seva hukuambia nini kilijibu: injini asilia ya ndani, mashine pepe ya Docker Desktop, au daemon kwenye mashine ya mbali. docker context inspect itaonyesha kituo cha mwisho cha muktadha uliochaguliwa ikiwa unataka kuwa na uhakika, na hakuna amri yoyote kati ya hizi inabadilisha chochote.

Kigeu cha mazingira kama DOCKER_HOST kinaweza kuelekeza CLI kimya kimya kwenye injini tofauti na ile unayodhani, na hiyo ndiyo maelezo ya kawaida ya kompyuta inayoonekana kuwa kwenye VPN wakati uvutaji unakwenda mahali pengine.

Daemon ina utambulisho wake wa mtandao

Injini ya mbali inahitaji njia yake iliyoidhinishwa kwenda kwenye rejista ya kibinafsi. Kuunganisha mteja wa VPN wa kompyuta yako kunampa kompyuta hiyo njia; hakumpi daemon aliye katika maabara au subnet ya wingu anwani hiyo hiyo ya kibinafsi. Ikiwa injini ni Docker Desktop, uvutaji hufanyika ndani ya mashine yake pepe, ambayo ina usanidi wake wa mtandao na proksi tofauti na mazingira ya shell yako.

Ndiyo sababu curl iliyofanikiwa kwenye mwenyeji ni ushahidi kuhusu mwenyeji na si zaidi.

Gundua ni mabadilishano gani na rejista yaliyoisha

Uvutaji wa picha ni mfululizo: uthibitishaji, upataji wa manifest, kisha uhamishaji wa blob ambao mara nyingi huelekezwa kwenye hifadhi ya vitu au kituo cha CDN. docker login iliyofanikiwa inathibitisha hatua ya kwanza tu, na token inaweza kuwa halali kabisa wakati mwenyeji wa blob ulioelekezwa hawezi kufikiwa kutoka kwenye mtandao wa daemon. Andika muda kamili, rejeleo la picha na tukio la kwanza muhimu kutoka kwa kumbukumbu ya daemon au mteja kabla ya kubadilisha kitu.

EOF peke yake haitaji sababu yoyote. Inaweza kuwa muunganisho uliokatika, proksi iliyoacha mtiririko, muda kuisha au tatizo la MTU, na kubahatisha kati yao bila tukio lenye muhuri wa muda ndiyo njia ambayo watu huishia kujenga injini nzuri upya. Chukulia mabadiliko ya baiti kwenye matokeo ya mteja kama data, kwa sababu uhamishaji unaosimama kwa ukubwa ule ule kila mara ni mnyama tofauti na ule usioanza kamwe. Andika matokeo yote mawili na uyalinganishe kati ya majaribio.

Sanidi sehemu inayohamisha

Kwa injini asilia ya Linux, proksi iko kwenye mazingira ya huduma, si kwenye shell yako. Faili ya drop-in chini ya /etc/systemd/system/docker.service.d/ yenye maingizo HTTP_PROXY, HTTPS_PROXY na NO_PROXY, ikifuatiwa na systemctl daemon-reload na kuanzisha upya, ndiyo mpangilio ulioandikwa. Docker Desktop hutoa maadili hayo hayo kupitia mipangilio yake, na kuhariri wasifu wa shell hakuathiri yoyote kati yao.

Ikiwa rejista inapaswa kufikiwa moja kwa moja kupitia VPN, daemon inahitaji kitatuzi, njia na kutengwa kwa proksi kwa makusudi, si kutengwa peke yake. Ulinganishaji wa NO_PROXY ni ulinganisho wa mfuatano kwa kila sehemu, na msamaha usio na njia ya msingi huzalisha kushindwa kunakoonekana kama tatizo la proksi.

Wakati ukaguzi wa TLS wa shirika uko kwenye njia iliyoidhinishwa, sakinisha mzizi wake uliothibitishwa kupitia mtiririko wa kazi wa injini au Desktop. Kuongeza rejista kwenye insecure-registries ni mabadiliko tofauti yanayozima uthibitishaji, na si usanidi wa hifadhi ya imani.

Rudia uvutaji mmoja unaodhibitiwa na uangalie kilichobadilika

Badilisha mpaka mmoja, anzisha upya sehemu inayomiliki, na urudie uvutaji ule ule kutoka kwenye muktadha ule ule. Thibitisha rejeleo la picha na digest inayotokana, si kutokuwepo kwa hitilafu, kwa sababu tabaka lililohifadhiwa kwenye akiba linaweza kufanya jaribio la pili lipite sehemu ndogo sana ya njia kuliko la kwanza. Weka kwenye tiketi uhamishaji uliotokea kweli, kwa sababu ndiyo rekodi pekee ya kile jaribio la pili lilijaribu kwa hakika.

Hatua za build na kontena zinazoendeshwa zina muktadha wao wa mtandao, kwa hiyo zichukulie kama maswali tofauti mara uvutaji wenyewe unapofanya kazi.