Kvifor ein proxy-container ikkje automatisk brukar DNS-containeren

Å køyra ein proxy og ein DNS-tenar på same Docker-vert knyter ikkje DNS-banane deira saman. Tre skilde tilhøve er viktige:

• Nettverkstilgjenge. Skilde Compose-prosjekt har vanlegvis skilde standardnettverk. Set tenestene på eit høveleg delt nettverk, anten innanfor eitt prosjekt eller via eit nettverk som er uttrykkeleg delt mellom prosjekt.
• Tenestefinning. Den innebygde DNS-en i eit tilpassa Docker-nettverk kan slå opp containernamn. Det lèt ein applikasjon oppdaga ein nabo; men han vel ikkje automatisk den naboen som DNS-resolveren sin.
• Resolver-val. Identifiser resolveren som vert brukt inne i proxy-containeren. Feltet dns i Compose tek imot DNS-tenaradresser. Eit namn som dns.local som vert slått opp i ein applikasjon gjer det ikkje til ein gyldig verdi for det feltet.

Følg førespurnaden frå proxy-containeren til den konfigurerte resolveradressa hans. Stadfest at det finst ei rute og ein DNS-lyttar på den adressa. Å publisera vertsport 53 lagar ein tilgangsveg på vertssida; men det fortel ikkje containarar at dei skal bruka han. Containarar som deler eit nettverk kan i staden kommunisera direkte.

Viss konfigurasjonen viser til adressa til DNS-containeren, hald henne stabil under kompatibel IPAM-konfigurasjon. Ei dynamisk tildelt adresse kopiert frå containeren i går kan feila ved attskaping. Gransk òg oppstraumsbanen til resolveren: å senda ubesvarte førespurnader tilbake til han sjølv skapar ein annan feil enn ein utilgjengeleg resolver.

Til slutt, identifiser kven som slår opp målet. Ein HTTP-proxy som slår opp eit CONNECT-namn kan bruka denne containerbanen; ein SOCKS-klient som slår opp lokalt kanskje ikkje. Eit vertsoppslag provar ruta til verten, ikkje den til proxyprosessen.