Как назначить статический IP контейнеру Docker

Почему нельзя просто добавить --ip к обычному docker run

Флаг `--ip` работает в контексте сети, где Docker знает допустимую подсеть. В официальном примере сначала создаётся user-defined network с `docker network create --subnet 192.0.2.0/24 my-net`, а уже затем контейнер запускается с `--network=my-net --ip=192.0.2.69`. Это защищает от произвольного назначения адреса вне пула и позволяет IPAM управлять сетью предсказуемо.

Default bridge — не лучшее место для ручной адресации. Пользовательские bridge-сети дают встроенное обнаружение по именам и более явную изоляцию. Если сервисы общаются только между собой, статический IP вообще может не понадобиться: подключите их к одной именованной сети и используйте имя сервиса или network alias. Это переживает пересоздание контейнера лучше, чем конфигурация, в которой приложение хранит `172.x.x.x` в коде.

Важно: Перед созданием подсети проверьте, что она не пересекается с LAN, VPN, корпоративными маршрутами и другими Docker networks. Пересечение часто выглядит как «Docker DNS сломан», хотя проблема в маршрутизации.

Статический IP через docker network и docker run

1. Выберите приватную подсеть, которая не конфликтует с сетями хоста и VPN, например тестовую `192.0.2.0/24` только для документации или свой RFC1918-диапазон в реальной среде.
2. Создайте сеть командой `docker network create --subnet <CIDR> <network-name>`.
3. Проверьте параметры через `docker network inspect <network-name>` и убедитесь, что subnet совпадает с планом.
4. Запустите контейнер с `--network=<network-name> --ip=<address>`. Адрес должен входить в объявленную подсеть и не быть уже занят.
5. Из второго контейнера в этой же сети проверьте связь сначала по DNS-имени, затем по IP, чтобы отделить проблему адресации от проблемы приложения.
6. После теста зафиксируйте создание сети и параметры запуска в Compose или инфраструктурном коде, если конфигурация должна воспроизводиться.

Предупреждение: Не выбирайте первый и последний адрес диапазона наугад. Учитывайте gateway и уже занятые адреса, которые показывает `docker network inspect`.

Как задать ipv4_address в Docker Compose

В Compose статический IPv4 задаётся на подключении сервиса к сети через `ipv4_address`. Но этого недостаточно: Docker Compose reference требует, чтобы соответствующая top-level network имела IPAM-конфигурацию с subnet, покрывающей каждый статический адрес. То есть сервис и сеть описываются вместе.

Практический шаблон: объявите сеть `app_net`, добавьте в `ipam.config` подсеть, например `172.30.0.0/24`, затем у нужного сервиса в `networks.app_net.ipv4_address` укажите `172.30.0.10`. Соседним сервисам статические адреса задавайте только если есть реальная причина. Для обычной базы данных приложение лучше подключать к `db:5432`, а не к её фиксированному IP: Compose DNS уже решает задачу обнаружения сервисов.

Если в одной сети нужно несколько фиксированных адресов, заранее разделите адресное пространство: например, оставьте понятный диапазон для ручных назначений и отдельный пул для динамической выдачи через IPAM. Compose позволяет задавать `subnet`, `ip_range`, `gateway` и auxiliary addresses. Это снижает риск, что вручную выбранный IP позже пересечётся с адресом, который Docker выделит автоматически другому контейнеру. Но для небольшого проекта не создавайте сложную схему без причины: одна сеть плюс DNS-имена сервисов почти всегда проще сопровождать, чем таблица из десятков закреплённых IP.

Совет: Если цель — «чтобы адрес базы никогда не менялся», чаще правильный ответ — использовать имя сервиса. Статический IP добавляет ручное управление без пользы.

Типичные ошибки: конфликт подсетей, занятый адрес и ожидание внешней статичности

Первая проблема — пересечение CIDR. Если Docker network использует ту же подсеть, что офисная сеть или VPN, ядро может отправлять трафик не туда. Выбирайте диапазон осознанно и смотрите таблицу маршрутов хоста. Вторая проблема — IP уже занят другим контейнером или зарезервирован gateway. Docker обычно сообщает конфликт, но в сложной среде полезно сверяться с `docker network inspect`.

Третья ошибка — считать внутренний IP контейнера внешним адресом сервиса. `172.30.0.10` существует внутри Docker network; клиенты из LAN или интернета обычно не подключаются к нему напрямую. Для внешнего доступа публикуют порт на хосте, используют reverse proxy или маршрутизируют сеть отдельно. Статический контейнерный IP не заменяет `-p`, firewall и нормальную схему ingress.

Отдельно проверьте, кому именно должен быть доступен сервис. Внутренний `ipv4_address` решает адресацию внутри Docker network, но не делает контейнер автоматически видимым из LAN или интернета. Для внешнего клиента обычно нужен опубликованный порт, reverse proxy, firewall и корректный маршрут до Docker host. Если проблему ingress пытаются решить только статическим адресом контейнера, конфигурация становится сложнее, а причина недоступности остаётся на месте.

Важно: Не добавляйте маршруты в корпоративную сеть только ради доступа к одному контейнеру, если ту же задачу решает опубликованный порт или reverse proxy. Чем меньше сетевых исключений, тем проще эксплуатация.

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

Если контейнер запускается вручную с фиксированным `--ip`, тот же адрес можно назначить снова при следующем запуске, пока сеть и адрес свободны. В Compose `ipv4_address` хранится в декларативном файле, поэтому пересозданный сервис получает заданный адрес в рамках этой сети. Это полезно для воспроизводимости, но создаёт ответственность: нельзя одновременно масштабировать сервис в несколько реплик с одним и тем же IP.

Если вам нужно несколько экземпляров приложения, используйте DNS-имя сервиса, service discovery или балансировщик. Статическая адресация лучше работает для одиночных инфраструктурных компонентов и тестовых стендов, где количество узлов известно заранее.

Перед переносом Compose-проекта на другой хост проверьте сетевые диапазоны заново. Подсеть, свободная на ноутбуке, может конфликтовать с VPN или LAN на сервере. Правильная конфигурация Docker сети — это не только валидный YAML, но и отсутствие пересечений в реальной таблице маршрутизации.

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

Флаг `--ip` работает в контексте сети, где Docker знает допустимую подсеть. В официальном примере сначала создаётся user-defined network с `docker network create --subnet 192.0.2.0/24 my-net`, а уже затем контейнер запускается с `--network=my-net --ip=192.0.2.69`. Это защищает от произвольного назначения адреса вне пула и позволяет IPAM управлять сетью предсказуемо. Default bridge — не лучшее место для ручной адресации. Пользовательские bridge-сети дают встроенное обнаружение по именам и более…

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

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

• docker container run
• Define services in Docker Compose
• Bridge network driver