Сети Compose: DNS сервисов и соединение контейнеров

Автор: Казачкин Даниил Михайлович · Обновлено 29 сентября 2026 г.

Приложение и база данных обычно работают в разных контейнерах. Адрес localhost:5432 внутри приложения указывает на само приложение, поэтому не приводит к PostgreSQL в соседнем…

Приложение и база данных обычно работают в разных контейнерах. Адрес localhost:5432 внутри приложения указывает на само приложение, поэтому не приводит к PostgreSQL в соседнем сервисе. После этого урока вы настроите соединение по имени сервиса, проверите DNS и поймёте, когда нужен порт хоста.

Имя сервиса вместо запомненного IP

Compose создаёт сеть проекта и подключает сервисы к ней. Внутри этой сети контейнеры могут обращаться к сервисам по именам. IP меняется при пересоздании, а имя остаётся стабильным. Клиент должен уметь переподключаться и повторно разрешать имя; вечное соединение не сохраняется только благодаря DNS. Описание сети Compose.

Сохраните отдельный compose.yaml:

name: yk-network-demo
services:
  web:
    image: nginx:1.28-alpine
  probe:
    image: alpine:3.22
    command: ["sh", "-c", "nslookup web && wget -qO- http://web:80"]

Запустите docker compose up -d web, затем docker compose run --rm probe. DNS выдаст адрес web, а wget прочитает HTML. ports в этом проекте нет: доступ из одного сервиса к другому не требует публикации Nginx на хосте.

Для сравнения выполните docker compose run --rm probe wget -qO- http://localhost:80. Внутри этого диагностического контейнера Nginx не запущен, поэтому соединение не устанавливается. Это намеренная ошибка адреса, а не признак неисправного Docker DNS.

Два направления трафика

Не копируйте строку подключения из IDE без изменения в приложение внутри Compose. Число 15432 существует на стороне хоста, а внутри сети сервер по-прежнему слушает 5432. Секреты и имя базы при этом остаются отдельными параметрами.

Несколько сетей и изоляция

Можно подключить proxy и приложение к frontend, а приложение и базу — к backend. Тогда proxy не обязан иметь сетевой доступ к базе. Сервис, не подключённый к нужной сети, не получает доступ только из-за совпадения имени. internal: true ограничивает внешнюю связность этой сети, но не является проверкой пользовательских полномочий внутри приложения. Compose networks.

У user-defined bridge есть DNS-обнаружение; не переносите это свойство на произвольный запуск в старом default bridge без проверки. Для ручного опыта создайте именованную сеть и подключайте к ней оба контейнера. Не фиксируйте IP в коде ради исправления одноразовой ошибки запуска: после следующего пересоздания адрес снова может измениться.

Проверять слой за слоем

Если имя не разрешается, посмотрите docker compose ps, docker network inspect и фактические сети сервиса. Если DNS работает, а TCP нет, проверьте порт, готовность сервера и bind address. Если сервер отвечает отказом аутентификации, сеть уже доставила запрос: теперь исследуйте пользователя, пароль и базу. Такая последовательность не позволяет спутать неверные credentials с DNS-проблемой.

Для исходящего DNS сравните запрос внутри контейнера и на хосте; VPN или корпоративный resolver могут менять результат. Не подменяйте DNS случайным публичным адресом, пока не выясните, нужны ли внутренние домены организации.

Контрольный опыт

Сначала выполните docker compose down со старым YAML, чтобы удалить контейнер web. Затем переименуйте сервис web в site, оставив старый URL у probe, запустите docker compose up -d site и повторите probe: ожидается отказ разрешения прежнего имени. Без удаления старого контейнера orphan мог бы продолжить отвечать как web. Исправьте URL, повторите проверку и пересоздайте сервер. Запишите, какое имя осталось устойчивым, а какое значение могло измениться. Остановите учебный проект docker compose down. Главный результат — строка подключения, построенная с позиции клиента, а не с позиции открытого рядом браузера.