Per què un contenidor proxy no utilitza automàticament el contenidor DNS

Executar un proxy i un servidor DNS en un mateix amfitrió Docker no connecta les seves rutes DNS. Hi ha tres relacions separades que importen:

• Abast de xarxa. Els projectes Compose separats normalment tenen xarxes per defecte separades. Posa els serveis en una xarxa compartida adequada, ja sigui dins d'un projecte o mitjançant una xarxa explícitament compartida entre projectes.
• Descobriment de serveis. El DNS incrustat d'una xarxa Docker personalitzada pot resoldre noms de contenidors. Això permet que una aplicació descobreixi un veí; però no selecciona automàticament aquest veí com a resolutor DNS.
• Selecció del resolutor. Identifica el resolutor que s'utilitza dins del contenidor proxy. El camp dns de Compose accepta adreces de servidors DNS. Un nom com dns.local que es resol en una aplicació no el converteix en un valor vàlid per a aquest camp.

Segueix la consulta des del contenidor proxy fins a la seva adreça de resolutor configurada. Confirma que hi ha una ruta i un escoltador DNS en aquesta adreça. Publicar el port 53 de l'amfitrió crea un camí d'accés des del costat de l'amfitrió; però no diu als contenidors que l'utilitzin. Els contenidors que comparteixen xarxa poden, en canvi, comunicar-se directament.

Si la configuració fa referència a l'adreça del contenidor DNS, mantén-la estable amb una configuració IPAM compatible. Una adreça assignada dinàmicament i copiada del contenidor d'ahir pot fallar en recrear-lo. Inspecciona també la ruta ascendent del resolutor: reenviar consultes sense resposta cap a ell mateix crea una fallada diferent de la d'un resolutor inabastable.

Finalment, identifica qui resol la destinació. Un proxy HTTP que resol un nom CONNECT pot utilitzar aquest camí pel contenidor; un client SOCKS que resol localment potser no. Una consulta a l'amfitrió demostra la ruta de l'amfitrió, no la del procés del proxy.