Docker kapsayıcıları VPN'in DNS çözümleyicisini neden yok sayar

VPN açık, tarayıcı iç sitelere ulaşıyor ve kapsayıcı hâlâ aynı adları çözemiyor. Bir paket kurulumu EAI_AGAIN gibi bir ad çözümleme hatasıyla ölüyor ya da bir uygulama, ana makinenin hiçbir şikâyet olmadan çözdüğü bir veritabanı sunucusunu bulamıyor. Kapsayıcı, VPN'in kurduğu çözümleyiciyi kullanmıyor. Docker, kapsayıcı oluşturulduğunda ana makinenin çözümleyici yapılandırmasını kopyaladı ve sonrasında hiçbir şey onu yeniden kopyalamadı.

Tek makinede iki çözümleyici görünümü

Linux'ta Docker, oluşturma anında her kapsayıcıya ana makinenin çözümleyici yapılandırmasının bir kopyasını verir, loopback adreslerini süzer ve 127.0.0.11 üzerinde sorguları dışarı ileten gömülü bir DNS sunucusu çalıştırır. Kapsayıcı başladıktan sonra /etc/resolv.conf dosyasını yeniden yazan bir VPN istemcisi içinde hiçbir şeyi değiştirmez. Kapsayıcıyı yeniden başlatmak yalnızca o anda ana makinenin çözümleyicisi tesadüfen doğruysa yardımcı olur.

macOS veya Windows'taki Docker Desktop bir katman ekler, çünkü daemon sanal bir makinede yaşar. Ana makinenin VPN çözümleyicisi o VM için hiç görünmeyebilir, bu yüzden yeniden başlatmak hiçbir şeyi değiştirmez. Bir düzeltme seçmeden önce iki görünümü karşılaştırın: ana makinenin çözümleyici listesinin yanında docker exec mycontainer cat /etc/resolv.conf.

Ana makine iç bir çözümleyici listelerken genel bir çözümleyici listeleyen kapsayıcı, genel adları çözer ve iç adlarda başarısız olur. Bu ayrım bu sorunun imzasıdır.

Seçenek A: tünel çözümleyicisini kapsayıcı başına geçirmek

Docker kapsayıcı başına DNS ayarlarını kabul eder ve bu, işe yarayan en küçük değişikliktir. Önce VPN'in çözümleyici adreslerini okuyun: macOS'ta scutil --dns, Linux'ta resolvectl status veya istemcinin kendi durum çıktısı. Ardından kapsayıcıyı bunlarla başlatın, örneğin docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Compose'da aynı ayar servisin altındaki bir listedir ve orada birinin shell geçmişi yerine sürüm denetiminde yaşar.

/etc/docker/daemon.json içindeki dns dizisi her yeni kapsayıcıya uygulanır; bu daha düzenli kulağa gelir ama değildir. Tünel kapalıyken de uygulanır ve o zaman yalnızca VPN üzerinden erişilebilen bir çözümleyici sıradan imaj çekmelerini bozar. Kapsayıcı başına ayarların gerekçelendirilmesi ve geri alınması daha kolaydır.

Seçenek B: kapsayıcının ana makine ağını paylaşmasına izin vermek

Ana makine ağı kopyayı tamamen atlar, çünkü kapsayıcı ana makinenin çözümleyicisini ve ana makinenin tünelini kullanır. Ayrıca muhtemelen istediğiniz ağ yalıtımını ortadan kaldırır ve Docker Desktop altında aynı şekilde davranmaz. Linux'ta iç adları çözmesi gereken tek seferlik bir araç için pragmatik seçimdir.

Derlemeler için iki seçenek de geçerli değildir, çünkü derleme adımları çalışma zamanı bayraklarını devralmaz. Platformun izin verdiği yerde ana makine ağıyla derleyin ya da bağımlılık kurulumunu tünele ihtiyaç duymayan bir aşamada tutun.

İki seçeneğin de düzeltmediği şey

Kapsayıcının oraya bir rotası yoksa DNS adresi işe yaramaz. VPN çözümleyicisi genellikle tünelin adres uzayının içinde oturur, bu yüzden kapsayıcının o öneke bir yolu olması gerekir. Docker'ın varsayılan köprüsü normalde ana makine üzerinden dışarı yönlendirir ve ana makinede tünel rotası olup yönlendirme açıksa bu yeterlidir. Kendi adres havuzlarına sahip özel köprü ağları VPN alt ağıyla çakışabilir ve o zaman sorgular bambaşka bir yere gider.

Çözümleyicinin kendisinde hata ayıklamadan önce Docker ağının alt ağını VPN'in alt ağıyla karşılaştırın. Çakışma, tıpkı bozuk bir DNS sunucusu gibi görünen bir arıza üretir.

Kapsayıcının içinde doğrulayın

Tarayıcı ya da dil çalışma zamanı yerine kapsayıcının içinde getent hosts db.internal ile test edin, çünkü onlar kendi DNS ilkelerini ve kendi önbelleklerini uygular. getent adı çözerse ve uygulama hâlâ başarısız olursa çözümleyici artık doğrudur ve kalan sorun uygulama düzeyindedir. Çözmezse DNS adımı tamamlanmamıştır.

DNS ayarlarını değiştirdikten sonra kapsayıcıyı yeniden oluşturun. Çalışan bir kapsayıcının içinde /etc/resolv.conf dosyasını düzenlemek onunla birlikte kaybolur ve yapılandırma sorununu birinin onu yeniden başlatması için gereken süre boyunca gizler.