Zakaj vsebniki Dockerja ignorirajo DNS razreševalnik VPN

VPN deluje, brskalnik doseže notranje strani, vsebnik pa še vedno ne more razrešiti istih imen. Namestitev paketa umre z napako razreševanja imen, kot je EAI_AGAIN, ali aplikacija ne najde gostitelja podatkovne baze, ki ga gostiteljski stroj razreši brez vsake pritožbe. Vsebnik ne uporablja razreševalnika, ki ga je namestil VPN. Docker je kopiral konfiguracijo razreševalnika gostitelja ob ustvarjanju vsebnika, in zatem je ni nič znova kopiralo.

Dva pogleda na razreševalnik na enem stroju

V Linuxu Docker ob ustvarjanju da vsakemu vsebniku kopijo konfiguracije razreševalnika gostitelja, izloči naslove loopback in zažene vgrajeni strežnik DNS na 127.0.0.11, ki poizvedbe posreduje navzven. Odjemalec VPN, ki prepiše /etc/resolv.conf po zagonu vsebnika, v njem ne spremeni ničesar. Ponovni zagon vsebnika pomaga le, če je razreševalnik gostitelja v tistem trenutku slučajno pravilen.

Docker Desktop v macOS ali Windows doda plast, ker demon živi v navidezni napravi. Razreševalnik VPN gostitelja morda nikoli ne bo viden tej VM, zato ponovni zagon ne spremeni prav ničesar. Primerjajte oba pogleda, preden izberete rešitev: docker exec mycontainer cat /etc/resolv.conf ob seznamu razreševalnikov gostitelja.

Vsebnik, ki navaja javni razreševalnik, medtem ko gostitelj navaja notranjega, bo razrešil javna imena in spodletel pri notranjih. Ta razcep je podpis te težave.

Možnost A: posredovanje razreševalnika tunela za vsak vsebnik

Docker sprejema nastavitve DNS za vsak vsebnik, in to je najmanjša sprememba, ki deluje. Najprej preberite naslove razreševalnika VPN: scutil --dns v macOS, resolvectl status ali lasten statusni izhod odjemalca v Linuxu. Nato zaženite vsebnik z njimi, na primer docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. V Composeu je ista nastavitev seznam pod storitvijo, kjer živi v nadzoru različic namesto v nečiji zgodovini lupine.

Polje dns v /etc/docker/daemon.json velja za vsak nov vsebnik, kar zveni bolj urejeno, kot je. Velja tudi, ko je tunel mrtev, in razreševalnik, dosegljiv le prek VPN, takrat pokvari običajno vlečenje slik. Nastavitve za posamezen vsebnik je lažje utemeljiti in lažje razveljaviti.

Možnost B: vsebnik naj si deli omrežje gostitelja

Omrežje gostitelja popolnoma obide kopijo, ker vsebnik uporablja razreševalnik gostitelja in tunel gostitelja. Odstrani pa tudi omrežno izolacijo, ki ste jo verjetno želeli, in se pod Docker Desktop ne obnaša enako. V Linuxu je to pragmatična izbira za enkratno orodje, ki mora razreševati notranja imena.

Za gradnje ne velja nobena od obeh možnosti, ker koraki gradnje ne podedujejo zastavic izvajalnega časa. Gradite z omrežjem gostitelja tam, kjer platforma to dovoli, ali hranite namestitev odvisnosti v fazi, ki tunela ne potrebuje.

Česa nobena možnost ne odpravi

Naslov DNS je neuporaben, če vsebnik nima poti do njega. Razreševalnik VPN običajno sedi v naslovnem prostoru tunela, zato vsebnik potrebuje pot do te predpone. Privzeti most Dockerja običajno usmerja navzven skozi gostitelja, in to zadostuje, kadar ima gostitelj pot tunela in je posredovanje omogočeno. Mostovna omrežja po meri z lastnimi bazeni naslovov se lahko zaletijo v podomrežje VPN, in takrat poizvedbe odidejo povsem drugam.

Pred razhroščevanjem samega razreševalnika primerjajte podomrežje omrežja Docker s podomrežjem VPN. Prekrivanje ustvari okvaro, ki je videti natanko kot pokvarjen strežnik DNS.

Preverite znotraj vsebnika

Preizkusite z getent hosts db.internal znotraj vsebnika, ne z brskalnikom ali jezikovnim izvajalnim okoljem, ker ta uveljavljata svojo politiko DNS in svoj predpomnilnik. Če getent razreši ime in aplikacija še vedno spodleti, je razreševalnik zdaj pravilen in preostala težava je na ravni aplikacije. Če ga ne razreši, korak DNS ni končan.

Po spremembi nastavitev DNS vsebnik znova ustvarite. Urejanje /etc/resolv.conf v delujočem vsebniku izgine z njim in skrije težavo s konfiguracijo natanko toliko časa, kolikor ga nekdo potrebuje za ponovni zagon.