docker pull lewat VPN: daemon punya jaringannya sendiri

Laptop Anda berada di VPN perusahaan, curl mencapai registry internal, tetapi docker pull tetap gagal dengan EOF. Kombinasi ini bukan kontradiksi. Perintah yang Anda ketik berjalan di shell Anda, tetapi transfernya berjalan di daemon mana pun yang dipilih Docker CLI, dan daemon itu bisa berada di host yang sama sekali berbeda. Jalur jaringannya lah yang harus bekerja, dan pengaturan proxy-nya lah yang berlaku.

Mulailah dengan mengidentifikasi engine, bukan rute

Jalankan docker context show dan docker version. Keluaran versi mencetak bagian klien dan bagian server, dan blok server memberi tahu Anda siapa yang menjawab: engine native lokal, mesin virtual Docker Desktop, atau daemon di mesin jarak jauh. docker context inspect akan menunjukkan endpoint konteks yang dipilih jika Anda ingin memastikannya, dan tidak satu pun dari perintah ini mengubah apa pun.

Variabel lingkungan seperti DOCKER_HOST dapat diam-diam mengarahkan CLI ke engine yang berbeda dari yang Anda asumsikan, dan itulah penjelasan biasa untuk laptop yang tampak berada di VPN sementara pull berjalan ke tempat lain.

Daemon memiliki identitas jaringan sendiri

Engine jarak jauh membutuhkan jalur yang disetujui sendiri ke registry privat. Menyambungkan klien VPN laptop Anda memberi laptop itu sebuah rute; itu tidak memberi daemon yang berada di laboratorium atau subnet cloud alamat privat yang sama. Jika engine-nya Docker Desktop, pull terjadi di dalam mesin virtualnya, yang memiliki konfigurasi jaringan dan proxy sendiri yang terpisah dari lingkungan shell Anda.

Itulah sebabnya curl yang berhasil di host hanya bukti tentang host dan tidak lebih.

Cari tahu pertukaran registry mana yang berakhir

Penarikan image adalah rangkaian: autentikasi, pengambilan manifest, lalu transfer blob yang sering dialihkan ke object storage atau endpoint CDN. docker login yang berhasil hanya membuktikan langkah pertama, dan token bisa sepenuhnya valid sementara host blob yang dialihkan tidak terjangkau dari jaringan daemon. Catat waktu persisnya, referensi image, dan peristiwa berguna pertama dari log daemon atau klien sebelum Anda mengubah apa pun.

EOF sendirian tidak menyebutkan penyebab apa pun. Bisa jadi koneksi terpotong, proxy yang menjatuhkan aliran, waktu tunggu habis, atau masalah MTU, dan menebak di antaranya tanpa peristiwa bertanda waktu adalah cara orang akhirnya membangun ulang engine yang sehat. Perlakukan offset byte pada keluaran klien sebagai data, karena transfer yang berhenti pada ukuran yang sama setiap kali adalah hewan yang berbeda dari yang tidak pernah mulai. Catat kedua hasil dan bandingkan di antara percobaan.

Konfigurasikan komponen yang mentransfer

Untuk engine Linux native, proxy berada di lingkungan layanan, bukan di shell Anda. Berkas drop-in di bawah /etc/systemd/system/docker.service.d/ dengan entri HTTP_PROXY, HTTPS_PROXY, dan NO_PROXY, diikuti systemctl daemon-reload dan restart, adalah susunan yang didokumentasikan. Docker Desktop mengekspos nilai yang sama melalui pengaturannya sendiri, dan mengedit profil shell tidak menyentuh keduanya.

Jika registry harus dijangkau langsung melalui VPN, daemon membutuhkan resolver, rute, dan pengecualian proxy yang disengaja, bukan hanya pengecualian. Pencocokan NO_PROXY adalah perbandingan string per komponen, dan pengecualian tanpa rute yang mendasarinya menghasilkan kegagalan yang tampak seperti masalah proxy.

Ketika inspeksi TLS perusahaan berada di jalur yang disetujui, pasang akar terverifikasinya melalui alur kerja engine atau Desktop. Menambahkan registry ke insecure-registries adalah perubahan berbeda yang mematikan validasi, dan itu bukan konfigurasi trust store.

Ulangi satu pull terkendali dan periksa apa yang berubah

Ubah satu batas, mulai ulang komponen yang memilikinya, dan ulangi pull yang sama dari konteks yang sama. Verifikasi referensi image dan digest yang dihasilkan, bukan tidak adanya kesalahan, karena lapisan yang di-cache dapat membuat percobaan kedua melewati bagian jalur yang jauh lebih sedikit daripada yang pertama. Simpan transfer yang benar-benar terjadi di tiket, karena itu satu-satunya catatan tentang apa yang benar-benar diuji oleh percobaan ulang.

Langkah build dan kontainer yang berjalan memiliki konteks jaringan sendiri, jadi perlakukan sebagai pertanyaan terpisah setelah pull itu sendiri berfungsi.