De ce un container proxy nu folosește automat containerul DNS

Rularea unui proxy și a unui server DNS pe aceeași gazdă Docker nu le conectează căile DNS. Contează trei relații separate:

• Accesibilitatea rețelei. Proiectele Compose separate au de obicei rețele implicite separate. Plasați serviciile într-o rețea partajată adecvată, fie în cadrul unui proiect, fie printr-o rețea partajată explicit între proiecte.
• Descoperirea serviciilor. DNS-ul încorporat al unei rețele Docker personalizate poate rezolva numele containerelor. Astfel o aplicație poate descoperi un vecin; dar nu îl selectează automat pe acel vecin drept resolver DNS.
• Alegerea resolverului. Identificați resolverul folosit în containerul proxy. Câmpul dns din Compose acceptă adrese de servere DNS. Un nume precum dns.local care se rezolvă într-o aplicație nu îl face o valoare validă pentru acel câmp.

Urmăriți interogarea de la containerul proxy până la adresa resolverului configurat. Confirmați că la acea adresă există o rută și un ascultător DNS. Publicarea portului 53 al gazdei creează o cale de acces pe partea gazdei; dar nu le spune containerelor să o folosească. Containerele care partajează o rețea pot comunica direct în schimb.

Dacă configurația face referire la adresa containerului DNS, mențineți-o stabilă într-o configurație IPAM compatibilă. O adresă alocată dinamic și copiată din containerul de ieri poate eșua la recreare. Inspectați și calea amonte a resolverului: retransmiterea interogărilor fără răspuns către el însuși creează o altă defecțiune decât un resolver inaccesibil.

În final, identificați cine rezolvă destinația. Un proxy HTTP care rezolvă un nume CONNECT poate folosi această cale prin container; un client SOCKS care rezolvă local s-ar putea să nu o facă. O căutare pe gazdă dovedește ruta gazdei, nu pe cea a procesului proxy.