Чаму кантэйнер проксі не выкарыстоўвае кантэйнер DNS аўтаматычна

Запуск проксі і DNS-сервера на адным хосце Docker не звязвае іх шляхі DNS. Важныя тры асобныя сувязі:

• Дасягальнасць сеткі. Асобныя праекты Compose звычайна маюць асобныя прадвызначаныя сеткі. Размясціце сэрвісы ў адпаведнай агульнай сетцы — ці ўнутры аднаго праекта, ці праз сетку, яўна агульную паміж праектамі.
• Выяўленне сэрвісаў. Убудаваны DNS уласнай сеткі Docker можа разрозніваць імёны кантэйнераў. Гэта дазваляе праграме выявіць суседа; але яно не выбірае гэтага суседа сваім рэзалверам DNS аўтаматычна.
• Выбар рэзалвера. Вызначце рэзалвер, які выкарыстоўваецца ўнутры кантэйнера проксі. Поле dns у Compose прымае адрасы DNS-сервераў. Імя накшталт dns.local, якое разрозніваецца ў праграме, не робіць яго дапушчальным значэннем для гэтага поля.

Прасачыце запыт ад кантэйнера проксі да яго настроенага адраса рэзалвера. Пацвердзіце наяўнасць маршруту і слухача DNS па гэтым адрасе. Публікацыя порта 53 на хосце стварае шлях доступу з боку хоста; яна не паведамляе кантэйнерам, што ім трэба ім карыстацца. Кантэйнеры, якія дзеляць сетку, могуць замест гэтага ўзаемадзейнічаць напрамую.

Калі канфігурацыя спасылаецца на адрас кантэйнера DNS, трымайце яго стабільным пры сумяшчальнай канфігурацыі IPAM. Дынамічна выдадзены адрас, скапіяваны з учарашняга кантэйнера, можа не спрацаваць пры перастварэнні. Таксама праверце шлях уверх па плыні ў рэзалвера: перасылка запытаў без адказу самому сабе стварае іншую памылку, чым недасягальны рэзалвер.

Нарэшце, вызначце, хто разрознівае пункт прызначэння. HTTP-проксі, які разрознівае імя CONNECT, можа выкарыстоўваць гэты шлях праз кантэйнер; кліент SOCKS, які разрознівае лакальна, можа і не. Запыт да хоста даказвае маршрут хоста, а не маршрут працэсу проксі.