Niyə Docker konteynerləri VPN-in DNS həlledicisini görməzliyə vurur
Konteyner başladıqda host-un həlledicisini kopyalayır, ona görə DNS-i sonradan dəyişən VPN onun içində görünməz qalır. Həlledicini açıq şəkildə ötürün.
VPN işləyir, brauzer daxili saytlara çatır, amma konteyner həmin adları hələ də həll edə bilmir. Paket quraşdırması EAI_AGAIN kimi bir ad həlli xətası ilə ölür, ya da tətbiq host maşınının heç bir şikayət etmədən həll etdiyi verilənlər bazası hostunu tapa bilmir. Konteyner VPN-in quraşdırdığı həlledicidən istifadə etmir. Docker host-un həlledici konfiqurasiyasını konteyner yaradılanda kopyalayıb və sonra heç nə onu yenidən kopyalamayıb.
Bir maşında iki həlledici görünüşü
Linux-da Docker hər konteynerə yaradılma anında host-un həlledici konfiqurasiyasının surətini verir, loopback ünvanlarını süzür və 127.0.0.11 ünvanında xarici istiqamətə sorğu ötürən daxili DNS serveri işlədir. Konteyner başladıqdan sonra /etc/resolv.conf faylını yenidən yazan VPN müştərisi onun içində heç nəyi dəyişmir. Konteyneri yenidən başlatmaq yalnız o anda host həlledicisi təsadüfən düzgün olduqda kömək edir.
macOS və ya Windows-dakı Docker Desktop bir qat əlavə edir, çünki demon virtual maşında yaşayır. Host-un VPN həlledicisi o VM üçün heç vaxt görünməyə bilər, ona görə yenidən başlatma heç nəyi dəyişmir. Düzəliş seçməzdən əvvəl iki görünüşü müqayisə edin: host-un həlledici siyahısının yanında docker exec mycontainer cat /etc/resolv.conf.
Host daxili həlledici sadalayarkən konteynerin ictimai həlledici sadalaması ictimai adları həll edəcək, daxili adlarda isə uğursuz olacaq. Bu parçalanma bu problemin imzasıdır.
A variantı: tunel həlledicisini hər konteynerə ötürmək
Docker hər konteyner üzrə DNS parametrlərini qəbul edir və bu, işləyən ən kiçik dəyişiklikdir. Əvvəlcə VPN-in həlledici ünvanlarını oxuyun: macOS-da scutil --dns, Linux-da resolvectl status və ya müştərinin öz status çıxışı. Sonra konteyneri onlarla başladın, məsələn docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Compose-da eyni parametr servisin altındakı siyahıdır və orada kiminsə shell tarixçəsi əvəzinə versiya nəzarətində yaşayır.
/etc/docker/daemon.json faylındakı dns massivi hər yeni konteynerə tətbiq olunur; bu daha səliqəli səslənir, amma belə deyil. Tunel söndüyü zaman da tətbiq olunur və yalnız VPN vasitəsilə əlçatan olan həlledici o zaman adi image dartmalarını pozur. Hər konteyner üzrə parametrləri əsaslandırmaq və geri qaytarmaq daha asandır.
B variantı: konteyner host şəbəkəsini paylaşsın
Host şəbəkəsi kopyanı tamamilə yan keçir, çünki konteyner host-un həlledicisindən və host-un tunelindən istifadə edir. O, həm də çox güman ki istədiyiniz şəbəkə təcridini aradan qaldırır və Docker Desktop altında eyni cür davranmır. Linux-da daxili adları həll etməli olan birdəfəlik alət üçün praqmatik seçimdir.
Build-lər üçün iki variantın heç biri tətbiq olunmur, çünki build addımları iş vaxtı açarlarını miras almır. Platformanın icazə verdiyi yerdə host şəbəkəsi ilə build edin və ya asılılıq quraşdırmasını tunelə ehtiyacı olmayan mərhələdə saxlayın.
Heç bir variantın düzəltmədiyi şeylər
Konteynerin ona marşrutu yoxdursa, DNS ünvanı faydasızdır. VPN həlledicisi adətən tunelin ünvan məkanının içində oturur, ona görə konteynerə həmin prefiksə yol lazımdır. Docker-in standart körpüsü normalda host vasitəsilə xaricə yönləndirir və host-da tunel marşrutu olub yönləndirmə aktiv olduqda bu kifayətdir. Öz ünvan hovuzları olan fərdi körpü şəbəkələri VPN alt şəbəkəsi ilə toqquşa bilər və o zaman sorğular tamamilə başqa yerə gedir.
Həlledicinin özünü sazlamazdan əvvəl Docker şəbəkəsinin alt şəbəkəsini VPN alt şəbəkəsi ilə müqayisə edin. Üst-üstə düşmə sınıq DNS serverinə tam bənzəyən nasazlıq yaradır.
Konteynerin içində yoxlayın
Konteynerin içində brauzer və ya dil mühiti əvəzinə getent hosts db.internal ilə sınaqdan keçirin, çünki onlar öz DNS siyasətlərini və öz keşlərini tətbiq edir. Əgər getent adı həll edirsə və tətbiq hələ də uğursuz olursa, həlledici indi düzdür və qalan problem tətbiq səviyyəsindədir. Həll etmirsə, DNS addımı bitməyib.
DNS parametrlərini dəyişdikdən sonra konteyneri yenidən yaradın. İşləyən konteynerin içində /etc/resolv.conf faylını redaktə etmək onunla birlikdə yox olur və konfiqurasiya problemini kimsə onu yenidən başladana qədər gizlədir.