VPN üzərindən docker pull: daemonun öz şəbəkəsi var
Çəkmə shell-də deyil, daemon daxilində baş verir. Konteksti yoxlayın, həmin mühərrikə öz marşrutunu və ya proxy-ni verin, sonra hansı registry mübadiləsinin bitdiyini oxuyun.
Noutbukunuz korporativ VPN-dədir, curl daxili registry-yə çatır, lakin docker pull hələ də EOF ilə dayanır. Bu birləşmə ziddiyyət deyil. Yazdığınız əmr sizin shell-inizdə işləyir, amma ötürmə Docker CLI-nin seçdiyi hansı daemon daxilində baş verirsə, orada baş verir və o daemon tamamilə başqa hostda ola bilər. İşləməli olan onun şəbəkə yolu, tətbiq olunan isə onun proxy parametrləridir.
Marşrutu deyil, mühərriki müəyyən etməklə başlayın
docker context show və docker version əmrlərini işə salın. Versiya çıxışı müştəri bölməsi və server bölməsi çap edir, server bloku isə kimin cavab verdiyini bildirir: yerli native mühərrik, Docker Desktop virtual maşını və ya uzaq maşındakı daemon. Əmin olmaq istəyirsinizsə, docker context inspect seçilmiş kontekstin son nöqtəsini göstərəcək və bu əmrlərin heç biri heç nəyi dəyişmir.
DOCKER_HOST kimi mühit dəyişəni CLI-ni gözlədiyinizdən fərqli bir mühərrikə səssizcə yönəldə bilər; bu, noutbukun VPN-də göründüyü halda çəkmənin başqa yerə getməsinin adi izahıdır.
Daemonun öz şəbəkə kimliyi var
Uzaq mühərrikin özəl registry-yə öz təsdiqlənmiş yolu lazımdır. Noutbukunuzun VPN müştərisini qoşmaq o noutbuka marşrut verir; laboratoriyada və ya bulud alt şəbəkəsində oturan daemona eyni özəl ünvanı vermir. Əgər mühərrik Docker Desktop-dırsa, çəkmə onun virtual maşınının içində baş verir və həmin maşının öz şəbəkə və proxy konfiqurasiyası sizin shell mühitinizdən ayrıdır.
Buna görə hostda uğurlu curl yalnız host haqqında sübutdur, başqa heç nə deyil.
Hansı registry mübadiləsinin bitdiyini tapın
Obraz çəkmə ardıcıllıqdır: autentifikasiya, manifestin alınması, sonra tez-tez obyekt saxlancına və ya CDN son nöqtəsinə yönləndirilən blob ötürmələri. Uğurlu docker login yalnız birinci addımı sübut edir və token tamamilə etibarlı ola bilər, halbuki yönləndirilmiş blob hostu daemonun şəbəkəsindən əlçatmazdır. Nəyisə dəyişməzdən əvvəl dəqiq vaxtı, obraz istinadını və daemon və ya müştəri jurnalındakı ilk faydalı hadisəni qeyd edin.
EOF təkbaşına heç bir səbəb göstərmir. Bu, kəsilmiş bağlantı, axını atan proxy, vaxt aşımı və ya MTU problemi ola bilər və zaman damğalı hadisə olmadan bunların arasında təxmin etmək insanların sağlam mühərriki yenidən qurmasına gətirib çıxarır. Müştəri çıxışındakı bayt ofsetini məlumat kimi qəbul edin, çünki hər dəfə eyni ölçüdə dayanan ötürmə heç başlamayan ötürmədən tamamilə fərqlidir. Hər iki nəticəni qeyd edin və cəhdlər arasında müqayisə edin.
Ötürməni həyata keçirən komponenti konfiqurasiya edin
Native Linux mühərriki üçün proxy shell-də deyil, xidmət mühitində olmalıdır. /etc/systemd/system/docker.service.d/ altında HTTP_PROXY, HTTPS_PROXY və NO_PROXY qeydləri olan drop-in faylı, ardınca systemctl daemon-reload və yenidən başlatma sənədləşdirilmiş qaydadır. Docker Desktop eyni dəyərləri öz parametrləri vasitəsilə təqdim edir və shell profilini redaktə etmək onların heç birinə toxunmur.
Registry-yə birbaşa VPN üzərindən çatmaq lazımdırsa, daemona yalnız istisna deyil, resolver, marşrut və qəsdən edilmiş proxy istisnası lazımdır. NO_PROXY uyğunluğu hər komponent üçün sətir müqayisəsidir və altında marşrut olmayan azad etmə proxy problemi kimi görünən nasazlıq yaradır.
Korporativ TLS yoxlaması təsdiqlənmiş yolda olduqda, onun yoxlanılmış kök sertifikatını mühərrik və ya Desktop iş axını vasitəsilə quraşdırın. Registry-ni insecure-registries-ə əlavə etmək validasiyanı söndürən başqa bir dəyişiklikdir və bu, trust store konfiqurasiyası deyil.
Bir nəzarətli çəkməni təkrarlayın və nəyin dəyişdiyini yoxlayın
Bir sərhədi dəyişin, ona sahib olan komponenti yenidən başladın və eyni kontekstdən eyni çəkməni təkrarlayın. Xətanın olmamasını deyil, nəticədə alınan obraz istinadını və digest-i yoxlayın, çünki keşlənmiş qat ikinci cəhdin yolun yalnız çox az hissəsini sınamasına səbəb ola bilər. Həqiqətən baş vermiş ötürmələri biletdə saxlayın, çünki onlar təkrar cəhdin həqiqətən nəyi sınaqdan keçirdiyinin yeganə qeydidir.
Build addımları və işləyən konteynerlər öz şəbəkə kontekstlərinə malikdir, ona görə çəkmə özü işlədikdən sonra onlara ayrı suallar kimi baxın.