Wêrom't in proxy-kontener net automatysk de DNS-kontener brûkt

In proxy en in DNS-tsjinner op ien Docker-host draaie ferbynt har DNS-paden net. Trije aparte relaasjes binne wichtich:

• Netwurkberikberens. Aparte Compose-projekten hawwe normaal aparte standertnetwurken. Set de tsjinsten op in geskikt dield netwurk, itsij binnen ien projekt itsij fia in netwurk dat eksplisyt dield wurdt tusken projekten.
• Tsjinstûntdekking. De ynboude DNS fan in oanpast Docker-netwurk kin kontenernammen oplosse. Dat lit in applikaasje in buorman ûntdekke; mar it selektearret dy buorman net automatysk as syn DNS-resolver.
• Resolverkar. Identifisearje de resolver dy't binnen de proxy-kontener brûkt wurdt. It fjild dns fan Compose nimt adressen fan DNS-tsjinners oan. In namme lykas dns.local dy't yn in applikaasje oplost, makket it noch gjin jildige wearde foar dat fjild.

Folgje de fraach fan de proxy-kontener nei syn konfigurearre resolveradres. Befestigje dat dêr in rûte en in DNS-luisterer binne. It publisearjen fan hostpoarte 53 makket in tagongspaad oan de hostkant; it fertelt konteners net dat se it brûke moatte. Konteners dy't in netwurk diele kinne ynstee direkt kommunisearje.

As de konfiguraasje it adres fan de DNS-kontener neamt, hâld it dan stabyl ûnder kompatibele IPAM-konfiguraasje. In dynamysk tawiisd adres dat fan de kontener fan juster kopiearre is, kin by it opnij oanmeitsjen misse. Undersykje ek it opstreampaad fan de resolver: net-beantwurde fragen weromstjoere nei himsels makket in oare flater as in net berikbere resolver.

Ta beslút: identifisearje wa't de bestimming oplost. In HTTP-proxy dy't in CONNECT-namme oplost kin dit kontenerpaad brûke; in SOCKS-klant dy't lokaal oplost miskien net. In host-sykjen bewiist de rûte fan de host, net dy fan it proxy-proses.