Waarom Docker-houers die VPN se DNS-oplosser ignoreer
’n Houer kopieer die gasheer se oplosser wanneer dit begin, so ’n VPN wat DNS later herskryf bly onsigbaar daarbinne. Gee die oplosser eksplisiet deur.
Die VPN is op, die blaaier bereik interne werwe, en die houer kan steeds nie dieselfde name oplos nie. ’n Pakketinstallasie sterf met ’n naamoplossingsfout soos EAI_AGAIN, of ’n toepassing kan nie ’n databasishost vind wat die gasheermasjien sonder klag oplos nie. Die houer gebruik nie die oplosser wat die VPN geïnstalleer het nie. Docker het die gasheer se oplosserkonfigurasie gekopieer toe die houer geskep is, en niks het dit daarna weer gekopieer nie.
Twee oplosseraansigte op een masjien
Op Linux gee Docker elke houer ’n kopie van die gasheer se oplosserkonfigurasie op die oomblik van skepping, filter loopback-adresse uit, en bedryf ’n ingebedde DNS-bediener by 127.0.0.11 wat navrae uitwaarts aanstuur. ’n VPN-kliënt wat /etc/resolv.conf herskryf nadat die houer begin het, verander niks daarbinne nie. Om die houer te herbegin help net as die gasheeroplosser op daardie oomblik toevallig korrek is.
Docker Desktop op macOS of Windows voeg ’n laag by, want die daemon woon in ’n virtuele masjien. Die gasheer se VPN-oplosser is dalk nooit vir daardie VM sigbaar nie, so herbegin verander glad niks. Vergelyk die twee aansigte voordat jy ’n oplossing kies: docker exec mycontainer cat /etc/resolv.conf langs die gasheer se oplosserlys.
’n Houer wat ’n publieke oplosser lys terwyl die gasheer ’n interne een lys, sal publieke name oplos en interne name misluk. Daardie splitsing is die kenmerk van hierdie probleem.
Opsie A: gee die tonneloplosser per houer deur
Docker aanvaar DNS-instellings per houer, wat die kleinste verandering is wat werk. Lees eers die VPN se oplosseradresse: scutil --dns op macOS, resolvectl status of die kliënt se eie statusuitvoer op Linux. Begin dan die houer daarmee, byvoorbeeld docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage. In Compose is dieselfde instelling ’n lys onder die diens, waar dit in weergawebeheer woon eerder as in iemand se skulphistorie.
’n dns-skikking in /etc/docker/daemon.json geld vir elke nuwe houer, wat netjieser klink en dit nie is nie. Dit geld ook wanneer die tonnel af is, en ’n oplosser wat net deur die VPN bereikbaar is, breek dan gewone beeldtrekkings. Instellings per houer is makliker om te beredeneer en makliker om ongedaan te maak.
Opsie B: laat die houer die gasheernetwerk deel
Gasheernetwerking omseil die kopie heeltemal, want die houer gebruik die gasheer se oplosser en die gasheer se tonnel. Dit verwyder ook die netwerkietsheid wat jy waarskynlik wou hê, en dit werk nie dieselfde onder Docker Desktop nie. Op Linux is dit die pragmatiese keuse vir ’n eenmalige instrument wat interne name moet oplos.
Vir bouwerk geld nie een van die twee opsies nie, want boustappe erf nie looptydvlaggies nie. Bou met gasheernetwerking waar die platform dit toelaat, of hou afhanklikheidsinstallering in ’n stadium wat nie die tonnel nodig het nie.
Wat nie een van die opsies regmaak nie
’n DNS-adres is nutteloos as die houer geen roete daarheen het nie. Die VPN-oplosser sit gewoonlik binne die tonnel se adresruimte, so die houer het ’n pad na daardie voorvoegsel nodig. Docker se verstekbrug lei normaalweg deur die gasheer uit, wat genoeg is wanneer die gasheer die tonnelroete het en aanstuur ingeskakel is. Pasgemaakte brugnetwerke met hul eie adrespoele kan met die VPN-subnet bots, en dan gaan navrae heeltemal elders heen.
Kontroleer die Docker-netwerksubnet teen die VPN-subnet voordat jy die oplosser self ontfout. Oorvleueling lewer ’n fout wat presies soos ’n stukkende DNS-bediener lyk.
Verifieer binne die houer
Toets met getent hosts db.internal binne die houer eerder as met ’n blaaier of ’n taal-tydloop, want dié pas hul eie DNS-beleid en hul eie kas toe. As getent die naam oplos en die toepassing misluk steeds, is die oplosser nou korrek en is die oorblywende probleem op toepassingsvlak. As dit nie oplos nie, is die DNS-stap nie klaar nie.
Herstel die houer nadat jy sy DNS-instellings verander het. Om /etc/resolv.conf binne ’n lopende houer te wysig, verdwyn saam met hom en verberg die konfigurasieprobleem vir presies so lank as wat dit iemand neem om hom te herbegin.