Hvorfor en proxy-container ikke automatisk bruger DNS-containeren

At køre en proxy og en DNS-server på én Docker-vært forbinder ikke deres DNS-stier. Tre separate forhold er vigtige:

• Netværksrækkevidde. Separate Compose-projekter har normalt separate standardnetværk. Anbring tjenesterne på et passende delt netværk, enten inden for ét projekt eller via et netværk, der udtrykkeligt deles mellem projekter.
• Tjenesteopdagelse. En brugerdefineret Docker-netværks indlejrede DNS kan opløse containernavne. Det lader en applikation opdage en nabo; men den vælger ikke automatisk den nabo som sin DNS-resolver.
• Resolver-valg. Identificér den resolver, der bruges inde i proxy-containeren. Compose-feltet dns tager DNS-serveradresser. Et navn som dns.local, der opløses i en applikation, gør det ikke til en gyldig værdi for det felt.

Følg forespørgslen fra proxy-containeren til dens konfigurerede resolver-adresse. Bekræft en rute og en DNS-lytter på den adresse. At publicere værtsport 53 skaber en adgangsvej på værtsiden; det fortæller ikke containere, at de skal bruge den. Containere, der deler et netværk, kan i stedet kommunikere direkte.

Hvis konfigurationen refererer til DNS-containerens adresse, hold den stabil under kompatibel IPAM-konfiguration. En dynamisk tildelt adresse kopieret fra gårsdagens container kan fejle ved genskabelse. Undersøg også resolverens upstream-sti: at videresende ubesvarede forespørgsler tilbage til sig selv skaber en anden fejl end en utilgængelig resolver.

Til sidst skal du identificere, hvem der opløser destinationen. En HTTP-proxy, der opløser et CONNECT-navn, kan bruge denne container-sti; en SOCKS-klient, der opløser lokalt, måske ikke. En værtsopslag beviser værtens rute, ikke proxy-processens.