Hvorfor en proxy-container ikke bruker DNS-containeren automatisk

Å dele en Docker-vert, dele et nettverk og velge en resolver er tre forskjellige ting. Følg DNS-spørringen fra innsiden av proxyen.

Å kjøre en proxy og en DNS-server på samme Docker-vert kobler ikke DNS-banene deres. Tre atskilte forhold er viktige:

  • Nettverksrekkevidde. Separate Compose-prosjekter har vanligvis separate standardnettverk. Sett tjenestene på et egnet delt nettverk, enten innenfor ett prosjekt eller via et nettverk som eksplisitt deles mellom prosjekter.
  • Tjenesteoppdagelse. Den innebygde DNS-en i et tilpasset Docker-nettverk kan slå opp containernavn. Det lar en applikasjon oppdage en nabo; men den velger ikke automatisk den naboen som sin DNS-resolver.
  • Resolver-valg. Identifiser resolveren som brukes inne i proxy-containeren. Feltet dns i Compose tar imot DNS-serveradresser. Et navn som dns.local som slås opp i en applikasjon gjør det ikke til en gyldig verdi for det feltet.

Følg spørringen fra proxy-containeren til dens konfigurerte resolveradresse. Bekreft at det finnes en rute og en DNS-lytter på den adressen. Å publisere vertsport 53 lager en tilgangsvei på vertssiden; men det forteller ikke containere at de skal bruke den. Containere som deler et nettverk kan i stedet kommunisere direkte.

Hvis konfigurasjonen refererer til DNS-containerens adresse, hold den stabil under kompatibel IPAM-konfigurasjon. En dynamisk tildelt adresse kopiert fra gårsdagens container kan feile ved gjenoppretting. Undersøk også resolverens oppstrømsbane: å sende ubesvarte spørringer tilbake til seg selv skaper en annen feil enn en utilgjengelig resolver.

Til slutt, identifiser hvem som slår opp målet. En HTTP-proxy som slår opp et CONNECT-navn kan bruke denne containerbanen; en SOCKS-klient som slår opp lokalt kanskje ikke. Et vertsoppslag beviser vertens rute, ikke proxyprosessens.

Relaterte artikler