Docker network alias: как работает DNS-имя контейнера

Почему alias удобнее жёсткого IP-адреса

Docker динамически назначает адреса контейнерам, поэтому привязывать конфигурацию приложения к конкретному IP обычно хрупко. В пользовательских сетях Docker доступно встроенное разрешение имён: контейнеры могут находить друг друга по имени, а network alias добавляет к этому ещё одно сетевое имя. Например, контейнер `postgres-prod-1` можно сделать доступным соседям как `db`, не переименовывая сам контейнер. При пересоздании контейнера его IP может измениться, а логическое имя останется частью конфигурации сети. Это особенно удобно для приложений, где переменная подключения может содержать `DB_HOST=db`, а физическая реализация сервиса меняется независимо.

Совет: Для связи контейнеров предпочитайте имена и aliases внутри user-defined network, а не копирование IP из `docker inspect` в конфиги.

Почему alias называется network-scoped

Один контейнер может одновременно быть подключён к нескольким сетям, и набор aliases у каждой сети может отличаться. Именно поэтому alias не следует воспринимать как второе глобальное имя контейнера. Можно дать приложению имя `api` в сети frontend и другое имя в сети внутреннего обмена, либо вовсе не публиковать alias в лишней сети. Такой scope помогает разделять пространства имён и уменьшает случайные связи между сервисами. Если контейнер не подключён к сети, запросы к alias этой сети ничего ему не дадут. На default bridge сетевое поведение отличается: Docker рекомендует пользовательские bridge-сети, где контейнеры получают DNS-разрешение по именам.

Важно: Alias — не публикация порта наружу. Он помогает контейнерам найти друг друга внутри сети, но не делает сервис доступным из браузера на хосте и не заменяет `-p` или `--publish`.

Как добавить alias и проверить его

1. Создайте пользовательскую сеть: Например: `docker network create app-net`. Отдельная user-defined сеть даёт предсказуемое разрешение имён между участниками.
2. Запустите сервис с alias: Используйте `docker run -d --name db1 --network app-net --network-alias db postgres:..` или эквивалентную конфигурацию Compose.
3. Подключите клиент к той же сети: Контейнер приложения должен находиться в `app-net`. Наличие опубликованного порта на хост не заменяет сетевое членство.
4. Проверьте разрешение имени: Выполните внутри клиентского контейнера запрос к `db` через приложение, `getent hosts db` или другой доступный инструмент. Проверяйте не только DNS, но и доступность нужного порта.
5. Добавьте alias работающему контейнеру: Команда `docker network connect --alias db app-net container2` позволяет подключить существующий контейнер и задать сетевой alias.
6. Посмотрите network inspect: Проверьте участников и настройки сети через `docker network inspect app-net`, если имя не разрешается или контейнер оказался не в той сети.

Предупреждение: Не создавайте один и тот же alias для нескольких независимых контейнеров, если клиент ожидает единственный однозначный backend. При общем alias конкретный ответ по имени может быть неоднозначным.

Имя контейнера, hostname, alias и published port

[object Object]

Как это выглядит в Docker Compose

В Compose имя сервиса само становится удобной точкой обращения внутри общей сети, но aliases полезны, когда приложению нужно старое имя, совместимость с существующей конфигурацией или разные имена в разных сетях. В секции `networks` у сервиса можно перечислить `aliases`, и они будут привязаны именно к соответствующей сети. Это позволяет, например, оставить код с `DB_HOST=database`, даже если сервис в YAML называется `postgres`. При масштабировании будьте осторожны с предположением «alias всегда указывает на один контейнер»: сетевое имя может представлять несколько endpoints, а конкретный ответ не гарантирован. Если требуется маршрутизация на один экземпляр, используйте более явную архитектуру, а не рассчитывайте на случайный DNS-ответ.

Как aliases помогают разделять внутренние роли сервиса

Один и тот же контейнер может быть известен разным соседям под разными логическими именами, если он подключён к нескольким сетям. Это удобно, когда архитектура разделяет frontend, backend и служебную сеть: внешней части можно дать только нужное имя API, а административный alias оставить во внутреннем сегменте. При этом network alias не является механизмом авторизации — контейнер, имеющий доступ к сети, всё равно может обнаруживать endpoints другими способами. Поэтому сеть и alias решают задачу адресации, а не заменяют firewall, TLS или аутентификацию приложения. Хорошая схема имён помогает конфигурации переживать пересоздание контейнеров и снижает соблазн привязываться к эфемерным IP.

Что происходит с alias при пересоздании контейнера

Network alias относится к подключению контейнера к конкретной сети, поэтому его нужно считать частью сетевой конфигурации, а не свойством приложения «навсегда». Если контейнер удалили и создали заново вручную без `--network-alias`, прежнее дополнительное имя само по себе не вернётся. В Compose aliases стоит описывать в YAML рядом с нужной сетью, чтобы конфигурация воспроизводилась при `docker compose up`. Это особенно важно для баз данных, брокеров и API, где клиенты должны обращаться к стабильному логическому имени, а физический контейнер может пересоздаваться при обновлении. Проверяя инцидент после redeploy, сравните не только имя контейнера, но и его фактические NetworkSettings и aliases в нужной сети. Такая проверка быстрее показывает, потеряно ли DNS-имя при пересоздании или проблема уже на уровне самого сервиса.

Почему published port и внутренний DNS решают разные задачи

Alias нужен контейнеру-клиенту, который уже находится в той же Docker network. Published port нужен, когда к контейнерному сервису обращается хост или внешняя сеть через адрес Docker host. Эти механизмы могут существовать одновременно, но один не заменяет другой. Например, backend внутри `app-net` может обращаться к базе как `db:5432`, тогда как администратор с хоста подключается к опубликованному `127.0.0.1:15432`. Если в конфиг контейнера положить host-порт вместо внутреннего имени, архитектура становится зависимой от маршрута через хост и сложнее переносится. Если, наоборот, попытаться открыть `http://db:5432` в браузере хоста, локальная ОС обычно не знает ничего о Docker network alias. При диагностике всегда сначала определяйте, откуда идёт клиентский запрос: из соседнего контейнера, с Docker host или с другой машины.

Если alias не работает, проверьте по порядку

• Клиент и сервер подключены к одной и той же user-defined network.
• Alias назначен именно в этой сети, а не в другой сети того же контейнера.
• В конфиге нет опечатки и клиент использует имя без лишнего домена.
• Сервис слушает нужный контейнерный порт и не ограничен только 127.0.0.1 внутри контейнера.
• Вы не путаете внутренний alias с адресом, который должен открываться на хосте.
• Общий alias не назначен нескольким сервисам, если требуется однозначная цель.

Что учитывать

Docker динамически назначает адреса контейнерам, поэтому привязывать конфигурацию приложения к конкретному IP обычно хрупко. В пользовательских сетях Docker доступно встроенное разрешение имён: контейнеры могут находить друг друга по имени, а network alias добавляет к этому ещё одно сетевое имя. Например, контейнер `postgres-prod-1` можно сделать доступным соседям как `db`, не переименовывая сам контейнер. При пересоздании контейнера его IP может измениться, а логическое имя останется частью…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. docker network connect). Пример и формулировки — редакция N1RO на 2026-09-20.

• docker network connect
• Networking overview
• Compose file reference — services