Hvers vegna Docker-gámar hunsa DNS-leysi VPN-sins

VPN er í gangi, vafrinn nær innri síðum, og gámurinn getur samt ekki leyst sömu nöfn. Uppsetning pakka deyr með nafnleysingarvillu eins og EAI_AGAIN, eða forrit finnur ekki gagnagrunnshýsil sem hýsilvélin leysir án nokkurrar kvörtunar. Gámurinn notar ekki leysinn sem VPN setti upp. Docker afritaði leysisstillingu hýsilsins þegar gámurinn var búinn til, og ekkert afritaði hana aftur eftir það.

Tvær sýnir á leysinum á einni vél

Á Linux gefur Docker hverjum gám afrit af leysisstillingu hýsilsins við sköpun, síar út loopback-vistföng og keyrir innbyggðan DNS-þjón á 127.0.0.11 sem sendir fyrirspurnir út. VPN-skjáborð sem endurskrifar /etc/resolv.conf eftir að gámurinn byrjaði breytir engu inni í honum. Endurræsing gámsins hjálpar aðeins ef leysir hýsilsins er fyrir tilviljun réttur á þeirri stundu.

Docker Desktop á macOS eða Windows bætir við lagi, því daemoninn býr í sýndarvél. Leysir VPN-sins á hýsilnum gæti aldrei orðið sýnilegur þeirri VM, svo endurræsing breytir engu. Berðu saman tvær sýnirnar áður en þú velur lausn: docker exec mycontainer cat /etc/resolv.conf við hlið leysilista hýsilsins.

Gámur sem listar opinberan leysi á meðan hýsillinn listar innri leysi mun leysa opinber nöfn og mistakast á innri. Sú skipting er undirskrift þessa vandamáls.

Valkostur A: senda leysi göngunnar fyrir hvern gám

Docker tekur við DNS-stillingum fyrir hvern gám, og það er minnsta breytingin sem virkar. Lestu fyrst leysisvistföng VPN-sins: scutil --dns á macOS, resolvectl status eða eigin stöðuúttak skjáborðsins á Linux. Ræstu svo gáminn með þeim, til dæmis docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. Í Compose er sama stilling listi undir þjónustunni, þar sem hún býr í útgáfustjórnun í stað skeljasögu einhvers.

Fylki dns í /etc/docker/daemon.json gildir fyrir hvern nýjan gám, sem hljómar snyrtilegra en er það ekki. Það gildir líka þegar göngin eru niðri, og leysir sem aðeins er hægt að ná í gegnum VPN eyðileggur þá venjulegan myndadrátt. Stillingar fyrir hvern gám eru auðveldari að rökstyðja og auðveldari að afturkalla.

Valkostur B: láta gáminn deila neti hýsilsins

Net hýsilsins sneiðir fram hjá afritinu alveg, því gámurinn notar leysi hýsilsins og göng hýsilsins. Það fjarlægir líka neteinangrunina sem þú vildir líklega, og það hegðar sér ekki eins undir Docker Desktop. Á Linux er það hagnýti kosturinn fyrir einskiptisverkfæri sem verður að leysa innri nöfn.

Fyrir byggingar gildir hvorugur kosturinn, því byggingarskref erfa ekki keyrslufána. Byggðu með neti hýsilsins þar sem vettvangurinn leyfir það, eða haltu uppsetningu háðra pakka í því stigi sem þarf ekki göngin.

Það sem hvorugur kosturinn lagar

DNS-vistfang er gagnslaust ef gámurinn hefur enga leið að því. Leysir VPN-sins situr venjulega innan vistfangarýmis göngunnar, svo gámurinn þarf slóð að því forskeyti. Sjálfgefna brú Docker beinir venjulega út um hýsilinn, og það nægir þegar hýsillinn hefur slóð göngunnar og framsending er virk. Sérsniðin brúarnet með eigin vistfangasöfnum geta rekist á VPN-undirnetið, og þá fara fyrirspurnirnar alveg annað.

Athugaðu undirnet Docker-netsins gegn undirneti VPN-sins áður en þú aflar villu í leysinum sjálfum. Skörun framleiðir bilun sem lítur nákvæmlega út eins og bilaður DNS-þjónn.

Sannprófaðu inni í gámnum

Prófaðu með getent hosts db.internal inni í gámnum í stað vafra eða tungumálakeyrslu, því þau beita eigin DNS-stefnu og eigin skyndiminni. Ef getent leysir nafnið og forritið mistekst samt, er Leysirinn nú réttur og vandamálið sem eftir er á forritastigi. Ef það leysir það ekki er DNS-skrefinu ekki lokið.

Búðu gáminn til aftur eftir að hafa breytt DNS-stillingum hans. Breyting á /etc/resolv.conf inni í gangandi gámi hverfur með honum og felur stillingarvandamálið nákvæmlega eins lengi og einhver þarf til að endurræsa hann.