Kvifor Docker-containarar ignorerer DNS-resolveren til VPN-en

VPN-en er oppe, nettlesaren når interne sider, og containeren kan framleis ikkje slå opp dei same namna. Ein pakkeinstallasjon døyr med ein namneoppslagsfeil som EAI_AGAIN, eller eit program finn ikkje ein databasevert som vertsmaskina slår opp utan klager. Containeren brukar ikkje resolveren som VPN-en installerte. Docker kopierte resolverkonfigurasjonen til verten då containeren vart oppretta, og ingenting kopierte han igjen etterpå.

To resolver-visningar på éi maskin

På Linux gir Docker kvar container ein kopi av resolverkonfigurasjonen til verten ved opprettinga, filtrerer bort loopback-adresser og køyrer ein innebygd DNS-server på 127.0.0.11 som videresender spørjingar ut. Ein VPN-klient som skriv om /etc/resolv.conf etter at containeren er starta, endrar ingenting inni han. Å starte containeren på nytt hjelper berre om resolveren til verten tilfeldigvis er riktig i det augneblunken.

Docker Desktop på macOS eller Windows legg til eit lag, fordi daemonen bur i ein virtuell maskin. Resolveren til VPN-en på verten er kanskje aldri synleg for den VM-en, så ein omstart endrar ingenting i det heile. Samanlikn dei to visningane før du vel ei løysing: docker exec mycontainer cat /etc/resolv.conf ved sida av resolverlista til verten.

Ein container som listar ein offentleg resolver medan verten listar ein intern, vil slå opp offentlege namn og feile på interne. Den delinga er signaturen på dette problemet.

Alternativ A: send tunnelresolveren vidare per container

Docker godtek DNS-innstillingar per container, og det er den minste endringa som verkar. Les først resolveradressene til VPN-en: scutil --dns på macOS, resolvectl status eller den eigne statusutskrifta til klienten på Linux. Start deretter containeren med dei, til dømes docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. I Compose er den same innstillinga ei liste under tenesta, der ho bur i versjonskontroll i staden for i shell-historia til nokon.

Ein dns-matrise i /etc/docker/daemon.json gjeld for kvar ny container, noko som høyrest ryddigare ut enn det er. Han gjeld òg når tunnelen er nede, og ein resolver som berre er nåbar via VPN-en øydelegg då vanlege image-hentingar. Innstillingar per container er lettare å grunngje og lettare å angre.

Alternativ B: lat containeren dele nettverket til verten

Vertsnettverk går heilt utanom kopien, fordi containeren brukar resolveren til verten og tunnelen til verten. Det fjernar òg nettverksisoleringa du sannsynlegvis ville ha, og det oppfører seg ikkje likt under Docker Desktop. På Linux er det det pragmatiske valet for eit eingongsverktøy som må slå opp interne namn.

For bygg gjeld ingen av alternativa, sidan byggesteg ikkje arvar køyretidsflagg. Bygg med vertsnettverk der plattforma tillèt det, eller hald installasjonen av avhengnader i eit steg som ikkje treng tunnelen.

Kva ingen av alternativa fiksar

Ei DNS-adresse er unytteleg om containeren ikkje har rute til ho. Resolveren til VPN-en sit vanlegvis inne i adresserommet til tunnelen, så containeren treng ein veg til det prefikset. Standardbrua til Docker rutar vanlegvis ut gjennom verten, og det er nok når verten har tunnelruta og videresending er slått på. Eigendefinerte brunettverk med eigne adressebasseng kan kollidere med subnettet til VPN-en, og då går spørjingane ein heilt annan stad.

Sjekk subnettet til Docker-nettverket mot subnettet til VPN-en før du feilsøkjer sjølve resolveren. Overlapp gjev ein feil som ser nøyaktig ut som ein øydelagd DNS-server.

Stadfest inne i containeren

Test med getent hosts db.internal inne i containeren i staden for med ein nettlesar eller ein språkruntime, fordi dei brukar si eiga DNS-policy og sin eigen hurtigbuffer. Viss getent slår opp namnet og programmet framleis feilar, er resolveren no riktig og det gjenverande problemet er på programnivå. Viss han ikkje slår det opp, er DNS-steget ikkje ferdig.

Lag containeren på nytt etter at du har endra DNS-innstillingane hans. Redigering av /etc/resolv.conf inne i ein køyrande container forsvinn med han og skjuler konfigurasjonsproblemet nøyaktig så lenge som nokon treng for å starte han på nytt.