Чому проксі-контейнер не використовує DNS-контейнер автоматично

Запуск проксі та DNS-сервера на одному хості Docker не з'єднує їхні DNS-шляхи. Важливі три окремі зв'язки:

• Мережева доступність. Окремі проєкти Compose зазвичай мають окремі мережі за замовчуванням. Розмістіть сервіси в належній спільній мережі — або в межах одного проєкту, або через мережу, явно спільну між проєктами.
• Виявлення сервісів. Вбудований DNS власної мережі Docker може розв'язувати імена контейнерів. Це дає застосунку змогу виявити сусіда; але не вибирає цього сусіда автоматично як свій DNS-резолвер.
• Вибір резолвера. Визначте резолвер, який використовується всередині проксі-контейнера. Поле dns у Compose приймає адреси DNS-серверів. Ім'я на кшталт dns.local, що розв'язується в застосунку, не робить його припустимим значенням для цього поля.

Простежте запит від проксі-контейнера до налаштованої адреси резолвера. Підтвердьте, що за цією адресою є маршрут і слухач DNS. Публікація порту 53 хоста створює шлях доступу з боку хоста; але не повідомляє контейнерам, що його треба використовувати. Контейнери, які поділяють мережу, можуть натомість взаємодіяти напряму.

Якщо конфігурація посилається на адресу DNS-контейнера, тримайте її стабільною за сумісної конфігурації IPAM. Динамічно виділена адреса, скопійована з учорашнього контейнера, може не спрацювати під час повторного створення. Перевірте також висхідний шлях резолвера: пересилання запитів без відповіді назад до нього самого створює інший збій, ніж недосяжний резолвер.

Нарешті, визначте, хто розв'язує призначення. HTTP-проксі, який розв'язує ім'я CONNECT, може використовувати цей шлях через контейнер; клієнт SOCKS, який розв'язує локально, можливо, ні. Пошук на хості доводить маршрут хоста, а не процесу проксі.