Kial Docker-ujoj ignoras la DNS-riparilon de la VPN

La VPN funkcias, la retumilo atingas internajn retejojn, kaj la ujo ankoraŭ ne povas solvi la samajn nomojn. Paketa instalado mortas per nomsolva eraro kiel EAI_AGAIN, aŭ aplikaĵo ne trovas datumbazan gastiganton, kiun la gastiga maŝino solvas sen iu ajn plendo. La ujo ne uzas la riparilon, kiun la VPN instalis. Docker kopiis la riparilan agordon de la gastiganto kiam la ujo estis kreita, kaj nenio kopiis ĝin denove poste.

Du riparilaj vidpunktoj sur unu maŝino

En Linux, Docker donas al ĉiu ujo kopion de la riparila agordo de la gastiganto ĉe kreo, filtas loopback-adresojn kaj funkciigas enkonstruitan DNS-servilon ĉe 127.0.0.11, kiu plusendas demandojn eksteren. VPN-kliento, kiu reskribas /etc/resolv.conf post kiam la ujo startis, ŝanĝas nenion ene. Restartigi la ujon helpas nur se la gastiganta riparilo hazarde estas ĝusta en tiu momento.

Docker Desktop sur macOS aŭ Windows aldonas tavolon, ĉar la demono loĝas en virtuala maŝino. La VPN-riparilo de la gastiganto eble neniam videblas al tiu VM, do restartigo tute nenion ŝanĝas. Komparu la du vidpunktojn antaŭ ol elekti solvon: docker exec mycontainer cat /etc/resolv.conf apud la riparila listo de la gastiganto.

Ujo, kiu listigas publikan riparilon dum la gastiganto listigas internan, solvos publikajn nomojn kaj malsukcesos ĉe internaj. Tiu divido estas la subskribo de ĉi tiu problemo.

Opcio A: transdoni la tunelan riparilon por ĉiu ujo

Docker akceptas DNS-agordojn por ĉiu ujo, kaj tio estas la plej malgranda ŝanĝo, kiu funkcias. Unue legu la riparilajn adresojn de la VPN: scutil --dns sur macOS, resolvectl status aŭ la propra statusa eligo de la kliento sur Linux. Poste startigu la ujon kun ili, ekzemple docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. En Compose la sama agordo estas listo sub la servo, kie ĝi loĝas en versikontrolo anstataŭ en la ŝelhistorio de iu.

Tabelo dns en /etc/docker/daemon.json validas por ĉiu nova ujo, kio sonas pli ordema kaj ne estas. Ĝi validas ankaŭ kiam la tunelo estas malaktiva, kaj tiam riparilo atingebla nur tra la VPN rompas ordinarajn bildelŝutojn. Agordoj por ĉiu ujo estas pli facile pravigeblaj kaj pli facile malfareblaj.

Opcio B: lasi la ujon kunhavigi la reton de la gastiganto

Gastiganta retumado tute ĉirkaŭiras la kopion, ĉar la ujo uzas la riparilon de la gastiganto kaj la tunelon de la gastiganto. Ĝi ankaŭ forigas la retan izolitecon, kiun vi verŝajne volis, kaj ĝi ne kondutas same sub Docker Desktop. Sur Linux ĝi estas la pragmata elekto por unuafoja ilo, kiu devas solvi internajn nomojn.

Por konstruoj validas nek unu nek la alia opcio, ĉar konstruaj paŝoj ne heredas rultempajn flagojn. Konstruu kun gastiganta retumado, kie la platformo permesas tion, aŭ tenu la instaladon de dependaĵoj en etapo, kiu ne bezonas la tunelon.

Kion nek unu nek la alia opcio riparas

DNS-adreso estas senutila se la ujo ne havas itineron al ĝi. La VPN-riparilo kutime sidas ene de la adresspaco de la tunelo, do la ujo bezonas vojon al tiu prefikso. La defaŭta ponto de Docker normale enkursigas eksteren tra la gastiganto, kaj tio sufiĉas kiam la gastiganto havas la tunelan itineron kaj plusendado estas ŝaltita. Propraj pontaj retoj kun propraj adresujoj povas kolizii kun la VPN-subreto, kaj tiam demandoj iras tute aliloken.

Komparu la subreton de la Docker-reto kun la VPN-subreto antaŭ ol sencimigi la riparilon mem. Interkovro produktas malsukceson, kiu aspektas ĝuste kiel rompita DNS-servilo.

Kontrolu ene de la ujo

Testu per getent hosts db.internal ene de la ujo anstataŭ per retumilo aŭ lingva rultempo, ĉar tiuj aplikas sian propran DNS-politikon kaj sian propran kaŝmemoron. Se getent solvas la nomon kaj la aplikaĵo ankoraŭ malsukcesas, la riparilo nun estas ĝusta kaj la restanta problemo estas je aplikaĵa nivelo. Se ĝi ne solvas ĝin, la DNS-paŝo ne estas finita.

Rekreu la ujon post ŝanĝi ĝiajn DNS-agordojn. Redakti /etc/resolv.conf ene de funkcianta ujo malaperas kun ĝi kaj kaŝas la agordan problemon ĝuste tiom longe, kiom iu bezonas por restartigi ĝin.