Docker networks: сети контейнеров и взаимодействие сервисов

Docker networks позволяют контейнерам взаимодействовать друг с другом и с внешней сетью.

В Docker Compose сервисы по умолчанию подключаются к общей сети проекта. Контейнеры могут находить друг друга по имени сервиса через встроенный DNS.

Например, если Compose-файл содержит сервисы app и postgres, приложение может подключаться к базе по адресу:

postgres:5432

IP-адрес базы указывать не нужно.

Зачем нужны Docker networks

Сети используются для:

• связи приложения с базой данных;
• связи Nginx с PHP;
• подключения приложения к Redis;
• изоляции сервисов;
• разделения frontend и backend;
• подключения нескольких Compose-проектов.

Список сетей

docker network ls

Создать сеть:

docker network create app-network

Информация:

docker network inspect app-network

Удалить:

docker network rm app-network

Подключение контейнера к сети

Создаем контейнер:

docker run -d \
  --name nginx \
  --network app-network \
  nginx

Другой контейнер в той же сети:

docker run --rm \
  --network app-network \
  curlimages/curl \
  http://nginx

Контейнер может обратиться к Nginx по имени nginx.

Docker Compose и сети

Простейший Compose-проект:

services:
  app:
    image: my-app

  postgres:
    image: postgres:18

Compose автоматически создает default network. Все сервисы подключаются к ней.

Собственная сеть

Можно определить сети явно:

services:
  app:
    image: my-app
    networks:
      - backend

  postgres:
    image: postgres:18
    networks:
      - backend

networks:
  backend:

Теперь оба сервиса находятся в сети backend.

Разделение frontend и backend

Более сложная архитектура:

services:
  nginx:
    image: nginx:alpine
    networks:
      - frontend
      - backend

  app:
    image: my-app
    networks:
      - backend

  postgres:
    image: postgres:18
    networks:
      - backend

networks:
  frontend:
  backend:

В этом случае Nginx подключен к двум сетям, а PostgreSQL — только к backend.

Это позволяет ограничить непосредственный доступ между сервисами.

Service discovery

В Compose сервисы доступны по именам.

Например:

services:
  web:
    image: my-app

  redis:
    image: redis:alpine

Приложение может использовать:

redis:6379

Вместо:

localhost:6379

Это важное правило Docker.

localhost внутри контейнера означает сам контейнер, а не хост и не соседний контейнер.

Почему нельзя использовать localhost

Допустим, приложение находится в контейнере app, а Redis — в redis.

Неправильно:

localhost:6379

Правильно:

redis:6379

Потому что localhost внутри app указывает на app.

Публикация портов

Сетевое взаимодействие между контейнерами не требует публикации порта наружу.

Например:

services:
  app:
    image: my-app

  postgres:
    image: postgres:18

PostgreSQL может быть доступен приложению внутри сети без:

ports:
  - "5432:5432"

Публиковать порт базы данных на интернет-хост без необходимости не стоит.

Проверка сети

Посмотреть сети:

docker network ls

Проверить конкретную:

docker network inspect project_default

Можно также войти в контейнер и проверить DNS/сетевое соединение.

Например:

docker compose exec app sh

Затем выполнить подходящую команду для проверки подключения к сервису.

Типичные проблемы

Контейнеры находятся в разных сетях

Тогда они не смогут нормально взаимодействовать через внутреннюю сеть.

Используется localhost

Это одна из самых распространенных ошибок.

Используется IP контейнера

IP может измениться после пересоздания контейнера. Лучше обращаться к сервису по имени.

База опубликована наружу без необходимости

Если PostgreSQL нужен только приложению, обычно достаточно внутренней сети.

Networks и Docker Compose

Сети особенно важны в многоконтейнерных проектах.

Например, стандартный стек веб-сайта может выглядеть так:

Internet
   |
 Nginx
   |
  App
 /   \
DB   Redis

Для такого проекта Compose позволяет создать несколько сетей и явно определить, какие сервисы имеют доступ друг к другу.

Читайте также:

• Docker Compose
• Docker volumes
• Docker для Nginx
• Docker для PostgreSQL
• Docker для Redis