Waarom een proxycontainer niet automatisch de DNS-container gebruikt

Een proxy en een DNS-server op dezelfde Docker-host draaien verbindt hun DNS-paden niet. Drie afzonderlijke relaties zijn van belang:

• Netwerkbereikbaarheid. Afzonderlijke Compose-projecten hebben meestal afzonderlijke standaardnetwerken. Plaats de services op een geschikt gedeeld netwerk, hetzij binnen één project of via een netwerk dat expliciet tussen projecten wordt gedeeld.
• Servicedetectie. De ingebouwde DNS van een aangepast Docker-netwerk kan containernamen resolven. Daardoor kan een applicatie een buur ontdekken; maar die buur wordt niet automatisch als DNS-resolver gekozen.
• Resolverkeuze. Identificeer de resolver die in de proxycontainer wordt gebruikt. Het veld dns van Compose accepteert adressen van DNS-servers. Een naam zoals dns.local die in een applicatie resolveert, maakt hem nog geen geldige waarde voor dat veld.

Volg de query van de proxycontainer naar het geconfigureerde resolveradres. Bevestig dat daar een route en een DNS-listener aanwezig zijn. Het publiceren van hostpoort 53 maakt een toegangspad aan de hostzijde; het vertelt containers niet dat ze het moeten gebruiken. Containers die een netwerk delen, kunnen in plaats daarvan rechtstreeks communiceren.

Als de configuratie verwijst naar het adres van de DNS-container, houd het dan stabiel onder een compatibele IPAM-configuratie. Een dynamisch toegewezen adres dat van de container van gisteren is gekopieerd, kan bij hercreatie falen. Onderzoek ook het upstreampad van de resolver: onbeantwoorde queries terugsturen naar zichzelf veroorzaakt een ander falen dan een onbereikbare resolver.

Identificeer ten slotte wie de bestemming resolvet. Een HTTP-proxy die een CONNECT-naam resolvet kan dit containerpad gebruiken; een SOCKS-client die lokaal resolvet misschien niet. Een lookup op de host bewijst de route van de host, niet die van het proxyproces.