Dlaczego kontener proxy nie używa automatycznie kontenera DNS

Uruchamianie proxy i serwera DNS na tym samym hoście Docker nie łączy ich ścieżek DNS. Znaczenie mają trzy odrębne relacje:

• Osiągalność sieci. Osobne projekty Compose mają zwykle osobne sieci domyślne. Umieść usługi w odpowiedniej współdzielonej sieci, albo w obrębie jednego projektu, albo poprzez sieć jawnie współdzieloną między projektami.
• Odkrywanie usług. Wbudowany DNS niestandardowej sieci Docker potrafi rozwiązywać nazwy kontenerów. To pozwala aplikacji odkryć sąsiada; nie wybiera go jednak automatycznie jako swojego resolvera DNS.
• Wybór resolvera. Ustal, jaki resolver jest używany wewnątrz kontenera proxy. Pole dns w Compose przyjmuje adresy serwerów DNS. Nazwa taka jak dns.local, która rozwiązuje się w aplikacji, nie staje się przez to prawidłową wartością tego pola.

Prześledź zapytanie od kontenera proxy do skonfigurowanego adresu resolvera. Potwierdź, że pod tym adresem istnieje trasa i nasłuch DNS. Opublikowanie portu 53 hosta tworzy ścieżkę dostępu po stronie hosta; nie mówi jednak kontenerom, że mają z niej korzystać. Kontenery współdzielące sieć mogą zamiast tego komunikować się bezpośrednio.

Jeśli konfiguracja odwołuje się do adresu kontenera DNS, utrzymuj go stabilnie w zgodnej konfiguracji IPAM. Dynamicznie przydzielony adres skopiowany z kontenera z wczoraj może zawieść przy odtworzeniu. Sprawdź także ścieżkę nadrzędną resolvera: przekazywanie nieodpowiedzianych zapytań z powrotem do niego samego tworzy inny błąd niż nieosiągalny resolver.

Na koniec ustal, kto rozwiązuje cel. Proxy HTTP rozwiązujące nazwę CONNECT może korzystać z tej ścieżki kontenera; klient SOCKS rozwiązujący lokalnie może już nie. Wyszukiwanie na hoście dowodzi trasy hosta, a nie trasy procesu proxy.