docker pull përmes një VPN: daemon-i ka rrjetin e vet

Laptopi juaj është në VPN-në e korporatës, curl arrin registry-në e brendshme, dhe megjithatë docker pull ende dështon me një EOF. Ky kombinim nuk është kundërshtim. Komanda që shtypët ekzekutohet në shell-in tuaj, por transferimi ekzekutohet në atë daemon që ka zgjedhur Docker CLI, dhe ai daemon mund të jetë në një host krejt tjetër. Është rruga e tij e rrjetit ajo që duhet të funksionojë, dhe janë cilësimet e tij të proxy ato që zbatohen.

Filloni duke identifikuar motorin, jo rrugën

Ekzekutoni docker context show dhe docker version. Dalja e versionit shtyp një seksion klienti dhe një seksion serveri, dhe blloku i serverit ju tregon kush u përgjigj: një motor vendas natyror, makineria virtuale e Docker Desktop, ose një daemon në një makinë të largët. docker context inspect do të tregojë pikën fundore të kontekstit të zgjedhur nëse doni të jeni i sigurt, dhe asnjë prej këtyre komandave nuk ndryshon asgjë.

Një variabël mjedisi si DOCKER_HOST mund ta drejtojë në heshtje CLI-në nga një motor tjetër nga ai që supozoni, dhe ky është shpjegimi i zakonshëm për një laptop që duket se është në VPN ndërsa tërheqja shkon diku tjetër.

Daemon-i ka identitetin e vet të rrjetit

Një motor i largët ka nevojë për rrugën e vet të miratuar drejt registry-së private. Lidhja e klientit VPN të laptopit i jep një rrugë atij laptopi; nuk i jep të njëjtin adresë private një daemon-i që ndodhet në laborator ose në një nënrrjet cloud. Nëse motori është Docker Desktop, tërheqja ndodh brenda makinës së tij virtuale, e cila ka konfigurimin e vet të rrjetit dhe të proxy-t, të ndarë nga mjedisi i shell-it tuaj.

Prandaj një curl i suksesshëm në host është provë për host-in dhe asgjë më shumë.

Zbuloni cili shkëmbim me registry-në përfundoi

Tërheqja e një imazhi është një sekuencë: vërtetim, marrje e manifestit, dhe më pas transferime blob që shpesh ridrejtohen drejt ruajtjes së objekteve ose një pike fundore CDN. Një docker login i suksesshëm provon vetëm hapin e parë, dhe një token mund të jetë plotësisht i vlefshëm ndërsa host-i i blob-it të ridrejtuar është i paarritshëm nga rrjeti i daemon-it. Regjistroni kohën e saktë, referencën e imazhit dhe ngjarjen e parë të dobishme nga regjistri i daemon-it ose i klientit përpara se të ndryshoni diçka.

EOF i vetëm nuk përmend asnjë shkak. Mund të jetë një lidhje e ndërprerë, një proxy që e lëshoi rrjedhën, një afat i skaduar ose një problem MTU, dhe hamendja mes tyre pa ngjarjen me vulë kohore është mënyra se si njerëzit përfundojnë duke rindërtuar një motor të shëndetshëm. Trajtojeni zhvendosjen e bajtëve në daljen e klientit si të dhënë, sepse një transferim që ndalon gjithmonë në të njëjtën madhësi është një kafshë tjetër nga një që nuk fillon kurrë. Regjistroni të dyja rezultatet dhe krahasoni ato mes provave.

Konfiguroni komponentin që transferon

Për një motor natyror Linux, proxy i takon mjedisit të shërbimit, jo shell-it tuaj. Një skedar drop-in nën /etc/systemd/system/docker.service.d/ me hyrje HTTP_PROXY, HTTPS_PROXY dhe NO_PROXY, i ndjekur nga systemctl daemon-reload dhe një rindezje, është rregullimi i dokumentuar. Docker Desktop ekspozon të njëjtat vlera përmes cilësimeve të veta, dhe redaktimi i një profili shell nuk prek asnjërën prej tyre.

Nëse registry duhet arritur drejtpërdrejt përmes VPN-së, daemon-i ka nevojë për një zgjidhës, një rrugë dhe një përjashtim të qëllimshëm të proxy-t, jo vetëm një përjashtim. Përputhja e NO_PROXY është një krahasim vargjesh për çdo komponent, dhe një përjashtim pa rrugë bazë prodhon një dështim që duket si problem proxy.

Kur inspektimi i TLS-së së korporatës ndodhet në rrugën e miratuar, instaloni rrënjën e tij të verifikuar përmes rrjedhës së punës së motorit ose të Desktop. Shtimi i registry-së në insecure-registries është një ndryshim tjetër që çaktivizon vërtetimin, dhe nuk është konfigurim i një depoje besimi.

Përsëritni një tërheqje të kontrolluar dhe kontrolloni çfarë ndryshoi

Ndryshoni një kufi, rindizni komponentin që e zotëron atë, dhe përsëritni të njëjtën tërheqje nga i njëjti kontekst. Verifikoni referencën e imazhit dhe digest-in që rezulton, jo mungesën e një gabimi, sepse një shtresë e ruajtur në cache mund ta bëjë provën e dytë të kalojë një pjesë shumë më të vogël të rrugës sesa e para. Mbani në tiketë transferimet që ndodhën vërtet, sepse ato janë regjistri i vetëm i asaj që provoi vërtet përsëritja.

Hapat e build-it dhe kontejnerët që ekzekutohen kanë kontekstet e tyre të rrjetit, prandaj trajtojini si pyetje të ndara pasi vetë tërheqja të funksionojë.