Varför en proxycontainer inte automatiskt använder DNS-containern

Att köra en proxy och en DNS-server på samma Docker-värd kopplar inte ihop deras DNS-vägar. Tre separata relationer spelar roll:

• Nätverksnåbarhet. Separata Compose-projekt har vanligtvis separata standardnätverk. Placera tjänsterna på ett lämpligt delat nätverk, antingen inom ett projekt eller via ett nätverk som uttryckligen delas mellan projekt.
• Tjänsteupptäckt. Den inbyggda DNS:en i ett anpassat Docker-nätverk kan lösa containernamn. Det låter en applikation upptäcka en granne; men den väljer inte automatiskt den grannen som sin DNS-resolver.
• Resolverval. Identifiera resolvern som används inuti proxycontainern. Fältet dns i Compose tar emot adresser till DNS-servrar. Ett namn som dns.local som löses i en applikation gör det inte till ett giltigt värde för det fältet.

Följ frågan från proxycontainern till dess konfigurerade resolveradress. Bekräfta att det finns en rutt och en DNS-lyssnare på den adressen. Att publicera värdport 53 skapar en åtkomstväg på värdsidan; men det säger inte till containrar att använda den. Containrar som delar ett nätverk kan i stället kommunicera direkt.

Om konfigurationen refererar till DNS-containerns adress, håll den stabil under kompatibel IPAM-konfiguration. En dynamiskt tilldelad adress kopierad från gårdagens container kan misslyckas vid återskapande. Granska också resolverns uppströmsväg: att skicka obesvarade frågor tillbaka till sig själv skapar ett annat fel än en onåbar resolver.

Till sist, identifiera vem som löser destinationen. En HTTP-proxy som löser ett CONNECT-namn kan använda denna containerbana; en SOCKS-klient som löser lokalt kanske inte. En uppslagning på värden bevisar värdens rutt, inte proxyprocessens.