docker pull melalui VPN: daemon mempunyai rangkaiannya sendiri

Komputer riba anda berada pada VPN korporat, curl mencapai registry dalaman, namun docker pull masih gagal dengan EOF. Gabungan ini bukan percanggahan. Arahan yang anda taip berjalan dalam shell anda, tetapi pemindahan berjalan dalam daemon yang dipilih oleh Docker CLI, dan daemon itu mungkin berada pada hos yang sama sekali berbeza. Laluan rangkaiannyalah yang mesti berfungsi, dan tetapan proxy-nyalah yang terpakai.

Mulakan dengan mengenal pasti enjin, bukan laluan

Jalankan docker context show dan docker version. Output versi mencetak bahagian klien dan bahagian pelayan, dan blok pelayan memberitahu anda apa yang menjawab: enjin asli tempatan, mesin maya Docker Desktop, atau daemon pada mesin jauh. docker context inspect akan menunjukkan titik akhir konteks yang dipilih jika anda mahu pastikan, dan tiada satu pun arahan ini mengubah apa-apa.

Pemboleh ubah persekitaran seperti DOCKER_HOST boleh menghalakan CLI secara senyap ke enjin yang berbeza daripada yang anda anggap, dan itulah penjelasan biasa bagi komputer riba yang kelihatan berada pada VPN sedangkan tarikan pergi ke tempat lain.

Daemon mempunyai identiti rangkaiannya sendiri

Enjin jauh memerlukan laluan yang diluluskan sendiri ke registry peribadi. Menyambungkan klien VPN komputer riba anda memberi komputer riba itu laluan; ia tidak memberi daemon yang berada di makmal atau subnet awan alamat peribadi yang sama. Jika enjinnya Docker Desktop, tarikan berlaku di dalam mesin mayanya, yang mempunyai konfigurasi rangkaian dan proxy sendiri yang berasingan daripada persekitaran shell anda.

Itulah sebabnya curl yang berjaya pada hos hanyalah bukti tentang hos dan tidak lebih.

Cari pertukaran registry yang mana telah berakhir

Tarikan imej ialah satu jujukan: pengesahan, pengambilan manifes, kemudian pemindahan blob yang sering dialihkan ke storan objek atau titik akhir CDN. docker login yang berjaya hanya membuktikan langkah pertama, dan token boleh sah sepenuhnya sedangkan hos blob yang dialihkan tidak dapat dicapai daripada rangkaian daemon. Catat masa yang tepat, rujukan imej dan peristiwa berguna pertama daripada log daemon atau klien sebelum anda mengubah apa-apa.

EOF sahaja tidak menamakan sebarang punca. Ia boleh jadi sambungan terpotong, proxy yang menggugurkan aliran, tamat masa atau masalah MTU, dan meneka antara mereka tanpa peristiwa bertanda masa ialah cara orang akhirnya membina semula enjin yang sihat. Anggap offset bait dalam output klien sebagai data, kerana pemindahan yang berhenti pada saiz yang sama setiap kali ialah haiwan yang berbeza daripada yang tidak pernah bermula. Catat kedua-dua hasil dan bandingkannya antara percubaan.

Konfigurasikan komponen yang memindahkan

Untuk enjin Linux asli, proxy terletak dalam persekitaran perkhidmatan, bukan dalam shell anda. Fail drop-in di bawah /etc/systemd/system/docker.service.d/ dengan entri HTTP_PROXY, HTTPS_PROXY dan NO_PROXY, diikuti systemctl daemon-reload dan mula semula, ialah susunan yang didokumenkan. Docker Desktop mendedahkan nilai yang sama melalui tetapannya sendiri, dan menyunting profil shell tidak menyentuh kedua-duanya.

Jika registry perlu dicapai terus melalui VPN, daemon memerlukan penyelesai, laluan dan pengecualian proxy yang disengajakan, bukan pengecualian sahaja. Padanan NO_PROXY ialah perbandingan rentetan bagi setiap komponen, dan pengecualian tanpa laluan asas menghasilkan kegagalan yang kelihatan seperti masalah proxy.

Apabila pemeriksaan TLS perusahaan berada pada laluan yang diluluskan, pasang akar yang disahkan melalui aliran kerja enjin atau Desktop. Menambah registry ke insecure-registries ialah perubahan lain yang mematikan pengesahan, dan ia bukan konfigurasi stor kepercayaan.

Ulang satu tarikan terkawal dan periksa apa yang berubah

Tukar satu sempadan, mula semula komponen yang memilikinya, dan ulang tarikan yang sama daripada konteks yang sama. Sahkan rujukan imej dan digest yang terhasil, bukan ketiadaan ralat, kerana lapisan yang dicache boleh membuat percubaan kedua melalui bahagian laluan yang jauh lebih kecil daripada yang pertama. Simpan dalam tiket pemindahan yang benar-benar berlaku, kerana itulah satu-satunya rekod tentang apa yang sebenarnya diuji oleh percubaan semula.

Langkah build dan kontena yang berjalan mempunyai konteks rangkaian mereka sendiri, jadi anggap ia sebagai soalan berasingan setelah tarikan itu sendiri berfungsi.