Mengapa kontena Docker mengabaikan penyelesai DNS VPN

VPN hidup, pelayar sampai ke laman dalaman, tetapi kontena masih tidak dapat menyelesaikan nama yang sama. Pemasangan pakej mati dengan ralat penyelesaian nama seperti EAI_AGAIN, atau aplikasi tidak menemui hos pangkalan data yang diselesaikan mesin hos tanpa sebarang aduan. Kontena tidak menggunakan penyelesai yang dipasang VPN. Docker menyalin konfigurasi penyelesai hos semasa kontena dicipta, dan tiada apa yang menyalinnya semula selepas itu.

Dua pandangan penyelesai pada satu mesin

Pada Linux, Docker memberikan setiap kontena salinan konfigurasi penyelesai hos pada masa penciptaan, menapis alamat loopback, dan menjalankan pelayan DNS terbenam pada 127.0.0.11 yang memajukan pertanyaan ke luar. Klien VPN yang menulis semula /etc/resolv.conf selepas kontena dimulakan tidak mengubah apa-apa di dalamnya. Memulakan semula kontena hanya membantu jika penyelesai hos kebetulan betul pada saat itu.

Docker Desktop pada macOS atau Windows menambah satu lapisan, kerana daemon tinggal dalam mesin maya. Penyelesai VPN hos mungkin tidak pernah kelihatan kepada VM itu, jadi memulakan semula tidak mengubah apa-apa sama sekali. Bandingkan kedua-dua pandangan sebelum memilih pembaikan: docker exec mycontainer cat /etc/resolv.conf di sebelah senarai penyelesai hos.

Kontena yang menyenaraikan penyelesai awam sementara hos menyenaraikan yang dalaman akan menyelesaikan nama awam dan gagal pada nama dalaman. Perpecahan itulah tandatangan masalah ini.

Pilihan A: berikan penyelesai terowong bagi setiap kontena

Docker menerima tetapan DNS bagi setiap kontena, dan itulah perubahan terkecil yang berkesan. Baca alamat penyelesai VPN dahulu: scutil --dns pada macOS, resolvectl status atau output status klien itu sendiri pada Linux. Kemudian mulakan kontena dengan alamat itu, contohnya docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Dalam Compose tetapan yang sama ialah senarai di bawah perkhidmatan, tempat ia hidup dalam kawalan versi dan bukan sejarah shell seseorang.

Tatasusunan dns dalam /etc/docker/daemon.json terpakai pada setiap kontena baharu, yang kedengaran lebih kemas dan sebenarnya tidak. Ia juga terpakai apabila terowong mati, dan penyelesai yang hanya boleh dicapai melalui VPN kemudian merosakkan tarikan imej biasa. Tetapan setiap kontena lebih mudah dipertanggungjawabkan dan lebih mudah dibatalkan.

Pilihan B: biarkan kontena berkongsi rangkaian hos

Rangkaian hos memintas salinan sepenuhnya, kerana kontena menggunakan penyelesai hos dan terowong hos. Ia juga membuang pengasingan rangkaian yang mungkin anda mahukan, dan ia tidak berkelakuan sama di bawah Docker Desktop. Pada Linux ia ialah pilihan pragmatik untuk alat sekali guna yang mesti menyelesaikan nama dalaman.

Untuk binaan, kedua-dua pilihan tidak terpakai, kerana langkah binaan tidak mewarisi bendera masa jalan. Bina dengan rangkaian hos di tempat platform membenarkannya, atau simpan pemasangan kebergantungan dalam peringkat yang tidak memerlukan terowong.

Apa yang tidak dibaiki oleh kedua-dua pilihan

Alamat DNS tidak berguna jika kontena tiada laluan ke sana. Penyelesai VPN biasanya duduk di dalam ruang alamat terowong, jadi kontena memerlukan laluan ke awalan itu. Jambatan lalai Docker biasanya menghala ke luar melalui hos, dan itu memadai apabila hos mempunyai laluan terowong dan pemajuan dihidupkan. Rangkaian jambatan tersuai dengan kolam alamat sendiri boleh berlanggar dengan subnet VPN, dan pertanyaan pun pergi ke tempat yang jauh berbeza.

Periksa subnet rangkaian Docker terhadap subnet VPN sebelum anda menyahpepijat penyelesai itu sendiri. Pertindihan menghasilkan kegagalan yang kelihatan tepat seperti pelayan DNS rosak.

Sahkan di dalam kontena

Uji dengan getent hosts db.internal di dalam kontena dan bukan dengan pelayar atau runtime bahasa, kerana kedua-duanya menggunakan dasar DNS dan cache mereka sendiri. Jika getent menyelesaikan nama itu dan aplikasi masih gagal, penyelesai kini betul dan masalah yang tinggal berada pada peringkat aplikasi. Jika ia tidak menyelesaikannya, langkah DNS belum selesai.

Cipta semula kontena selepas menukar tetapan DNS-nya. Menyunting /etc/resolv.conf di dalam kontena yang berjalan hilang bersamanya dan menyembunyikan masalah konfigurasi tepat selama masa yang diambil oleh seseorang untuk memulakannya semula.