Miért hagyják figyelmen kívül a Docker-tárolók a VPN DNS-feloldóját

A VPN fut, a böngésző eléri a belső oldalakat, a tároló mégsem tudja feloldani ugyanazokat a neveket. Egy csomagtelepítés névfeloldási hibával hal meg, például EAI_AGAIN, vagy egy alkalmazás nem talál olyan adatbázis-gazdagépet, amelyet a gazdagép gép panasz nélkül felold. A tároló nem a VPN által telepített feloldót használja. A Docker a tároló létrehozásakor lemásolta a gazdagép feloldókonfigurációját, és utána semmi nem másolta le újra.

Két feloldónézet egy gépen

Linuxon a Docker létrehozáskor minden tárolónak ad egy másolatot a gazdagép feloldókonfigurációjáról, kiszűri a loopback-címeket, és egy beágyazott DNS-kiszolgálót futtat a 127.0.0.11 címen, amely kifelé továbbítja a lekérdezéseket. Egy VPN-kliens, amely a tároló indulása után átírja a /etc/resolv.conf fájlt, semmit nem változtat azon belül. A tároló újraindítása csak akkor segít, ha a gazdagép feloldója abban a pillanatban véletlenül helyes.

A macOS vagy Windows alatti Docker Desktop egy réteget ad hozzá, mert a démon virtuális gépen él. Előfordulhat, hogy a gazdagép VPN-feloldója soha nem látható annak a VM-nek, így az újraindítás semmit sem változtat. Hasonlítsa össze a két nézetet, mielőtt megoldást választ: docker exec mycontainer cat /etc/resolv.conf a gazdagép feloldólistája mellett.

Az a tároló, amely nyilvános feloldót sorol fel, miközben a gazdagép belsőt sorol fel, feloldja a nyilvános neveket, és elbukik a belsőkön. Ez a kettősség a probléma aláírása.

A lehetőség: az alagút feloldójának átadása tárolónként

A Docker elfogad tárolónkénti DNS-beállításokat, és ez a legkisebb működő változtatás. Először olvassa ki a VPN feloldócímeit: scutil --dns macOS-en, resolvectl status vagy a kliens saját állapotkimenete Linuxon. Ezután indítsa el a tárolót ezekkel, például docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. A Compose-ban ugyanez a beállítás a szolgáltatás alatti lista, ahol verziókezelésben él, nem valakinek a shell-előzményeiben.

A /etc/docker/daemon.json fájlban lévő dns tömb minden új tárolóra érvényes, ami rendezettebbnek hangzik, mint amilyen. Akkor is érvényes, amikor az alagút áll, és egy csak a VPN-en át elérhető feloldó ilyenkor elrontja a szokásos image-letöltéseket. A tárolónkénti beállításokat könnyebb megindokolni és könnyebb visszavonni.

B lehetőség: a tároló ossza meg a gazdagép hálózatát

A gazdagép hálózata teljesen megkerüli a másolatot, mert a tároló a gazdagép feloldóját és a gazdagép alagútját használja. Eltávolítja azt a hálózati elkülönítést is, amelyet valószínűleg szeretett volna, és a Docker Desktop alatt nem viselkedik ugyanígy. Linuxon ez a pragmatikus választás egy egyszeri eszközhöz, amelynek belső neveket kell feloldania.

Buildeléshez egyik lehetőség sem alkalmazható, mert a build-lépések nem öröklik a futásidejű kapcsolókat. Ott buildeljen gazdagép-hálózattal, ahol a platform engedi, vagy tartsa a függőségek telepítését olyan szakaszban, amelynek nincs szüksége az alagútra.

Amit egyik lehetőség sem javít meg

A DNS-cím haszontalan, ha a tárolónak nincs útvonala hozzá. A VPN feloldója általában az alagút címtartományában ül, ezért a tárolónak útvonalra van szüksége ahhoz az előtaghoz. A Docker alapértelmezett hídja általában a gazdagépen keresztül irányít kifelé, és ez elég, ha a gazdagép rendelkezik az alagút útvonalával, és a továbbítás engedélyezett. A saját címkészletekkel rendelkező egyedi hídhálózatok ütközhetnek a VPN alhálózatával, és akkor a lekérdezések egészen máshová mennek.

A feloldó hibakeresése előtt hasonlítsa össze a Docker-hálózat alhálózatát a VPN alhálózatával. Az átfedés olyan hibát eredményez, amely pontosan egy tönkrement DNS-kiszolgálóra hasonlít.

Ellenőrzés a tárolón belül

A tárolón belül a getent hosts db.internal paranccsal teszteljen, ne böngészővel vagy nyelvi futtatókörnyezettel, mert azok a saját DNS-szabályzatukat és a saját gyorsítótárukat alkalmazzák. Ha a getent feloldja a nevet, és az alkalmazás még mindig elbukik, a feloldó most helyes, és a fennmaradó probléma alkalmazásszintű. Ha nem oldja fel, a DNS-lépés nincs befejezve.

A DNS-beállítások módosítása után hozza létre újra a tárolót. A /etc/resolv.conf szerkesztése egy futó tárolóban eltűnik vele együtt, és pontosan addig rejti el a konfigurációs problémát, ameddig valakinek újra kell indítania.