Perché un container proxy non usa automaticamente il container DNS
Condividere un host Docker, condividere una rete e scegliere un resolver sono tre disposizioni diverse. Segui la query DNS dall'interno del proxy.
Eseguire un proxy e un server DNS sullo stesso host Docker non collega i loro percorsi DNS. Contano tre relazioni separate:
- Raggiungibilità di rete. Progetti Compose separati hanno di solito reti predefinite separate. Metti i servizi su una rete condivisa adeguata, all'interno di un progetto oppure tramite una rete esplicitamente condivisa tra progetti.
- Scoperta dei servizi. Il DNS incorporato di una rete Docker personalizzata può risolvere i nomi dei container. Questo consente a un'applicazione di scoprire un vicino; ma non seleziona automaticamente quel vicino come proprio resolver DNS.
- Scelta del resolver. Identifica il resolver usato dentro il container proxy. Il campo
dnsdi Compose accetta indirizzi di server DNS. Un nome comedns.localche si risolve in un'applicazione non lo rende un valore valido per quel campo.
Segui la query dal container proxy fino al suo indirizzo di resolver configurato. Verifica che a quell'indirizzo esistano una rotta e un listener DNS. Pubblicare la porta 53 dell'host crea un percorso di accesso lato host; ma non dice ai container di usarlo. I container che condividono una rete possono invece comunicare direttamente.
Se la configurazione fa riferimento all'indirizzo del container DNS, mantienilo stabile con una configurazione IPAM compatibile. Un indirizzo assegnato dinamicamente e copiato dal container di ieri può fallire alla ricreazione. Esamina anche il percorso a monte del resolver: rinviare le query senza risposta a se stesso crea un guasto diverso da un resolver irraggiungibile.
Infine, identifica chi risolve la destinazione. Un proxy HTTP che risolve un nome CONNECT può usare questo percorso del container; un client SOCKS che risolve localmente potrebbe non farlo. Una ricerca sull'host dimostra la rotta dell'host, non quella del processo proxy.