Waarom 'n proxy-houer nie outomaties die DNS-houer gebruik nie

Om 'n proxy en 'n DNS-bediener op een Docker-gasheer te laat loop, verbind nie hulle DNS-paaie nie. Drie afsonderlike verwantskappe is belangrik:

• Netwerkbereikbaarheid. Afsonderlike Compose-projekte het gewoonlik afsonderlike versteknetwerke. Plaas die dienste op 'n geskikte gedeelde netwerk, hetsy binne een projek of deur 'n eksplisiet gedeelde netwerk tussen projekte.
• Diensontdekking. 'n Pasgemaakte Docker-netwerk se ingebedde DNS kan houernames oplos. Dit laat 'n toepassing 'n buur ontdek; dit kies nie outomaties daardie buur as sy DNS-oplosser nie.
• Oplosserkeuse. Identifiseer die oplosser wat binne die proxy-houer gebruik word. Compose se dns-veld neem DNS-bedieneradresse. 'n Naam soos dns.local wat in 'n toepassing oplos, maak dit nie 'n geldige waarde vir daardie veld nie.

Volg die navraag van die proxy-houer na sy gekonfigureerde oplosseradres. Bevestig 'n roete en 'n DNS-luisteraar by daardie adres. Om gasheerpoort 53 te publiseer skep 'n toegangspad aan die gasheerkant; dit sê nie vir houers om dit te gebruik nie. Houers wat 'n netwerk deel, kan eerder direk kommunikeer.

As die konfigurasie na die DNS-houer se adres verwys, hou dit stabiel onder versoenbare IPAM-konfigurasie. 'n Dinamies toegekende adres wat van gister se houer gekopieer is, kan by herskeping misluk. Ondersoek ook die oplosser se opstroom-pad: om onbeantwoorde navrae na homself terug te stuur, skep 'n ander faling as 'n onbereikbare oplosser.

Laastens, identifiseer wie die bestemming oplos. 'n HTTP-proxy wat 'n CONNECT-naam oplos, kan hierdie houerpad gebruik; 'n SOCKS-kliënt wat plaaslik oplos, miskien nie. 'n Gasheeropsoeking bewys die gasheer se roete, nie dié van die proxy-proses nie.