Сетевое взаимодействие контейнерных приложений

Предыдущие темы курса рассматривали контейнер как отдельный объект: сначала как воспроизводимый артефакт сборки, затем как управляемый процесс в среде выполнения. Однако реальные приложения почти никогда не сводятся к одному контейнеру. Веб-сервер обращается к базе данных, фоновая задача публикует сообщения в брокер очередей, шлюз проксирует запросы во внутренние сервисы. Все эти взаимодействия требуют сети — и устроены они в контейнерной среде иначе, чем в классической многопроцессной системе на одном хосте.

Сеть в контейнерной среде имеет двухуровневый характер. С одной стороны, сетевой стек контейнера изолирован от хоста средствами ядра операционной системы; контейнер не видит интерфейсов хоста и не может произвольно слушать его порты. С другой стороны, эта изоляция должна быть прозрачно «прорезана» в нужных местах: контейнеры должны находить друг друга по именам, а внешние клиенты — попадать в нужный контейнер через известный порт. Понимание того, как именно среда выполнения создаёт эти точки прозрачности, и составляет основное содержание темы.

Материал темы строится по схеме «от изоляции к публикации». Открывается тема кратким напоминанием базовых сетевых понятий, нужных дальше по тексту. Затем рассматривается, как устроено изолированное сетевое пространство контейнера и какие виртуальные интерфейсы обеспечивают его связь с внешним миром. Далее — как Docker предоставляет несколько режимов подключения (drivers) с разным компромиссом между изоляцией и удобством. После этого разбираются механизмы публикации сервисов наружу и обнаружения сервисов друг другом внутри одного хоста. Затем следует обзор типичных эксплуатационных рисков и ограничений локальной контейнерной сети. Завершает тему Docker Compose — декларативное описание многоконтейнерного приложения вместе с его сетями, томами и порядком запуска; его ограничения мотивируют переход к оркестрации в теме 7.

Минимальные сведения о компьютерных сетях

Дальнейший материал опирается на ряд понятий из курса компьютерных сетей. Глубокое их изложение выходит за пределы темы, но без короткого напоминания текст превратится в перечень терминов. Поэтому ниже собраны те и только те сведения, которые потребуются по ходу разбора контейнерной сетевой модели. Для более основательного знакомства с предметом в дополнительных материалах темы собраны глоссарий, шпаргалка по командам и аннотированный список источников, а сетевые пространства имён и виртуальные интерфейсы описаны в справочных страницах Linux ¹¹¹².

IP-адреса, подсети и сетевые интерфейсы

Каждое устройство, участвующее в сетевом обмене, идентифицируется IP-адресом (англ. Internet Protocol address). В курсе мы практически всегда имеем дело с адресами IPv4 — четыре десятичных числа, разделённые точками: например, 192.168.1.10. Адрес сам по себе не даёт полной информации о расположении узла; к нему нужна подсеть (англ. subnet) — диапазон адресов, считающихся «локальными». Подсеть задаётся длиной префикса в записи 192.168.1.0/24: первые 24 бита определяют сеть, оставшиеся 8 — конкретный узел в ней.

Подсеть нужна узлу, чтобы решить, как отправить пакет. Если адрес назначения попадает в локальную подсеть, пакет передаётся в неё напрямую, на канальном уровне. Если нет — пакет уходит через шлюз по умолчанию (англ. default gateway), специально настроенный узел, отвечающий за передачу пакетов в другие сети. Сопоставление «куда пойдёт пакет с данным адресом назначения» хранится в таблице маршрутизации (англ. routing table) узла; именно эту таблицу будет иметь свой экземпляр у каждого контейнера.

Связь узла с сетью реализуется через сетевой интерфейс (англ. network interface) — программную сущность, к которой привязан IP-адрес и через которую идут пакеты. Физическому Ethernet-порту обычно соответствует интерфейс eth0, петлевому интерфейсу — lo (адрес 127.0.0.1, видимый только изнутри узла). На одном узле может быть несколько интерфейсов; в контейнерной среде к этому добавятся виртуальные интерфейсы, создаваемые ядром по запросу.

Транспортные порты и сокеты

IP-адрес определяет узел, но не приложение. На одном узле обычно работают десятки сетевых процессов одновременно: веб-сервер, СУБД, агенты мониторинга. Чтобы пакет дошёл до нужного процесса, на транспортном уровне используется понятие порта (англ. port) — целое число от 1 до 65535. Сочетание «IP-адрес + порт» называется сокетом (англ. socket) и однозначно указывает конкретную точку обмена в сети.

Большинство сетевых соединений в курсе — это TCP-соединения (англ. Transmission Control Protocol): надёжный поток байтов с установлением и закрытием соединения. Реже встречается UDP (англ. User Datagram Protocol) — обмен отдельными пакетами без подтверждений, применяется, например, для DNS-запросов. На уровне работы с контейнерами различия между этими протоколами чаще всего не критичны; критично то, что приложение должно «слушать» (англ. listen) определённый порт, чтобы клиенты могли к нему подключиться.

Адрес, на котором приложение слушает, имеет значение. Привязка к 127.0.0.1 (петлевой интерфейс) делает порт доступным только локальным процессам узла. Привязка к конкретному IP-адресу одного из интерфейсов — только клиентам, идущим через этот интерфейс. Привязка к 0.0.0.0 означает «на всех интерфейсах»: порт доступен и локально, и снаружи. Различение этих режимов окажется важным при разборе публикации портов контейнеров.

Разрешение имён и трансляция адресов

Запоминать IP-адреса вручную неудобно, поэтому в реальных сетях работает разрешение имён через систему DNS (англ. Domain Name System). DNS — это иерархическая распределённая база данных, в которой именам узлов ставятся в соответствие их IP-адреса. Когда приложение обращается к имени db.example.com, операционная система отправляет DNS-запрос настроенному серверу имён и получает в ответ адрес. Параметры DNS на узле задаются файлом /etc/resolv.conf. Среда выполнения формирует этот файл для каждого контейнера сама, но по-разному в зависимости от сети. Контейнер в стандартной сети bridge получает копию настроек DNS хоста. Контейнер в пользовательской сети получает файл, указывающий на встроенный DNS-сервер Docker с адресом 127.0.0.11; этот сервер отвечает на имена контейнеров, а остальные запросы пересылает серверам хоста ¹. Механизм разрешения имён при этом остаётся стандартным: приложение не знает, что работает в контейнере.

Второе понятие, неизбежное при разборе контейнерных сетей, — трансляция адресов NAT (англ. Network Address Translation). NAT — это техника, при которой узел-посредник переписывает заголовки проходящих пакетов: подменяет адрес источника, адрес назначения или оба. Самый частый сценарий — преобразование частных адресов локальной сети в один публичный адрес шлюза при выходе наружу; ответы шлюз возвращает в обратном направлении, восстанавливая исходный адрес. Среда выполнения Docker использует NAT для двух задач: чтобы наружу контейнер был виден под адресом хоста (исходящие соединения) и чтобы пакет с порта хоста попадал в нужный контейнер (опубликованные порты). Подробного знания механики NAT для темы не требуется; достаточно помнить, что трансляция выполняется в ядре хоста, прозрачно для приложения и не оставляет следов в самом контейнере.

Базовая модель «клиент — сервер» и фильтрация трафика

Большинство сетевых взаимодействий в курсе укладываются в модель «клиент — сервер»: серверный процесс заранее открыл сокет и ждёт подключений на известном порту, клиент устанавливает соединение по адресу и порту сервера, обменивается с ним сообщениями и закрывает соединение. Серверный процесс может одновременно обслуживать множество клиентов, каждое соединение различается своей четвёркой «адрес-порт клиента — адрес-порт сервера».

Помимо собственно передачи пакетов, в современных операционных системах действует межсетевой фильтр (англ. firewall) — подсистема ядра, проверяющая каждый пакет по заданным правилам. На Linux это netfilter, управляемый утилитами iptables или nft (подсистема nftables). Фильтр может пропускать, отбрасывать или модифицировать пакеты; именно через эти модификации реализуются и проброс портов, и NAT для исходящего трафика контейнеров. Помнить синтаксис правил наизусть не нужно — но важно понимать, что результаты команд docker run -p ... и docker network create ... наблюдаемы как изменения в межсетевом фильтре хоста, и при диагностике сетевых проблем именно туда стоит смотреть в первую очередь.

Сетевые пространства контейнеров

Сетевая изоляция контейнера — частный случай более общего механизма пространств имён (англ. namespaces), рассмотренного в теме 3 в разделе об изоляции контейнеров. Сетевое пространство имён (англ. network namespace) — это отдельный экземпляр сетевого стека ядра: собственный набор сетевых интерфейсов, своя таблица маршрутизации, свои правила фильтрации, своя таблица сокетов. Процессы, помещённые в одно сетевое пространство, видят только его интерфейсы; процессы хоста видят интерфейсы хоста; пересечения нет, пока его явно не настроить.

С практической точки зрения это означает, что внутри контейнера команда ip addr покажет только два интерфейса: локальную петлю lo и одно виртуальное Ethernet-устройство, через которое контейнер подключён к внешней сети. Никаких физических интерфейсов хоста, никаких других контейнеров в этом списке нет — даже если на хосте одновременно работают десятки контейнеров. Изоляция сетевого стека делает контейнер минимально похожим на отдельную виртуальную машину с точки зрения сетевой адресации, но при этом не требует виртуализации оборудования.

Убедиться в этом можно одной командой. Образ busybox содержит упрощённые версии утилит ip, ping, nslookup и wget, поэтому подходит для сетевых опытов:

docker run --rm busybox:1.37 sh -c 'ip addr; ip route'

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
...
2: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 6a:3e:51:0c:9d:12 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 scope global eth0
...
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 scope link src 172.17.0.2

Вывод сокращён, номера интерфейсов и MAC-адрес у каждого запуска свои. Существенны три строки. Запись eth0@if7 означает, что интерфейс — один конец пары, второй конец которой имеет в другом пространстве имён индекс 7. Адрес 172.17.0.2/16 выделен из подсети стандартной сети Docker. Маршрут по умолчанию ведёт через 172.17.0.1 — адрес моста на стороне хоста. Каждое сетевое пространство имён имеет собственные интерфейсы, таблицы маршрутизации и правила netfilter, а физическое устройство может находиться только в одном из них ¹¹.

Виртуальные интерфейсы и базовая модель подключения

Передача пакетов между изолированным пространством контейнера и сетью хоста реализуется через пару виртуальных интерфейсов (англ. veth pair). Это устройство, которое ведёт себя как двусторонний сетевой кабель: один его конец помещается в сетевое пространство контейнера, другой остаётся в пространстве хоста. Всё, что записывается в один конец, выходит из другого. Внутри контейнера этот конец обычно называется eth0; на хосте — имеет техническое имя вида vethXXXX и сам по себе для пользовательских задач не используется. Пары veth создаются всегда вдвоём, и типичное их применение — именно связь двух сетевых пространств имён; при удалении одного конца исчезает и второй ¹².

Простое существование пары виртуальных интерфейсов ещё не делает контейнер достижимым по сети. Хостовый конец пары должен быть подключён к какой-либо коммутирующей структуре, через которую пакеты пойдут дальше. В стандартной конфигурации Docker эта структура — программный сетевой мост (англ. bridge) с именем docker0. Все хостовые концы пар veth от контейнеров одной мостовой сети подключены к этому мосту, что позволяет пакетам ходить между контейнерами и наружу через таблицу маршрутизации хоста.

Хостовую сторону той же картины показывают обычные утилиты iproute2. Команды выполняются на хосте с Docker Engine для Linux; у Docker Desktop мост находится внутри служебной виртуальной машины и с хоста не виден (об этом — в конце раздела о рисках):

ip -br link show type veth        # хостовые концы пар veth
ip -br link show master docker0   # какие из них подключены к мосту docker0

veth3f2a1b0@if2  UP   7a:78:e2:29:50:97 <BROADCAST,MULTICAST,UP,LOWER_UP>

Запись @if2 — зеркальная к eth0@if7 в контейнере: она указывает индекс парного интерфейса в чужом пространстве имён. Если запустить второй контейнер, на хосте появится вторая пара veth, подключённая к тому же мосту.

Маршрутизация в самом контейнере при этом устроена просто: задан адрес шлюза по умолчанию, совпадающий с адресом моста на стороне хоста. Любой пакет, не относящийся к локальной подсети контейнера, отправляется через этот шлюз и далее — обычными средствами хоста. Внешние ответы возвращаются по тому же пути, и Docker обеспечивает корректную трансляцию исходного адреса (англ. source NAT), чтобы внешним сервисам контейнер был виден под адресом хоста.

Внутренняя связность и внешний доступ — два разных вопроса

При работе с сетью контейнеров полезно с самого начала разделять два вопроса, которые часто смешивают. Первый: «могут ли два контейнера обращаться друг к другу?» Второй: «может ли клиент извне обратиться к контейнеру?» Ответы на них даются разными механизмами и регулируются разными настройками.

Внутренняя связность — это вопрос о том, какие контейнеры подключены к одной и той же сети и какие правила фильтрации между ними действуют. Если оба контейнера находятся в стандартной мостовой сети docker0, они могут обращаться друг к другу по IP-адресам, но не по именам — стандартный мост не предоставляет встроенного разрешения имён. Если же оба контейнера подключены к пользовательской сети, созданной командой docker network create, между ними автоматически работает встроенный DNS-сервис Docker, и они могут обращаться друг к другу по имени контейнера.

Внешний доступ — это вопрос о том, какие порты хоста проброшены в контейнер. Без явного проброса контейнер недоступен извне хоста, даже если он слушает порт 0.0.0.0:8080: адрес контейнера принадлежит внутренней подсети моста, маршрута к ней у других машин нет, а пакеты, адресованные прямо в контейнер не через мост, Docker отбрасывает ³⁵. Оговорка «извне хоста» существенна. С самого хоста Docker Engine для Linux адрес контейнера достижим напрямую: команда curl http://172.17.0.2:8080 на хосте сработает без всякой публикации, потому что хост подключён к мосту и имеет адрес в его подсети. Контейнеры той же сети тоже обращаются друг к другу на любые порты ². Эта на первый взгляд избыточная двухуровневая модель оказывается удобной в эксплуатации: она позволяет запустить десяток контейнеров, каждый из которых внутри слушает порт 8080, и не получить конфликта на хосте — наружу публикуется только то, что нужно, через явно выбранные порты.

Сетевые драйверы и режимы подключения

Конкретный способ организации сети для контейнера в Docker задаётся сетевым драйвером (англ. network driver). Драйвер — это реализация конкретной модели сетевого подключения; на одном хосте могут одновременно существовать сети нескольких типов, и каждый контейнер подключается к одной или нескольким из них. Базовая поставка Docker включает несколько встроенных драйверов; на практике в учебном курсе и в большинстве однохостовых сценариев достаточно двух из них — bridge и host.

Мостовая сеть как основной режим

Драйвер bridge — стандартный сетевой режим Docker. Именно он используется по умолчанию, если при запуске контейнера не указано иное. Для контейнеров создаётся изолированное сетевое пространство, в нём — интерфейс eth0, подключённый через пару veth к программному мосту в пространстве хоста. Этот мост действует как ethernet-коммутатор второго уровня: пакеты между контейнерами одной мостовой сети передаются напрямую, без участия таблицы маршрутизации хоста.

Стандартный мост docker0 создаётся автоматически при установке Docker, к нему подключаются все контейнеры, для которых явно не указана сеть. Однако опираться на него для прикладных задач не рекомендуется. Как уже было отмечено, он не предоставляет разрешения имён, что вынуждает разработчиков жёстко прописывать IP-адреса и сильно усложняет воспроизводимость окружения. Вместо этого следует создавать пользовательскую мостовую сеть командой docker network create my-net. С точки зрения пакетной коммутации она устроена так же, как стандартный мост, но дополнительно включает встроенный DNS-сервер: каждый контейнер этой сети доступен другим её участникам по имени, заданному при запуске.

Сразу после установки Docker существуют три сети: стандартный мост и две служебные сети для режимов host и none. Пользовательская сеть создаётся одной командой; подсеть можно задать явно или доверить выбор Docker:

docker network ls
docker network create --subnet 10.61.0.0/24 app-net
docker network inspect app-net

NETWORK ID     NAME      DRIVER    SCOPE
88f196238a4b   bridge    bridge    local
bb3a8fd98017   host      host      local
f4c1bb9a58ee   none      null      local

[
    {
        "Name": "app-net",
        "Driver": "bridge",
        "EnableIPv4": true,
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Config": [
                {
                    "Subnet": "10.61.0.0/24",
                    "Gateway": "10.61.0.1"
                }
            ]
        },
        "Internal": false,
        "Containers": {},
        ...
    }
]

Поле Gateway — адрес, который Docker назначает мосту на стороне хоста; он же становится маршрутом по умолчанию в контейнерах этой сети. Поле Internal будет важно в разделе о Compose: внутренняя сеть не получает выхода наружу. Мост пользовательской сети называется на хосте br- плюс первые 12 символов идентификатора сети, поэтому его легко найти командой ip -br link show type bridge.

Пользовательские сети также удобны для логического разделения групп связанных контейнеров. На одном хосте могут одновременно существовать несколько таких сетей. Каждая сеть — отдельный мост, то есть отдельный сегмент канального уровня, но одного этого для изоляции недостаточно: мосты соединены через стек хоста, в котором Docker включает пересылку пакетов (net.ipv4.ip_forward=1), и без дополнительных правил хост пересылал бы пакеты из одной подсети в другую как обычный маршрутизатор. Межсетевую изоляцию обеспечивают правила фильтрации, которые Docker добавляет в netfilter хоста. До версии Docker Engine 28 включительно это были цепочки DOCKER-ISOLATION-STAGE-1 и DOCKER-ISOLATION-STAGE-2; в версии 29 они удалены, и ту же роль играет правило вида ! -i br-… -o br-… -j DROP в цепочке DOCKER: пакет, входящий в мост сети не из неё самой и не к опубликованному порту, отбрасывается ⁵⁷. Это даёт минимальную, но рабочую модель сетевой сегментации — она не заменяет полноценные сетевые политики оркестратора (тема 11), но позволяет разделить, например, фронтальную часть приложения и внутренние сервисы на двух разных мостах.

Контейнер может состоять в нескольких сетях одновременно; для этого его подключают к дополнительной сети командой docker network connect и отключают командой docker network disconnect, не перезапуская ²:

docker network connect app-net web     # у контейнера web появится второй интерфейс eth1
docker exec web ip -4 addr             # eth0 — в прежней сети, eth1 — в app-net
docker network disconnect app-net web

Именно так устроен «шлюз» между двумя сетями: один контейнер с интерфейсами в обеих. Пересылки пакетов между этими интерфейсами внутри контейнера нет — контейнер не маршрутизатор, он лишь принимает соединения из одной сети и сам открывает соединения в другую.

Режим хоста и особые драйверы

Драйвер host принципиально отличается от мостового. Контейнер, запущенный в этом режиме, не получает собственного сетевого пространства имён: он использует сетевой стек хоста напрямую. С точки зрения сети это означает, что приложение внутри контейнера слушает порты хоста так же, как обычный процесс — без проброса, без NAT, без дополнительных интерфейсов.

Режим host имеет ограниченную область применения. С одной стороны, он минимизирует сетевую нагрузку: пакеты не проходят через дополнительный мост и не подвергаются трансляции адресов, что бывает заметно для приложений с высокой пропускной способностью. С другой стороны, он полностью устраняет сетевую изоляцию контейнера: контейнер видит все интерфейсы хоста, может слушать любой порт и потенциально конфликтовать с другими процессами хоста. На одном хосте нельзя запустить два контейнера в режиме host, оба слушающих один и тот же порт. По этим причинам режим host используется в качестве оптимизации в специфических случаях, а не как режим общего назначения.

Помимо bridge и host, среда Docker предоставляет несколько специализированных драйверов: none (полное отсутствие сети, для контейнеров вспомогательных задач), macvlan и ipvlan (для случаев, когда контейнеру нужен собственный MAC- или IP-адрес в физической сети), overlay (для распределённых развёртываний на нескольких хостах в режиме Docker Swarm). В курсе они подробно не рассматриваются. macvlan и ipvlan решают узкую задачу включения контейнера прямо в физическую сеть и нужны редко. overlay и сам Docker Swarm в курсе не изучаются вовсе: многохостовая сеть контейнеров рассматривается на примере Kubernetes, у которого собственная сетевая модель (тема 7). Сводка драйверов приведена в таблице ¹².

Правила netfilter Docker создаёт только для мостовых сетей; для macvlan, ipvlan и host их нет ⁴, поэтому разобранные ниже публикация портов и межсетевая изоляция относятся к драйверу bridge.

Общий сетевой стек нескольких контейнеров

Помимо драйверов, есть ещё один режим подключения, который легко пропустить, хотя он важен для понимания следующей темы. Ключ --network container:<имя> помещает новый контейнер в сетевое пространство имён уже работающего контейнера ¹. Собственного интерфейса, адреса и таблицы маршрутизации новый контейнер не получает — он видит те же lo и eth0, что и первый, и может обращаться к его процессам по адресу 127.0.0.1:

docker run -d --name app busybox:1.37 httpd -f -p 8080 -h /etc
docker run --rm --network container:app busybox:1.37 wget -qO- http://127.0.0.1:8080/hostname
docker run --rm --network container:app busybox:1.37 ip -4 addr   # те же адреса, что у app

Пространства имён PID и точек монтирования у контейнеров остаются раздельными: второй контейнер не видит процессов первого и имеет свою корневую файловую систему. Общим становится только сетевой стек, а с ним и пространство портов: два процесса в таких контейнерах не могут одновременно слушать один и тот же порт. Ключи -p, --dns, --hostname для такого контейнера не допускаются — всё это свойства общего стека, и задаются они у первого контейнера ¹.

Ровно так устроен Pod в Kubernetes: несколько контейнеров одного пода разделяют сетевое пространство имён, общаются через localhost и имеют один IP-адрес на всех. Технически пространство имён удерживает служебный контейнер pause, а прикладные контейнеры подключаются к нему тем же механизмом, что и --network container:. Подробно модель пода разбирается в теме 7; в Compose тот же режим записывается как network_mode: "service:<имя>".

Публикация сервисов и межконтейнерное взаимодействие

Создание сети и подключение к ней контейнеров — только первая часть задачи. Прикладной смысл сети раскрывается через два конкретных механизма: публикацию сервисов наружу и обнаружение сервисов внутри сети.

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

Проброс портов (англ. port mapping или port publishing) — основной способ сделать сервис, работающий в контейнере, доступным внешним клиентам. При запуске контейнера ключом -p HOST_PORT:CONTAINER_PORT указывается соответствие между портом хостовой машины и портом внутри контейнера. Среда выполнения настраивает правила трансляции в межсетевом фильтре хоста; внешний пакет, пришедший на указанный порт хоста, перенаправляется на указанный порт контейнера. Обратный путь обеспечивается стандартными механизмами трансляции состояний.

При выборе порта на стороне хоста часто возникает соблазн использовать тот же номер, что и внутри контейнера. Это удобно для разработки, но создаёт неявные ограничения в эксплуатации: на одном хосте нельзя запустить два контейнера, публикующих один и тот же хостовый порт. По этой причине в реальных конфигурациях номер хостового порта обычно либо выбирается осознанно из выделенного диапазона, либо поручается среде выполнения. Для этого хостовый порт просто не указывают: -p 8000 публикует порт 8000 контейнера на свободном порту хоста, а ключ -P (--publish-all) делает то же для всех портов, объявленных инструкцией EXPOSE. Порт выбирается из эфемерного диапазона, заданного в /proc/sys/net/ipv4/ip_local_port_range ³. Узнать, какой порт достался контейнеру, можно командой docker port:

docker run -d --name web -p 8000 python:3.12-alpine python -m http.server 8000
docker port web

8000/tcp -> 0.0.0.0:32768
8000/tcp -> [::]:32768

Две строки появились потому, что без явного адреса порт публикуется на всех адресах хоста — и IPv4, и IPv6 ². Номер 32768 — начало эфемерного диапазона в Linux по умолчанию (32768–60999); у читателя он может быть другим.

Сама публикация состоит из двух механизмов. Первый — правило DNAT в таблице nat межсетевого фильтра: пакет, пришедший на адрес хоста и опубликованный порт, получает новый адрес назначения — адрес и порт контейнера. Второй — процесс docker-proxy, так называемый userland-proxy: для каждого опубликованного порта Docker запускает небольшой прокси, который слушает этот порт на хосте и пересылает соединения в контейнер ³. Прокси нужен прежде всего для соединений с самого хоста на 127.0.0.1: такие пакеты порождаются локально и проходят не цепочку PREROUTING, а цепочку OUTPUT, где Docker не применяет DNAT к адресам 127.0.0.0/8 — перенаправить петлевой пакет на внешний адрес ядро без особой настройки не позволяет. Поэтому команда ss -ltnp на хосте покажет, что опубликованный порт «слушает» docker-proxy, хотя внешние соединения до него не доходят — их раньше перехватывает DNAT. Прокси можно отключить параметром демона "userland-proxy": false; тогда Docker обслуживает и петлевой трафик правилами netfilter. Одно наблюдаемое следствие стоит запомнить: соединение, пришедшее через docker-proxy, контейнер видит с адреса шлюза моста, а соединение, прошедшее DNAT, — с настоящего адреса клиента.

Как выглядят правила, видно в таблице nat. Пусть контейнер с адресом 172.18.0.2 в пользовательской сети с мостом br-5c1e2a7d9f30 запущен с ключом -p 8080:80. На хосте с бэкендом iptables (вариант по умолчанию, см. раздел о рисках) правила выводятся так:

sudo iptables -t nat -S DOCKER     # то же в виде таблицы: sudo iptables -t nat -L DOCKER -n
sudo iptables -S DOCKER

-N DOCKER
-A DOCKER ! -i br-5c1e2a7d9f30 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 172.18.0.2:80
-N DOCKER
-A DOCKER -d 172.18.0.2/32 ! -i br-5c1e2a7d9f30 -o br-5c1e2a7d9f30 -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER ! -i docker0 -o docker0 -j DROP
-A DOCKER ! -i br-5c1e2a7d9f30 -o br-5c1e2a7d9f30 -j DROP

Первая команда показывает правило трансляции: всё, что пришло не из самого моста на TCP-порт 8080 адреса хоста, направляется на 172.18.0.2:80. Вторая — фильтрующие правила той же цепочки в таблице filter: пропустить в мост пакеты к опубликованному порту контейнера и отбросить всё остальное, что входит в мост извне. Последнее правило — то самое, что изолирует сети друг от друга. Состав и порядок цепочек Docker не является стабильным интерфейсом и меняется между версиями; приведённый вывод соответствует Docker Engine 29 ⁵.

Разберём путь одного соединения с конкретными числами (рисунок ниже). Клиент 192.0.2.50 открывает соединение со своего порта 51000 на адрес хоста 203.0.113.10, порт 8080. Пакет приходит на внешний интерфейс хоста и проходит цепочку PREROUTING таблицы raw, где Docker отбрасывает пакеты, адресованные прямо в 172.18.0.2 откуда-либо, кроме моста; наш пакет адресован хосту и проходит дальше. В цепочке PREROUTING таблицы nat срабатывает DNAT: адрес назначения 203.0.113.10:8080 заменяется на 172.18.0.2:80, а подсистема отслеживания соединений conntrack запоминает эту замену для всего соединения. Теперь адрес назначения не принадлежит хосту, поэтому ядро не передаёт пакет локальным процессам через цепочку INPUT, а пересылает его через цепочку FORWARD. В ней пакет проходит DOCKER-USER, затем DOCKER-FORWARD и попадает под правило ACCEPT цепочки DOCKER, после чего через мост и пару veth доставляется в контейнер. Адрес источника не меняется: приложение в контейнере видит клиента 192.0.2.50:51000. Ответ из контейнера идёт с 172.18.0.2:80 на 192.0.2.50:51000, и conntrack выполняет обратную замену: клиент получает ответ от 203.0.113.10:8080, то есть ровно от того адреса, к которому подключался.

Полезно ясно различать инструкцию EXPOSE в Dockerfile и фактический проброс портов при запуске. EXPOSE — это документация намерения: она сообщает, какие порты приложение собирается слушать, но сама по себе не открывает доступ извне. Реальная публикация формируется только в момент запуска контейнера и определяется параметрами docker run или эквивалентной конфигурацией оркестратора. Смешение этих двух понятий — частый источник недоразумений: кажется, что приложение должно быть доступно, потому что в Dockerfile есть EXPOSE 8080, а на самом деле никакого проброса не выполнено. Единственное место, где EXPOSE влияет на публикацию, — ключ -P: он публикует именно объявленные порты.

Имена сервисов и встроенное разрешение имён

Внутри пользовательской сети Docker контейнеры обращаются друг к другу не по IP-адресам, а по именам. Среда выполнения поднимает встроенный DNS-сервер; в каждом контейнере, подключённом к пользовательской сети, файл /etc/resolv.conf указывает на этот сервер. Когда приложение в контейнере web обращается к адресу db, DNS-запрос разрешается во внутренний IP-адрес контейнера db в той же сети.

Разницу между сетями видно прямо в файле /etc/resolv.conf. В стандартной сети контейнер получает копию настроек хоста (на хосте с systemd-resolved — адреса настоящих серверов, а не петлевой 127.0.0.53, недоступный из контейнера); в пользовательской сети — адрес встроенного сервера ¹:

docker run --rm busybox:1.37 cat /etc/resolv.conf                    # стандартная сеть bridge
docker run --rm --network app-net busybox:1.37 cat /etc/resolv.conf  # пользовательская сеть

# стандартная сеть: копия настроек хоста
nameserver 192.168.1.1
...
# пользовательская сеть: встроенный DNS Docker
nameserver 127.0.0.11
options ndots:0
...

Адрес 127.0.0.11 принадлежит петлевому интерфейсу самого контейнера, поэтому сервер имён не может быть «где-то в сети». Docker добавляет в сетевое пространство имён контейнера правила netfilter, которые перенаправляют запросы с 127.0.0.11:53 на сокет, открытый демоном Docker внутри этого же пространства имён на произвольном порту ⁵. Этот сервер отвечает на имена контейнеров и их псевдонимов в тех сетях, к которым подключён спрашивающий контейнер, а прочие имена пересылает серверам DNS хоста ¹. Отсюда важное следствие: имя другого контейнера разрешается только при наличии общей пользовательской сети. Для контейнера в другой сети имя db не существует, и обращение к нему завершится ошибкой разрешения имени ещё до попытки соединения.

С точки зрения архитектуры приложения это даёт важное свойство: имена сервисов фиксируются в конфигурации приложения, а конкретные адреса — нет. Если контейнер пересоздан и получил другой IP-адрес, имя осталось тем же, и приложение продолжит работать без правок. Это первый шаг от модели «сервер с фиксированным IP» к модели «сервис с устойчивым именем», которая в полной мере раскрывается в оркестраторе.

Стандартный мост docker0 встроенного DNS не имеет; для разрешения имён необходимо явно создать пользовательскую сеть. По этой причине рекомендация «не использовать стандартный мост в прикладных конфигурациях» имеет не стилистический, а практический характер: только пользовательская сеть даёт устойчивое именование, а значит — переносимую конфигурацию приложения.

Разделение фронтальной и внутренней связности

Типичная многосервисная конфигурация на одном хосте требует разделения сетевых ролей. Часть сервисов обслуживает внешних клиентов (фронтальный веб-сервер, API-шлюз) — они публикуют порты наружу. Другая часть работает только во внутренней сети приложения (база данных, очередь сообщений, кеш) — наружу они не публикуются принципиально и должны быть недоступны для прямых внешних обращений.

Простейший способ обеспечить это разделение — две пользовательские сети: одна, в которой находятся фронтальные сервисы и шлюз, и вторая, к которой подключены шлюз и внутренние сервисы. Шлюз присутствует в обеих сетях; внутренние сервисы видят его, но не видят фронтального трафика напрямую. Такая структура — базовый сетевой шаблон контейнерных приложений: «опубликовать минимум, оставить остальное во внутреннем периметре». Декларативное описание подобной топологии естественным образом ложится в формат Docker Compose; полный пример такого приложения с двумя сетями разобран в разделе «Docker Compose» в конце темы.

Сетевые риски и эксплуатационные ограничения

Сетевая модель Docker удобна и компактна, но именно её простота создаёт несколько типичных эксплуатационных рисков. Они проявляются не в учебных сценариях, а на этапе сопровождения, когда конфигурация переходит из рук разработчика в эксплуатацию.

Первый и наиболее распространённый риск — избыточная сетевая открытость. Привычка публиковать порт «на всякий случай» приводит к тому, что внутренние сервисы — базы данных, административные интерфейсы, отладочные эндпоинты — оказываются доступны извне. На рабочей машине разработчика это незаметно, но при переносе конфигурации на сервер с публичным сетевым адресом ошибка превращается в открытую дверь. Правило здесь простое: публиковаться наружу должны только порты, действительно нужные внешним клиентам; всё остальное должно оставаться во внутренней пользовательской сети.

Второй риск связан с используемым адресом привязки на стороне хоста. По умолчанию -p 8080:8080 биндится на адрес 0.0.0.0, то есть на все интерфейсы хоста, включая внешние. Если требуется ограничить публикацию только локальной машиной, привязку нужно делать явно: -p 127.0.0.1:8080:8080. Это типовая ошибка при работе с серверами, имеющими несколько сетевых интерфейсов: разработчик считает, что сервис «слушает локально», а на деле он слушает все интерфейсы. Ошибку усугубляет то, что межсетевой экран хоста от неё не защищает: опубликованные порты обходят правила ufw (подробно — в подразделе об обходе межсетевого экрана ниже).

Третье ограничение — пределы локальной сетевой модели. Стандартные сети Docker (мостовые и пользовательские) работают в пределах одного хоста. Если приложение нужно распределить по нескольким хостам, эти средства уже недостаточны: требуются либо специализированные драйверы вроде overlay в режиме Docker Swarm (в курсе не изучаются), либо переход к оркестратору с собственной сетевой моделью — этот путь и выбран в теме 7. Локальная контейнерная сеть удобна для разработки, тестирования и одно-узловой эксплуатации; при выходе за этот сценарий она перестаёт быть достаточной, и попытки обойти ограничение «вручную» обычно приводят к хрупким конфигурациям.

Наконец, в эксплуатации значимым становится документирование сетевых зависимостей между сервисами. В контейнерной среде эти зависимости естественным образом скрыты внутри частных сетей, и их легко потерять из виду. Какой сервис обращается к какому, на каких портах, по какой сети — всё это должно быть явно зафиксировано в декларативном описании приложения и в эксплуатационной документации. Без такой фиксации диагностика проблем превращается в реверс-инжиниринг: при сетевом сбое непонятно, какой компонент чего ждал и где именно разорвалось соединение.

Опубликованные порты в обход межсетевого экрана хоста

Самый неожиданный для администратора риск связан с тем, как публикация портов встроена в netfilter. Типичная настройка сервера на Ubuntu — ufw с политикой «запретить все входящие, кроме SSH». Администратор публикует контейнер с базой данных ключом -p 5432:5432, проверяет sudo ufw status, видит, что порт 5432 не разрешён, и считает базу закрытой. Однако база доступна из Интернета.

Причина видна на рисунке с путём пакета выше. Правила ufw живут в цепочке INPUT таблицы filter — она применяется к пакетам, адресованным локальным процессам хоста. Пакет к опубликованному порту ещё в PREROUTING получает DNAT на адрес контейнера, после чего он адресован уже не хосту, а пересылается в мост через цепочку FORWARD. До цепочки INPUT он не доходит, и правила ufw к нему не применяются ⁴. Документация Docker прямо называет Docker и ufw несовместимыми в этом отношении. Вывод ss -ltnp, где порт «слушает» docker-proxy, только усиливает иллюзию: кажется, что это обычный локальный сокет, на который распространяется ufw.

Защиту выстраивают на трёх уровнях. Первый и главный — не публиковать лишнего: внутренним сервисам порты не нужны, они доступны соседям по пользовательской сети. Второй — привязка к адресу: -p 127.0.0.1:8080:80 публикует порт только на петлевом интерфейсе, и Docker начиная с версии 28 дополнительно отбрасывает в raw PREROUTING пакеты к такому порту, пришедшие не с lo; до версии 28 соседние узлы того же сегмента L2 могли достучаться и до порта, опубликованного на 127.0.0.1 ³. Адрес привязки по умолчанию можно сменить для сети целиком опцией com.docker.network.bridge.host_binding_ipv4. Третий — собственные правила фильтрации в цепочке DOCKER-USER, которую Docker создаёт пустой и вызывает из FORWARD раньше своих правил ⁵. Например, разрешить доступ к опубликованным портам только из локальной сети 192.168.1.0/24 через внешний интерфейс eth0:

sudo iptables -I DOCKER-USER -i eth0 ! -s 192.168.1.0/24 -j DROP
sudo iptables -I DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Второе правило вставляется выше первого и пропускает ответы на соединения, которые контейнеры открыли сами. Следует учитывать, что в DOCKER-USER пакет приходит уже после DNAT: условия на порт должны указывать порт контейнера, а не хоста, либо использовать расширение conntrack с параметром --ctorigdstport ⁵. Docker не сохраняет правила DOCKER-USER между перезагрузками хоста: их сохраняют теми же средствами, что и прочие правила iptables, например пакетом iptables-persistent.

Правила Docker в netfilter: iptables и nftables

Docker Engine создаёт свои правила через один из двух бэкендов, выбираемых параметром демона firewall-backend ⁴. По умолчанию это iptables: цепочки DOCKER, DOCKER-USER, DOCKER-FORWARD, DOCKER-BRIDGE, DOCKER-CT, DOCKER-INTERNAL в таблице filter, цепочка DOCKER в таблице nat и правила в таблице raw ⁵. В Ubuntu 24.04 команда iptables по умолчанию сама является надстройкой над nftables (вариант iptables-nft), поэтому те же правила видны и в выводе sudo nft list ruleset — как таблицы ip filter, ip nat, ip raw с цепочками, названными по-iptables-овски.

С версии 29.0 у Docker есть и собственный бэкенд nftables, включаемый строкой "firewall-backend": "nftables" в /etc/docker/daemon.json. На момент написания он объявлен экспериментальным: его поведение может меняться, а в режиме Swarm он не работает ⁶. Правила при этом сосредоточены в таблицах ip docker-bridges и ip6 docker-bridges, по набору цепочек на каждую сеть. Фрагмент для контейнера 192.0.2.2, опубликованного с ключом -p 8080:80 в сети с мостом bridge1, выглядит так (пример из внутренней документации проекта moby, на которую ссылается ⁶):

sudo nft list table ip docker-bridges

table ip docker-bridges {
	...
	chain nat-prerouting-and-output {
		iifname != "bridge1" tcp dport 8080 counter dnat to 192.0.2.2:80 comment "DNAT"
	}
	chain raw-PREROUTING {
		type filter hook prerouting priority raw; policy accept;
		ip daddr 192.0.2.2 iifname != "bridge1" counter drop comment "DROP DIRECT ACCESS"
	}
	chain filter-forward-in__bridge1 {
		ct state established,related counter accept
		iifname "bridge1" counter accept comment "ICC"
		ip daddr 192.0.2.2 tcp dport 80 counter accept
		counter drop comment "UNPUBLISHED PORT DROP"
	}
	...
}

Логика та же — DNAT, запрет прямого доступа, разрешение опубликованного порта, отбрасывание остального, — но выражена в терминах nftables. Есть и практические отличия. Цепочки DOCKER-USER в бэкенде nftables нет: собственные правила кладут в отдельную таблицу с базовой цепочкой на нужном хуке и приоритете. Правило accept в nftables не окончательно — пакет, принятый в одной базовой цепочке, может быть отброшен в другой, поэтому «разрешающие» правила в обход Docker делаются через метку пакета и параметр --bridge-accept-fwmark. Наконец, с бэкендом nftables Docker сам не включает пересылку пакетов в ядре и не ставит политику DROP для пересылки, и об этой защите хоста администратор заботится сам ⁶. В этом курсе используется бэкенд по умолчанию, iptables.

Особенности IPv6 и Docker Desktop

IPv6 в пользовательской сети включается ключом docker network create --ipv6 (в Compose — enable_ipv6: true у сети). Подсеть IPv6 можно указать явно или поручить выбор Docker. Для IPv6 Docker создаёт те же правила, что и для IPv4, через ip6tables. Даже в сети без IPv6 порт, опубликованный без указания адреса, по умолчанию слушается и на IPv6-адресах хоста: через docker-proxy соединение на IPv6-адрес хоста доставляется на IPv4-адрес контейнера ³. Поэтому -p 0.0.0.0:8080:80 и -p 8080:80 — не одно и то же: первый вариант публикует порт только для IPv4. Отдельно стоит режим шлюза routed, в котором NAT не используется вовсе и контейнеры доступны по своим адресам; он рассчитан прежде всего на IPv6 с маршрутизируемыми адресами ³.

Docker Desktop для macOS и Windows, а также Docker Desktop для Linux запускают Docker Engine внутри служебной виртуальной машины (тема 3). Всё сказанное в теме о мостах, veth и правилах netfilter верно, но происходит внутри этой машины. Отсюда наблюдаемые отличия ¹⁰. На хосте нет интерфейса docker0, и команды ip link, iptables, nft на хосте правил Docker не покажут. IP-адреса контейнеров с хоста недоступны: Docker Desktop не маршрутизирует трафик к Linux-контейнерам, поэтому единственный путь к ним — опубликованные порты. Опубликованный порт слушает на хосте процесс Docker Desktop, пересылающий соединения в виртуальную машину; именно к этому процессу и применяются правила межсетевого экрана хоста. Наконец, из контейнера хост доступен по имени host.docker.internal. Эти отличия нужно держать в голове, читая лабораторную работу: наблюдение мостов и правил netfilter в ней требует Docker Engine на Linux.

Docker Compose

Всё, что разобрано выше, выполнялось отдельными командами: создать сети, запустить контейнеры с нужными ключами -p, --network, -e, -v, подключить шлюз ко второй сети. Для приложения из трёх контейнеров это десяток команд с длинными строками параметров, которые нужно выполнять в правильном порядке и повторять при каждом пересоздании. Docker Compose решает эту задачу: приложение описывается одним файлом, а среда выполнения сама приводит набор контейнеров, сетей и томов в соответствие с описанием. Формат файла стандартизован спецификацией Compose (англ. Compose Specification) ⁸; в курсе используется реализация Docker Compose v2 — подкоманда docker compose (версии 2.29 и новее; на момент написания актуальна ветка 5.x).

Декларативная модель проекта

Описание в Compose декларативно: в файле записано, что должно существовать, а не какие команды выполнить. Команда docker compose up сравнивает описание с тем, что уже запущено, и создаёт недостающее, пересоздаёт изменившееся и не трогает совпадающее. Чтобы находить «свои» объекты, Compose помечает каждый созданный контейнер, сеть и том метками com.docker.compose.project и com.docker.compose.service, а в метке com.docker.compose.config-hash хранит хеш конфигурации сервиса: если хеш не изменился, контейнер не пересоздаётся.

Модель Compose состоит из четырёх понятий.

• Проект (англ. project) — единица развёртывания: всё, что описано в одном файле compose.yaml (или в нескольких, наложенных друг на друга ключами -f). Имя проекта берётся из поля name: или из имени каталога и служит префиксом всех объектов. Два проекта с разными именами на одном хосте не мешают друг другу.
• Сервис (англ. service) — описание одного компонента: образ или инструкции сборки, переменные окружения, порты, сети, тома, проверка здоровья, политика перезапуска. Из сервиса создаётся один или несколько контейнеров с именами вида <проект>-<сервис>-<номер>.
• Сеть — пользовательская сеть Docker с именем <проект>_<сеть>. Если сети не описаны, Compose создаёт одну сеть <проект>_default и подключает к ней все сервисы ⁹.
• Том — именованный том Docker с именем <проект>_<том> (тома разобраны в теме 5). Тома переживают пересоздание контейнеров и удаляются только явно: docker compose down -v.

Сеть проекта — обычная пользовательская мостовая сеть, поэтому для неё верно всё сказанное выше о встроенном DNS. Каждый сервис доступен остальным по имени сервиса: backend обращается к базе по адресу db:5432, не зная её IP-адреса ⁹. Когда контейнер пересоздаётся после изменения конфигурации, он получает новый адрес, но то же имя; открытые соединения со старым контейнером при этом рвутся, и приложение должно уметь переподключаться ⁹. Если у сервиса несколько контейнеров (docker compose up --scale backend=3), имя сервиса разрешается во все их адреса. Порт в обращении между сервисами — порт контейнера; опубликованный порт хоста из раздела ports нужен только клиентам вне сетей проекта.

Трёхзвенное приложение в двух сетях

Полный пример описывает приложение из трёх компонентов: frontend на nginx отдаёт статику и проксирует /api/ на backend, backend работает с PostgreSQL. Сетевая топология повторяет шаблон из раздела о публикации сервисов: сеть front для frontend и backend, внутренняя сеть back для backend и базы. Схема на рисунке ниже показывает, кто кого видит.

name: notes

services:
  frontend:
    image: nginx:1.28-alpine
    ports:
      - "127.0.0.1:${FRONT_PORT:-8080}:80"     # только на петлевом адресе хоста
    volumes:
      - ./frontend/nginx.conf:/etc/nginx/conf.d/default.conf:ro
    networks: [front]
    depends_on:
      backend:
        condition: service_healthy
    restart: unless-stopped

  backend:
    build: ./backend
    environment:
      DB_HOST: db                               # имя сервиса, а не IP-адрес
      DB_USER: ${DB_USER:-notes}
      DB_PASSWORD: ${DB_PASSWORD:?задайте DB_PASSWORD в файле .env}
    networks: [front, back]                     # шлюз между сетями
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://127.0.0.1:3000/api/health"]
      interval: 10s
      timeout: 3s
      retries: 3
      start_period: 20s
    restart: unless-stopped

  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_DB: notes
      POSTGRES_USER: ${DB_USER:-notes}
      POSTGRES_PASSWORD: ${DB_PASSWORD:?задайте DB_PASSWORD в файле .env}
    volumes:
      - dbdata:/var/lib/postgresql/data
    networks: [back]
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 5s
      timeout: 3s
      retries: 10
    restart: unless-stopped

  toolbox:                                      # отладка, только по запросу
    image: busybox:1.37
    profiles: [debug]
    network_mode: "service:backend"
    command: ["sleep", "infinity"]

networks:
  front: {}
  back:
    internal: true                              # без выхода наружу

volumes:
  dbdata: {}

Строки version: в файле нет: поле устарело, спецификация Compose его не использует, а современный Compose при его наличии выводит предупреждение. Разберём сетевую часть. Сервис db подключён только к сети back, и у него нет раздела ports: из сети front он невидим (имя db там не разрешается, а пакеты к его адресу отбрасываются межсетевой изоляцией), с других машин — тем более. Сервис backend подключён к обеим сетям и получает два интерфейса; через сеть front к нему обращается nginx, через сеть back он сам обращается к базе. Сервис frontend — единственный с опубликованным портом, причём только на 127.0.0.1: на сервере перед ним обычно стоит обратный прокси или балансировщик, а для разработки достаточно локального доступа.

Ключ internal: true делает сеть внутренней: Docker не назначает в ней маршрут по умолчанию и не создаёт правил маскарадинга, а правила цепочки DOCKER-INTERNAL отбрасывают пакеты, уходящие из подсети сети или приходящие в неё извне ⁵⁹. Контейнер, подключённый только к внутренней сети, не может открыть соединение с Интернетом: попытка подключиться к внешнему адресу завершится ошибкой Network is unreachable. Контейнер, подключённый и к внутренней, и к обычной сети, как backend, выходит наружу через обычную сеть. Две оговорки. Опубликовать порт контейнера, состоящего только во внутренней сети, нельзя: правил DNAT для неё Docker не создаёт. И внутренняя сеть не изолирована от самого хоста: мост получает адрес в её подсети, так что процессы хоста могут обращаться к контейнерам этой сети напрямую ³.

Том dbdata подключён к каталогу данных PostgreSQL, поэтому docker compose down и повторный up сохраняют данные, а docker compose down -v их удаляет. Путь /var/lib/postgresql/data верен для образа postgres:17; в образах PostgreSQL 18 каталог данных по умолчанию изменился, поэтому версию образа и путь тома следует менять вместе.

Порядок запуска: healthcheck, depends_on и restart

Без указаний Compose запускает сервисы параллельно. Ключ depends_on задаёт порядок: зависимый сервис создаётся после тех, от которых зависит, а останавливается раньше них ⁸. Но короткая форма depends_on: [db] гарантирует лишь, что контейнер db запущен, то есть его процесс стартовал. Готовность принимать соединения — другое событие: PostgreSQL после старта процесса ещё несколько секунд инициализирует каталог данных и открывает порт позже. Если backend при запуске сразу подключается к базе, возникает гонка старта (англ. race condition): на быстрой машине всё работает, на медленной или при первом запуске backend падает с ошибкой «соединение отклонено».

Решение — связать порядок запуска с проверкой готовности. Ключ healthcheck описывает команду проверки здоровья, которую Docker выполняет внутри контейнера — механизм тот же, что у инструкции HEALTHCHECK из темы 5. Длинная форма depends_on с условием condition: service_healthy заставляет Compose ждать, пока проверка зависимости не перейдёт в состояние healthy ⁸. Параметры проверки определяют, сколько времени займёт ожидание:

Значения по умолчанию совпадают с инструкцией HEALTHCHECK ⁸. Условий три: service_started (эквивалент короткой формы), service_healthy и service_completed_successfully — для одноразовых задач вроде миграции схемы, которые должны завершиться с кодом 0 до старта основного сервиса. Если зависимость не становится здоровой (или завершается), docker compose up сообщает об ошибке зависимости, а зависимый сервис не запускается. Обратим внимание на двойной знак доллара в проверке базы: $${POSTGRES_USER} экранирует подстановку, чтобы переменную раскрыла оболочка внутри контейнера, а не Compose при чтении файла.

У этой схемы есть границы, о которых важно помнить. Проверка здоровья должна проверять сам сервис, а не его зависимости: если проверка backend обращается к базе, падение базы сделает «нездоровым» и backend, и в оркестраторе это приведёт к каскадным перезапускам (тема 7). depends_on влияет только на запуск: если база упадёт через час, Compose ничего не сделает с backend, и приложение должно само переживать временную недоступность зависимостей. Наконец, restart (значения no, always, on-failure[:N], unless-stopped, см. тему 5) исполняет не Compose, а демон Docker — это та же политика перезапуска контейнера. Политика перезапуска может замаскировать гонку старта: backend упадёт, перезапустится и со второй-третьей попытки подключится к уже готовой базе. Система работает, но первые секунды её журнал полон ошибок, а время старта непредсказуемо.

Переменные, профили и проверка конфигурации

Значения, которые различаются между окружениями (порты, пароли, версии образов), выносят в переменные. Compose подставляет их в файл при чтении (англ. interpolation): ${VAR} — значение переменной, ${VAR:-default} — значение по умолчанию, если переменная не задана или пуста, ${VAR:?сообщение} — ошибка с сообщением, если не задана ⁸. Значения берутся из окружения оболочки и из файла .env в каталоге проекта; переменная оболочки важнее файла. Файл .env для примера выше:

FRONT_PORT=8080
DB_USER=notes
DB_PASSWORD=change-me

Файл .env с паролями не помещают в систему контроля версий; в репозиторий кладут его образец без секретов. Важно различать два механизма: переменные из .env подставляются в файл Compose, а раздел environment сервиса передаёт переменные в контейнер. Значение попадает в контейнер, только если оно указано в environment или подключено ключом env_file.

Профили (англ. profiles) позволяют держать в одном файле вспомогательные сервисы, которые не нужны при обычном запуске. Сервис без ключа profiles включён всегда, сервис с профилем — только когда профиль активен: docker compose --profile debug up или переменная COMPOSE_PROFILES=debug ⁸. Сервис, явно названный в команде, включается и без этого: docker compose run --rm toolbox ip addr запустит отладочный контейнер в сетевом пространстве backend и покажет его интерфейсы.

Перед запуском полезно посмотреть, во что Compose превратил файл после подстановки переменных, наложения нескольких файлов и подстановки значений по умолчанию. Это делает команда docker compose config. Она проверяет синтаксис и ссылки (на несуществующую сеть, неопределённую обязательную переменную) и печатает итоговую модель, не обращаясь к демону Docker:

docker compose config --quiet && echo "файл корректен"
docker compose config        # итоговая модель целиком

...
networks:
  back:
    name: notes_back
    internal: true
  front:
    name: notes_front
volumes:
  dbdata:
    name: notes_dbdata

В выводе видны окончательные имена сетей и томов с префиксом проекта. Если удалить из .env строку с паролем, та же команда завершится ошибкой required variable DB_PASSWORD is missing a value: задайте DB_PASSWORD в файле .env — проблема обнаружится до запуска, а не в журнале упавшего контейнера.

Границы Compose: один хост без согласования состояния

Compose удобен для разработки, тестирования и небольших развёртываний на одном сервере, но его модель имеет принципиальные пределы, и именно они ведут к оркестратору.

Первый предел — один хост. Compose обращается к одному демону Docker, и все контейнеры проекта работают на одной машине. Сети проекта — мосты этой машины, тома — каталоги на её диске. Разместить сервисы на нескольких серверах, распределить нагрузку между ними или пережить отказ сервера Compose не может.

Второй предел — сверка желаемого и фактического состояния выполняется только в момент команды. docker compose up действительно сравнивает описание с запущенными объектами и устраняет расхождения, но делает это один раз и завершается. Если после этого контейнер удалят вручную, изменят его параметры или откажет весь хост, Compose об этом не узнает: следить за состоянием некому. Политика restart частично закрывает этот пробел, но её исполняет локальный демон Docker, и она умеет только перезапустить тот же контейнер на той же машине. При отказе хоста перезапускать нечего и негде.

Третий предел — обновления. При изменении образа docker compose up останавливает старый контейнер и запускает новый; на время замены сервис недоступен. Постепенной замены экземпляров с проверкой готовности, отката при неудаче, автоматического масштабирования по нагрузке в Compose нет.

Оркестратор устроен иначе: желаемое состояние хранится в кластере, а контроллеры непрерывно сравнивают его с фактическим и исправляют расхождения на любом из узлов. Это цикл согласования (англ. reconciliation loop), с которого начинается тема 7. Понятия Compose при этом переносятся почти напрямую: сервис соответствует объектам Deployment и Service, имя сервиса в DNS — имени объекта Service, сеть проекта — сети кластера, healthcheck — пробам готовности и живости, --network container: — общему сетевому пространству контейнеров пода, а внутренняя сеть back — сетевой политике, которая разрешает обращаться к базе только backend (тема 11).

Итоги темы

Сетевое взаимодействие контейнерных приложений строится на двухуровневой модели: с одной стороны — изолированное сетевое пространство имён каждого контейнера, с другой — явные точки прозрачности, через которые контейнер сообщается с внешним миром и с другими контейнерами. Связь между уровнями обеспечивают пары виртуальных интерфейсов и программные мосты в пространстве хоста; пакеты ходят между мостом и контейнером прозрачно, а наружу — через таблицу маршрутизации и трансляцию адресов хоста.

Конкретный режим сети задаётся драйвером. Для подавляющего большинства учебных и однохостовых задач используется драйвер bridge, причём предпочтительна не стандартная сеть docker0, а явно созданная пользовательская сеть со встроенным разрешением имён. Режим host отказывается от изоляции в пользу прямого доступа к стеку хоста и применим только в узких сценариях оптимизации. Специальные драйверы (macvlan, ipvlan, overlay) решают задачи включения контейнера в физическую сеть и связи нескольких хостов; в курсе они подробно не рассматриваются, а многохостовая сеть изучается на примере Kubernetes. Режим --network container:, при котором несколько контейнеров разделяют один сетевой стек, — прямой прообраз пода.

Прикладная сторона сети — это два механизма: проброс портов наружу и обнаружение сервисов внутри. Первый делает контейнер доступным внешним клиентам через явный выбор хостового порта; второй позволяет контейнерам обращаться друг к другу по устойчивым именам, не завися от конкретных IP. Сочетание этих механизмов и нескольких пользовательских сетей даёт основной сетевой шаблон контейнерных приложений: «публиковать только то, что должно быть видно снаружи; всё внутреннее оставлять в частных сетях».

Эксплуатационные риски сетевой модели предсказуемы и связаны не с её сложностью, а с привычкой разработчика к удобной открытой среде. Избыточно опубликованные порты, привязка к 0.0.0.0 без необходимости, недокументированные зависимости между сервисами — типичные источники проблем. Особенно опасно то, что опубликованный порт проходит через цепочку FORWARD, минуя правила ufw в цепочке INPUT: закрывать такие порты нужно привязкой к 127.0.0.1 или правилами в DOCKER-USER, а не настройкой межсетевого экрана хоста. Наблюдать всё это позволяют правила netfilter: DNAT в таблице nat, фильтрация и межсетевая изоляция в таблице filter, — выводимые через iptables или, в экспериментальном бэкенде, через nft.

Docker Compose переводит эту сетевую модель в декларативное описание проекта: сервисы, сети, тома и порядок запуска записываются в одном файле, имя сервиса становится его DNS-именем, а внутренняя сеть с internal: true реализует шаблон «опубликовать минимум» без единой команды docker network. Связка healthcheck и depends_on с условием service_healthy устраняет гонку старта. Но Compose сверяет желаемое и фактическое состояние только в момент команды и только на одном хосте; непрерывное согласование состояния на множестве узлов — задача оркестратора, с которой начинается тема 7.

Литература

1. Docker Documentation. Networking overview. — https://docs.docker.com/engine/network/ (дата обращения: 22.10.2026).
2. Docker Documentation. Bridge network driver. — https://docs.docker.com/engine/network/drivers/bridge/ (дата обращения: 22.10.2026).
3. Docker Documentation. Port publishing and mapping. — https://docs.docker.com/engine/network/port-publishing/ (дата обращения: 22.10.2026).
4. Docker Documentation. Packet filtering and firewalls. — https://docs.docker.com/engine/network/packet-filtering-firewalls/ (дата обращения: 22.10.2026).
5. Docker Documentation. Docker with iptables. — https://docs.docker.com/engine/network/firewall-iptables/ (дата обращения: 22.10.2026).
6. Docker Documentation. Docker with nftables. — https://docs.docker.com/engine/network/firewall-nftables/ (дата обращения: 22.10.2026).
7. Docker Documentation. Docker Engine 29 release notes. — https://docs.docker.com/engine/release-notes/29/ (дата обращения: 22.10.2026).
8. Docker Documentation. Compose file reference (Compose Specification). — https://docs.docker.com/reference/compose-file/ (дата обращения: 22.10.2026).
9. Docker Documentation. Networking in Compose. — https://docs.docker.com/compose/how-tos/networking/ (дата обращения: 22.10.2026).
10. Docker Documentation. Networking on Docker Desktop. — https://docs.docker.com/desktop/features/networking/ (дата обращения: 22.10.2026).
11. Linux man-pages project. network_namespaces(7) — overview of Linux network namespaces. — https://man7.org/linux/man-pages/man7/network_namespaces.7.html (дата обращения: 22.10.2026).
12. Linux man-pages project. veth(4) — Virtual Ethernet Device. — https://man7.org/linux/man-pages/man4/veth.4.html (дата обращения: 22.10.2026).

Дополнительные материалы

Вопросы для самопроверки

1. Какие ресурсы ядра изолирует сетевое пространство имён и почему физический интерфейс не может одновременно принадлежать двум пространствам?
2. Что означает запись eth0@if7 в выводе ip addr внутри контейнера и как найти парный интерфейс на хосте?
3. Чем пользовательская мостовая сеть отличается от стандартной сети bridge? Назовите не менее трёх отличий.
4. Почему в контейнере стандартной сети нельзя оставить в /etc/resolv.conf адрес 127.0.0.53 хоста с systemd-resolved, а в пользовательской сети адрес 127.0.0.11 работает?
5. Какие правила netfilter создаёт Docker при запуске контейнера с ключом -p 8080:80? В каких таблицах и цепочках они находятся?
6. Почему опубликованный порт доступен извне при политике ufw «запретить все входящие»? Какие три способа ограничить доступ к нему предлагает документация Docker?
7. В чём разница между -p 8000, -P и -p 8000:8000? Когда -P ничего не публикует?
8. Зачем нужен docker-proxy и что изменится, если отключить его параметром "userland-proxy": false?
9. Почему контейнер, подключённый к двум сетям, не превращается в маршрутизатор между ними? Как тогда он служит «шлюзом» между фронтальной и внутренней сетью?
10. Что делает internal: true с сетью и от чего такая сеть не защищает?
11. Чем depends_on в короткой форме отличается от длинной формы с condition: service_healthy? Что произойдёт, если зависимость станет нездоровой через час после запуска?
12. Как Compose определяет, нужно ли пересоздать контейнер при повторном docker compose up?
13. Чем подстановка переменных из .env в файл Compose отличается от передачи переменных в контейнер? Какое значение победит, если переменная задана и в оболочке, и в .env?
14. Какие отличия сетевой модели Docker Desktop от Docker Engine на Linux важны при диагностике?
15. Что общего у режима --network container: и пода Kubernetes? Какие пространства имён у контейнеров пода общие?

Глоссарий темы

Шпаргалка по инструментам

Сети Docker:

docker network ls                                    # все сети
docker network create --subnet 10.61.0.0/24 app-net  # пользовательская сеть
docker network create --internal back-net            # внутренняя сеть без выхода наружу
docker network inspect app-net                       # подсеть, шлюз, подключённые контейнеры
docker network connect app-net web                   # подключить работающий контейнер
docker network disconnect app-net web                # отключить
docker network rm app-net                            # удалить (если нет контейнеров)
docker run --network container:web busybox:1.37 ip addr   # общий сетевой стек с web
docker inspect -f '{{range $k, $v := .NetworkSettings.Networks}}{{$k}}={{$v.IPAddress}} {{end}}' web

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

docker run -p 8080:80 nginx:1.28-alpine            # на всех адресах хоста, IPv4 и IPv6
docker run -p 127.0.0.1:8080:80 nginx:1.28-alpine  # только локально
docker run -p 0.0.0.0:8080:80 nginx:1.28-alpine    # только IPv4
docker run -p 80 nginx:1.28-alpine                 # случайный порт хоста
docker run -P nginx:1.28-alpine                    # все порты из EXPOSE на случайных портах
docker port КОНТЕЙНЕР                               # что опубликовано

Наблюдение на хосте (Docker Engine на Linux):

ip -br link show type bridge                 # мосты docker0 и br-…
ip -br link show master docker0              # veth, подключённые к мосту
sudo ss -ltnp                                # docker-proxy на опубликованных портах
sudo iptables -t nat -S DOCKER               # DNAT опубликованных портов
sudo iptables -t nat -L DOCKER -n -v         # то же со счётчиками
sudo iptables -S DOCKER                      # ACCEPT опубликованных портов, DROP прочего
sudo iptables -S DOCKER-INTERNAL             # правила внутренних сетей
sudo iptables -t raw -S PREROUTING           # запрет прямого доступа к контейнерам
sudo iptables -I DOCKER-USER -i eth0 ! -s 192.168.1.0/24 -j DROP   # ограничить доступ
sudo nft list table ip docker-bridges        # правила при "firewall-backend": "nftables"

Docker Compose:

Что почитать и посмотреть

• Docker Documentation. Networking overview и Bridge network driver — https://docs.docker.com/engine/network/ и https://docs.docker.com/engine/network/drivers/bridge/. Первоисточник по сетям Docker: отличия пользовательских сетей, встроенный DNS, --network container:, параметры мостов. Стоит прочитать целиком после темы.
• Docker Documentation. Packet filtering and firewalls, Docker with iptables, Docker with nftables — https://docs.docker.com/engine/network/packet-filtering-firewalls/. Описание цепочек Docker, совместимости с ufw и firewalld, миграции на nftables. Обязательное чтение перед размещением Docker на сервере с публичным адресом.
• Документация проекта moby о правилах iptables и nftables — https://github.com/moby/moby/blob/master/integration/network/bridge/iptablesdoc/index.md. Сгенерированные тестами полные наборы правил для типовых сценариев: публикация порта, петлевой адрес, внутренняя сеть, режим routed. Лучший способ понять, какое правило за что отвечает; формат меняется между версиями.
• Compose Specification — https://github.com/compose-spec/compose-spec/blob/main/spec.md и справочник https://docs.docker.com/reference/compose-file/. Полное описание формата: все поля сервисов, сетей, томов, правила слияния нескольких файлов, подстановка переменных.
• Docker Documentation. Networking in Compose и Control startup and shutdown order — https://docs.docker.com/compose/how-tos/networking/ и https://docs.docker.com/compose/how-tos/startup-order/. Практические руководства по сетям проекта, внутренним сетям и depends_on с проверками здоровья.
• Docker Documentation. Networking on Docker Desktop — https://docs.docker.com/desktop/features/networking/. Как Docker Desktop передаёт трафик между хостом и виртуальной машиной и почему с хоста не видны мосты и адреса контейнеров.
• Linux man-pages: network_namespaces(7), veth(4), ip-netns(8) — https://man7.org/linux/man-pages/man7/network_namespaces.7.html. Краткие и точные описания механизмов ядра, на которых построены сети контейнеров; ip netns позволяет повторить схему Docker вручную.
• Ivan Velichko. How Container Networking Works: Building a Bridge Network From Scratch — https://iximiuz.com/en/posts/container-networking-is-simple/. Пошаговая сборка мостовой сети контейнеров из ip netns, veth и iptables без Docker; после неё правила Docker читаются как знакомые.
• Julia Evans. A container networking overview — https://jvns.ca/blog/2016/12/22/container-networking/. Короткий обзор способов связать контейнеры между хостами: оверлеи, маршрутизация, VXLAN. Полезен как мостик к сетевой модели Kubernetes.
• Kubernetes Documentation. Pods — https://kubernetes.io/docs/concepts/workloads/pods/. Модель пода как группы контейнеров с общим сетевым пространством; продолжение темы --network container:.

Углубление (по желанию)

От --link к встроенному DNS

В ранних версиях Docker пользовательских сетей не было, и все контейнеры жили в стандартной сети bridge. Чтобы один контейнер мог найти другой, использовался ключ --link: Docker дописывал в /etc/hosts контейнера строку с адресом связанного контейнера и передавал ему переменные окружения вида DB_PORT_5432_TCP_ADDR. Связи были однонаправленными, не переживали пересоздание контейнера с новым адресом и требовали запускать контейнеры в определённом порядке. Пользовательские сети со встроенным DNS заменили этот механизм: имя разрешается в момент обращения, а адрес может меняться сколько угодно. Документация Docker называет --link устаревшим механизмом, и именно поэтому стандартная сеть bridge до сих пор не имеет DNS: её поведение сохранено ради совместимости.

Почему iptables уступает место nftables

Docker почти десять лет создавал правила через утилиту iptables, а за это время сам netfilter сменил интерфейс: подсистема nftables с единым синтаксисом для IPv4, IPv6 и мостов, атомарной заменой наборов правил и словарями (vmap) вместо длинных линейных цепочек. Большинство дистрибутивов сделали iptables надстройкой над nftables (iptables-nft), так что правила Docker давно хранятся в nftables, только в «переводе» со старого синтаксиса. В Docker Engine 28 правила мостовых сетей были серьёзно переработаны в том числе ради перехода на nftables, в Engine 29 появился собственный экспериментальный бэкенд, создающий таблицы docker-bridges. Та же эволюция идёт в Kubernetes, где у kube-proxy есть режим nftables. Практическое следствие для администратора: правила, написанные под iptables (например, в DOCKER-USER), при смене бэкенда придётся переносить вручную.

Как Compose стал спецификацией

Первая реализация Compose (утилита docker-compose, написанная на Python) читала файл docker-compose.yml с обязательным полем version, и форматы версий 2 и 3 различались набором возможностей: версия 3 была ориентирована на Docker Swarm и, например, лишилась условий в depends_on. В 2020 году формат был выделен в открытую спецификацию Compose Specification, объединившую возможности всех версий, а инструмент переписан на Go и стал подкомандой docker compose. Поле version в спецификации больше не используется, а условия service_healthy и service_completed_successfully вернулись. Поэтому в старых руководствах можно встретить утверждения, что depends_on «не умеет ждать готовности», — для современного Compose они неверны.

Лабораторная работа 6. Сетевая изоляция многоконтейнерного приложения в Docker Compose

• Раздел курса: тема 6 «Сетевое взаимодействие контейнерных приложений»

Введение

В лабораторной работе 5 контейнер рассматривался как управляемый процесс: параметры запуска, сигналы, политика перезапуска, проверка здоровья. Все контейнеры той работы жили поодиночке. Настоящая работа собирает из них приложение и отвечает на вопросы, которые возникают, как только контейнеров становится больше одного. Как контейнеры находят друг друга? Почему один контейнер видит другой, а третий — нет? Что на самом деле делает ключ -p и почему опубликованный порт может оказаться открытым всему Интернету при включённом межсетевом экране? Как сделать, чтобы база данных была недоступна никому, кроме backend, и не могла сама ходить наружу?

Работа идёт от ручных команд к декларативному описанию. Сначала сети создаются вручную командами docker network, и на хосте наблюдаются мосты, пары veth и правила netfilter, которые Docker создаёт для каждой сети и каждого опубликованного порта. Затем то же самое описывается в одном файле compose.yaml: трёхзвенное приложение frontend — backend — db в двух сетях, одна из которых внутренняя. В последней базовой части стенд намеренно ломается: неверное имя сервиса, сервис не в той сети, опечатка в имени сети, отсутствующая проверка здоровья. Каждую неисправность нужно найти по симптомам и устранить.

Работа готовит к этапу 2 курсового проекта, где приложение «Заметки» описывается в Docker Compose, и к теме 7: общий сетевой стек контейнеров из продвинутой части — это модель пода Kubernetes.

Работа состоит из базовой части (части 1–4) и продвинутой (часть 5).

Цель работы

Научиться проектировать и проверять сетевую изоляцию многоконтейнерного приложения средствами Docker и Docker Compose, наблюдая механизмы изоляции, разрешения имён и публикации портов на уровне хоста.

После выполнения работы можно будет:

• создать пользовательскую сеть, подключить к ней контейнер и отключить его, объяснить по выводу ip addr, ip route и /etc/resolv.conf разницу между стандартной и пользовательской сетью;
• предсказать, какие контейнеры видят друг друга по имени и по адресу, и проверить предсказание;
• найти в выводе iptables правила DNAT, фильтрации и межсетевой изоляции, созданные Docker, и объяснить, почему опубликованный порт обходит ufw;
• опубликовать порт только на петлевом адресе и показать, что он недоступен по внешнему адресу хоста;
• описать в compose.yaml приложение с двумя сетями, внутренней сетью без выхода наружу, томом и проверками здоровья;
• устранить гонку старта с помощью healthcheck и depends_on с условием service_healthy;
• диагностировать типичные ошибки конфигурации Compose по журналам, docker compose ps и docker compose config.

Теоретический минимум

Теория изложена в теме 6: разделы «Сетевые пространства контейнеров», «Сетевые драйверы и режимы подключения», «Публикация сервисов и межконтейнерное взаимодействие», «Сетевые риски и эксплуатационные ограничения», «Docker Compose». Ниже — сжатая справка.

Учебный стенд частей 3–5 (имя проекта lab06, значения адресов и портов зависят от варианта):

            хост: curl http://127.0.0.1:FRONT_PORT
                          │  (публикация только на 127.0.0.1)
  ┌─────────── сеть lab06_front (обычная, есть выход наружу) ───────────┐
  │   frontend: nginx :80  ──── /api/ → backend:8000 ────►  backend      │
  └─────────────────────────────────────────────────────────  :8000  ───┘
                                                              │ eth1
  ┌─────────── сеть lab06_back (internal: true, BACK_SUBNET) ─┼─────────┐
  │   db: minidb :7000  ◄──────────── db:7000 ────────────────┘          │
  │   том lab06_dbdata → /data                                          │
  └─────────────────────────────────────────────────────────────────────┘

Основные команды:

В образах busybox и *-alpine есть упрощённые утилиты ip, nslookup, wget, ping; curl в них нет. Сообщения этих утилит короче привычных: например, ошибка разрешения имени в wget выглядит как bad address.

Перечень оснащения

• ОС Ubuntu 24.04 (физическая или виртуальная машина либо WSL2) с Docker Engine 27 или новее, установленным по инструкции docs.docker.com, и Docker Compose 2.29 или новее (docker compose version). Команды и ожидаемые результаты составлены по документации Docker Engine 29 и Compose 5; правила netfilter в Engine 27–28 называются иначе (цепочки DOCKER-ISOLATION-STAGE-1/2), это оговорено в заданиях.
• Права sudo для просмотра правил iptables и сокетов ss. Пакеты iproute2 iptables curl unzip (в Ubuntu 24.04 установлены по умолчанию, кроме unzip).
• Образы: busybox:1.37, python:3.12-alpine, nginx:1.28-alpine — около 120 МБ на диске. Нужен доступ к Docker Hub.
• Архив окружения lr-env: compose.yaml, .env, каталоги frontend/, backend/, db/ с кодом сервисов, каталог faults/ с неисправностями части 4, скрипты up.sh, down.sh, README.md.
• Ресурсы: менее 300 МБ оперативной памяти.
• Docker Desktop (macOS, Windows): шаги на стороне контейнеров и Compose выполняются так же, но мосты и правила netfilter находятся внутри служебной виртуальной машины Docker Desktop и с хоста не видны, а IP-адреса контейнеров с хоста недоступны. Шаги, помеченные «(Linux)», на Docker Desktop пропустите и ответьте на их вопросы по теории.

Порядок выполнения работы

Распакуйте архив и задайте переменные своего варианта:

unzip lr-env.zip -d ~/lab06 && cd ~/lab06/lr-env && chmod +x *.sh
N=3                                   # номер варианта
WEB_PORT=$((9000 + N))                # порт части 2
LAB_SUBNET=10.61.$N.0/24              # подсеть части 1

Значения FRONT_PORT, BACK_SUBNET и DB_STARTUP_DELAY для частей 3–5 впишите в файл .env по таблице вариантов.

Если выбранная подсеть уже занята в вашей локальной сети или VPN (проверьте ip route), возьмите соседний вариант. Все контейнеры, созданные вручную, имеют имена с префиксом lab06-, поэтому скрипт down.sh удаляет их вместе с проектом Compose, сетями и томом; его можно запускать в любой момент, чтобы вернуться к чистому состоянию. Перед частью 3 и по окончании работы выполните ./down.sh.

Каждый пункт с пометкой «Предсказание» выполняется в два шага: сначала запишите в журнал ожидаемый результат и его обоснование, затем выполните команду и сравните.

Часть 1. Сети вручную: стандартный мост, пользовательская сеть, изоляция

Задание

1. Посмотрите список сетей и мостов хоста:

   docker network ls
   ip -br link show type bridge          # (Linux)
   

   Какие сети существуют до начала работы и какой мост соответствует сети bridge?

2. Запустите два контейнера в стандартной сети и посмотрите на сеть изнутри одного из них:

   docker run -d --name lab06-a1 busybox:1.37 sleep 3600
   docker run -d --name lab06-a2 busybox:1.37 sleep 3600
   docker exec lab06-a1 sh -c 'ip -4 addr; ip route; cat /etc/resolv.conf'
   A2=$(docker inspect -f '{{.NetworkSettings.Networks.bridge.IPAddress}}' lab06-a2)
   docker exec lab06-a1 ping -c 2 $A2
   docker exec lab06-a1 ping -c 2 lab06-a2
   

   Объясните оба результата ping. Откуда взялось содержимое /etc/resolv.conf в контейнере? Сравните его с файлом хоста.

3. Найдите на хосте концы пар veth и проверьте, к какому мосту они подключены (Linux): ip -br link show type veth, ip -br link show master docker0. Сопоставьте индекс в имени eth0@ifN внутри контейнера с индексами интерфейсов хоста (ip -o link | grep "^N:").

4. Создайте пользовательскую сеть с подсетью своего варианта и два контейнера в ней:

   docker network create --subnet $LAB_SUBNET lab06-net
   docker run -d --name lab06-b1 --network lab06-net busybox:1.37 sleep 3600
   docker run -d --name lab06-b2 --network lab06-net busybox:1.37 sleep 3600
   docker network inspect lab06-net
   

   Найдите в выводе inspect подсеть, шлюз и адреса контейнеров. Найдите на хосте мост этой сети: его имя — br- и первые 12 символов идентификатора сети (Linux).

5. Предсказание. Сработает ли docker exec lab06-b1 ping -c 2 lab06-b2? Что будет записано в /etc/resolv.conf контейнера lab06-b1? Проверьте, а также выполните docker exec lab06-b1 nslookup lab06-b2. Какой сервер ответил на запрос?

6. Предсказание. Пройдёт ли ping из lab06-b1 по IP-адресу контейнера lab06-a1, находящегося в другой сети? Хост пересылает пакеты между своими интерфейсами (sysctl net.ipv4.ip_forward), маршрут к обеим подсетям у него есть — почему результат может отличаться от ожидаемого «как у маршрутизатора»? Проверьте, затем найдите правило, отбросившее пакеты (Linux):

   sudo iptables -S DOCKER
   sudo iptables -S DOCKER-FORWARD
   

   В Docker Engine 27–28 межсетевую изоляцию выполняют цепочки DOCKER-ISOLATION-STAGE-1 и DOCKER-ISOLATION-STAGE-2; посмотрите их, если DOCKER-FORWARD не существует.

7. Предсказание. Проверьте, доступен ли адрес контейнера lab06-b1 с самого хоста: ping -c 2 АДРЕС_B1 (Linux). Объясните, чем этот случай отличается от пункта 6.

8. Подключите lab06-b1 ко второй сети без перезапуска и повторите опыты:

   docker network connect bridge lab06-b1
   docker exec lab06-b1 ip -4 addr
   docker exec lab06-b1 ping -c 2 $A2
   docker exec lab06-b1 ping -c 2 lab06-a2
   docker exec lab06-b1 ping -c 2 lab06-b2
   docker network disconnect bridge lab06-b1
   

   Сколько интерфейсов стало у контейнера? Какие обращения стали возможны, а какие по-прежнему нет, и почему?

Что должно получиться

В списке сетей до начала работы — bridge, host, none (и, возможно, сети других проектов). В контейнере стандартной сети — интерфейс eth0@ifN с адресом из 172.17.0.0/16, маршрут по умолчанию через 172.17.0.1, а /etc/resolv.conf повторяет серверы DNS хоста (на хосте с systemd-resolved — серверы из /run/systemd/resolve/resolv.conf, а не 127.0.0.53). ping по адресу работает, по имени — нет:

ping: bad address 'lab06-a2'

В пользовательской сети lab06-net адреса выдаются из подсети варианта, шлюз — первый адрес подсети, в /etc/resolv.conf записан nameserver 127.0.0.11, ping lab06-b2 работает, nslookup показывает сервер 127.0.0.11. Пакеты из lab06-b1 к lab06-a1 теряются полностью (100% packet loss), хотя пересылка на хосте включена. Отбрасывает их правило -A DOCKER ! -i docker0 -o docker0 -j DROP цепочки DOCKER (в Engine 27–28 — правило DROP в DOCKER-ISOLATION-STAGE-2); в выводе iptables -S видны правила для обоих мостов. С хоста адрес lab06-b1 пингуется: хост имеет адрес на мосту br-… и обращается к контейнеру напрямую, без пересылки через FORWARD.

После docker network connect у lab06-b1 два интерфейса, eth0 в lab06-net и eth1 в bridge. ping по адресу lab06-a2 проходит, по имени — нет: в стандартной сети встроенный DNS имён не регистрирует. Имя lab06-b2 по-прежнему разрешается. Типичное отклонение: подсеть варианта пересекается с локальной сетью или VPN, и docker network create завершается ошибкой о перекрытии адресов, — выберите другой вариант.

Часть 2. Публикация портов и правила NAT

Задание

1. Запустите веб-сервер с опубликованным портом. Встроенный в Python сервер записывает в журнал адрес каждого клиента, что пригодится для наблюдения за NAT:

   docker run -d --name lab06-web1 -p $WEB_PORT:8000 python:3.12-alpine python -m http.server 8000
   docker port lab06-web1
   HOST_IP=$(hostname -I | awk '{print $1}')       # внешний адрес хоста
   curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:$WEB_PORT/
   curl -s -o /dev/null -w '%{http_code}\n' http://$HOST_IP:$WEB_PORT/
   docker logs lab06-web1
   

   Почему docker port выводит две строки? Предсказание: с какого адреса придут в контейнер два этих запроса? Сравните с журналом и объясните разницу.

2. Посмотрите, кто слушает опубликованный порт на хосте и какие правила создал Docker (Linux):

   sudo ss -ltnp "sport = :$WEB_PORT"
   sudo iptables -t nat -S DOCKER
   sudo iptables -S DOCKER
   sudo iptables -t raw -S PREROUTING
   

   Для каждого правила, относящегося к lab06-web1, запишите, в какой таблице и цепочке оно находится и что делает. Сопоставьте с рисунком пути пакета в теории.

3. Предсказание. Счётчики правила DNAT в цепочке DOCKER таблицы nat растут при каждом соединении через него. Какой из двух запросов пункта 1 увеличит счётчик, а какой нет? Обнулите счётчики (sudo iptables -t nat -Z DOCKER), повторите каждый запрос по одному разу и проверьте командой sudo iptables -t nat -L DOCKER -n -v (Linux).

4. Запустите второй сервер с публикацией только на петлевом адресе и сравните:

   docker run -d --name lab06-web2 -p 127.0.0.1:$((WEB_PORT + 100)):8000 python:3.12-alpine python -m http.server 8000
   curl -s -m 3 -o /dev/null -w '%{http_code}\n' http://127.0.0.1:$((WEB_PORT + 100))/
   curl -s -m 3 -o /dev/null -w '%{http_code}\n' http://$HOST_IP:$((WEB_PORT + 100))/; echo "код выхода curl: $?"
   sudo iptables -t nat -S DOCKER | grep $((WEB_PORT + 100))
   sudo iptables -t raw -S PREROUTING
   

   Чем правило DNAT для lab06-web2 отличается от правила для lab06-web1? Что добавилось в таблицу raw и от какой угрозы это правило защищает?

5. Публикация без указания порта хоста:

   docker run -d --name lab06-web3 -p 8000 python:3.12-alpine python -m http.server 8000
   docker run -d --name lab06-web4 -P python:3.12-alpine python -m http.server 8000
   docker run -d --name lab06-web5 -P nginx:1.28-alpine
   docker port lab06-web3; docker port lab06-web4; docker port lab06-web5
   cat /proc/sys/net/ipv4/ip_local_port_range
   

   Почему у lab06-web4 нет ни одного опубликованного порта, а у lab06-web5 есть? Подсказка: docker image inspect -f '{{.Config.ExposedPorts}}' nginx:1.28-alpine и то же для python:3.12-alpine.

6. Только если на хосте включён ufw с запретом входящих (sudo ufw status verbose) и в локальной сети есть второе устройство (ноутбук, телефон): откройте с него http://HOST_IP:WEB_PORT/. Объясните результат по рисунку пути пакета. Затем ограничьте доступ к опубликованным портам одним адресом этого устройства и проверьте снова (замените eth0 и адрес на свои):

   sudo iptables -I DOCKER-USER -i eth0 ! -s 192.168.1.50 -j DROP
   sudo iptables -I DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
   # проверка с разных устройств, затем удаление правил:
   sudo iptables -D DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
   sudo iptables -D DOCKER-USER -i eth0 ! -s 192.168.1.50 -j DROP
   

7. Удалите контейнеры части: docker rm -f lab06-web1 lab06-web2 lab06-web3 lab06-web4 lab06-web5. Проверьте, что правила DNAT для них исчезли.

Что должно получиться

docker port lab06-web1 выводит две строки, 0.0.0.0:WEB_PORT и [::]:WEB_PORT: без явного адреса порт публикуется для IPv4 и IPv6. Оба запроса пункта 1 возвращают код 200. В журнале контейнера запрос через 127.0.0.1 пришёл с адреса шлюза моста (172.17.0.1): его принял процесс docker-proxy на хосте и открыл новое соединение к контейнеру. Запрос на внешний адрес хоста прошёл через DNAT, и в журнале виден сам внешний адрес хоста — источник не подменялся. Примерный вид журнала:

172.17.0.1 - - [22/Oct/2026 10:15:02] "GET / HTTP/1.1" 200 -
192.168.1.10 - - [22/Oct/2026 10:15:03] "GET / HTTP/1.1" 200 -

ss показывает процессы docker-proxy на опубликованном порту. В таблице nat есть правило -A DOCKER ! -i docker0 -p tcp -m tcp --dport WEB_PORT -j DNAT --to-destination 172.17.0.X:8000, в таблице filter — ACCEPT к 172.17.0.X на порт 8000, в таблице raw — DROP для пакетов к адресу контейнера, пришедших не с моста. Счётчик DNAT растёт только от запроса на внешний адрес: локальные соединения на 127.0.0.0/8 Docker не транслирует, их обслуживает docker-proxy.

Для lab06-web2 запрос на 127.0.0.1 возвращает 200, а на внешний адрес — ошибку соединения (код 000, у curl код выхода 7): на внешнем адресе никто не слушает и DNAT не срабатывает, потому что правило содержит -d 127.0.0.1/32. В таблице raw добавилось правило -A PREROUTING -d 127.0.0.1/32 ! -i lo -p tcp -m tcp --dport ПОРТ -j DROP: оно не даёт соседям по сегменту L2 обратиться к петлевому порту, отправив пакет с адресом назначения 127.0.0.1 на MAC-адрес хоста (до Engine 28 такая атака была возможна).

lab06-web3 получает порт из эфемерного диапазона (по умолчанию 32768–60999). У образа python:3.12-alpine нет объявленных портов (map[]), поэтому -P ничего не публикует; у nginx:1.28-alpine объявлен 80/tcp, и он публикуется на случайном порту. Если выполнялся пункт 6: при включённом ufw страница с другого устройства открывается, после правил в DOCKER-USER — только с разрешённого адреса.

Часть 3. Трёхзвенное приложение в Compose

Задание

1. Выполните ./down.sh. Впишите значения варианта в .env. Прочитайте compose.yaml и для каждого сервиса запишите, в каких сетях он будет и какие имена сможет разрешать. Предсказание: какие из шести направлений «сервис → сервис» будут работать?

2. Проверьте итоговую модель без запуска:

   docker compose config --services
   docker compose config | sed -n '/^networks:/,$p'
   docker compose config frontend | grep -A5 ports
   

   Какие имена получат сети и том? Куда подставились значения из .env?

3. Поднимите проект и проверьте работу приложения:

   ./up.sh
   curl -s http://127.0.0.1:$FRONT_PORT/api/notes; echo
   curl -s -X POST -d '{"text": "первая заметка"}' http://127.0.0.1:$FRONT_PORT/api/notes; echo
   curl -s http://127.0.0.1:$FRONT_PORT/api/notes; echo
   curl -s http://127.0.0.1:$FRONT_PORT/api/info; echo
   

   Подставьте свой порт вместо $FRONT_PORT или задайте переменную в оболочке. Сколько адресов у backend по данным /api/info и в каких они подсетях?

4. Проверьте разрешение имён и связность из каждого сервиса:

   docker compose exec backend nslookup db
   docker compose exec frontend nslookup backend
   docker compose exec frontend nslookup db
   docker compose exec frontend wget -qO- -T 3 http://db:7000/health
   DB_IP=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' lab06-db-1)
   docker compose exec frontend wget -qO- -T 3 http://$DB_IP:7000/health
   

   Чем отличаются ошибки последних двух команд и о каких механизмах изоляции они говорят?

5. Проверьте выход наружу. Команда пытается открыть TCP-соединение с внешним адресом:

   docker compose exec backend python -c "import socket; socket.create_connection(('1.1.1.1', 80), timeout=3); print('есть выход наружу')"
   docker compose exec db python -c "import socket; socket.create_connection(('1.1.1.1', 80), timeout=3); print('есть выход наружу')"
   docker compose exec db ip route
   docker compose exec backend ip route
   

   Объясните результат по таблицам маршрутизации.

6. Посмотрите на внутреннюю сеть со стороны хоста:

   docker network inspect -f '{{.Internal}} {{range .IPAM.Config}}{{.Subnet}} {{.Gateway}}{{end}}' lab06_back
   sudo iptables -S DOCKER-INTERNAL          # (Linux); в Engine 27–28 — DOCKER-ISOLATION-STAGE-1
   curl -s -m 3 http://$DB_IP:7000/health; echo   # (Linux)
   

   Предсказание: ответит ли db на запрос с самого хоста? Проверьте и объясните, от чего защищает internal: true, а от чего нет.

7. Проверьте сохранность данных: docker compose down, затем ./up.sh и GET /api/notes; затем docker compose down -v, ./up.sh и снова GET /api/notes.

Что должно получиться

docker compose config печатает сети lab06_front и lab06_back (у второй internal: true и подсеть варианта), том lab06_dbdata, порт frontend 127.0.0.1:FRONT_PORT. up.sh завершается, когда все сервисы готовы; примерный вид docker compose ps:

NAME               IMAGE                SERVICE    STATUS                    PORTS
lab06-backend-1    python:3.12-alpine   backend    Up 15 seconds (healthy)   
lab06-db-1         python:3.12-alpine   db         Up 21 seconds (healthy)   
lab06-frontend-1   nginx:1.28-alpine    frontend   Up 4 seconds              127.0.0.1:8083->80/tcp

Первый GET /api/notes возвращает [], POST — {"id": 1, "text": "первая заметка"}. /api/info показывает два адреса backend: один из подсети lab06_front, другой из BACK_SUBNET, и адрес db из BACK_SUBNET.

Из backend имя db разрешается сервером 127.0.0.11 в адрес из BACK_SUBNET; из frontend имя backend разрешается, а db — нет (nslookup сообщает, что имя не найдено). wget по имени db из frontend завершается ошибкой bad address 'db:7000' — сбой на этапе DNS. wget по IP-адресу db завершается по таймауту (download timed out): пакет ушёл, но был отброшен правилами межсетевой изоляции и DOCKER-INTERNAL. Работают четыре направления: frontend → backend, backend → frontend, backend → db, db → backend.

Из backend соединение с 1.1.1.1:80 устанавливается (при наличии Интернета у хоста), из db — ошибка:

OSError: [Errno 101] Network is unreachable

У db в таблице маршрутизации только маршрут к своей подсети, маршрута по умолчанию нет; у backend маршрут по умолчанию ведёт через шлюз сети lab06_front. В DOCKER-INTERNAL видны два правила DROP для моста lab06_back: всё, что входит в мост не из его подсети, и всё, что выходит из него не в его подсеть. С хоста (Linux) db отвечает {"status": "ok"}: мост внутренней сети имеет адрес в её подсети, и хост обращается к контейнеру напрямую. internal: true защищает от выхода контейнеров наружу и от обращений из других сетей, но не от процессов самого хоста.

После down и up заметка сохраняется (том не удалялся), после down -v список снова пуст. Типичные отклонения: up.sh долго ждёт и падает — посмотрите docker compose logs; порт FRONT_PORT занят другим процессом — docker compose up сообщит, что адрес уже используется. В журнале frontend могут быть строки о том, что сценарий образа не смог изменить default.conf (файл смонтирован только для чтения), — это не ошибка.

Часть 4. Порядок запуска и неисправности: сломать и починить

Задание

1. Пронаблюдайте порядок запуска. Выполните docker compose down и затем docker compose up -d, внимательно читая строки прогресса: в какой момент появляется Waiting, когда Healthy, когда стартует каждый следующий сервис? Затем:

   docker compose logs -t --no-log-prefix db backend | sort | head -20
   docker inspect -f '{{json .State.Health}}' lab06-db-1 | python3 -m json.tool | head -20
   

   По отметкам времени определите, сколько прошло от запуска db до запуска backend. Как это время связано с DB_STARTUP_DELAY, start_period и start_interval проверки здоровья db?

2. Выполните docker compose down. Файлы в каталоге faults/ накладываются на compose.yaml и вносят по одной неисправности. Не открывайте их до окончания диагностики. Для каждой неисправности A, B, C, D:

   F=faults/fault-a.yaml                         # затем fault-b, fault-c, fault-d
   docker compose -f compose.yaml -f $F up -d
   docker compose -f compose.yaml -f $F ps -a
   docker compose -f compose.yaml -f $F logs backend
   

   Определите по симптомам, что сломано, и подтвердите гипотезу командами, не открывая файл: docker compose -f compose.yaml -f $F config backend, docker inspect, docker network inspect. Предложите исправление и проверьте его. После каждой неисправности выполните docker compose -f compose.yaml -f $F down.

3. Неисправности A и B дают в журнале backend одинаковое сообщение. Объясните, почему разные причины приводят к одному симптому и какая команда их различает.

4. Неисправность D воспроизводит гонку старта. Измените параметр DB_STARTUP_DELAY в .env на 0 и повторите опыт с файлом fault-d.yaml несколько раз. Объясните результат. Почему отсутствие ошибки в этом опыте не доказывает корректность конфигурации?

5. Скопируйте faults/fault-d.yaml в faults/fault-d2.yaml, замените в копии restart: "no" на restart: unless-stopped, верните DB_STARTUP_DELAY своего варианта и поднимите только два сервиса: docker compose -f compose.yaml -f faults/fault-d2.yaml up -d db backend. Наблюдайте docker inspect -f '{{.RestartCount}} {{.State.Status}}' lab06-backend-1 раз в несколько секунд. Затем повторите с restart: on-failure:3. Чем закончился каждый из опытов и почему политика перезапуска — не замена проверке здоровья?

Что должно получиться

При обычном запуске Compose выводит для db строки Waiting и затем Healthy, и только после этого создаёт и запускает backend; frontend ждёт Healthy у backend. Разница между запуском db и backend примерно равна DB_STARTUP_DELAY плюс до одной секунды: в период start_period проверка выполняется каждые start_interval (1 с), и первая успешная проверка сразу переводит контейнер в healthy. В .State.Health.Log видны неудачные проверки с ошибкой соединения и затем успешная с кодом 0.

Диагнозы неисправностей:

Неисправности A и B различаются не журналом, а моделью: в A ошибочно имя, в B — набор сетей, и встроенный DNS одинаково не находит имя, которого нет в сетях контейнера. Различает их docker compose config или docker inspect контейнера backend. С DB_STARTUP_DELAY=0 гонка в опыте D обычно не проявляется: база успевает открыть порт раньше, чем backend к ней обратится. Конфигурация от этого не становится верной — она работает по случайному совпадению времени, и на медленном диске или при первом запуске настоящей СУБД упадёт.

В опыте с unless-stopped backend несколько раз падает и перезапускается с растущей паузой, пока база не откроет порт, после чего работает; RestartCount больше нуля, а в журнале — серия ошибок. С on-failure:3 исход зависит от того, успеет ли база подняться до исчерпания трёх перезапусков, и при задержке в несколько секунд backend обычно остаётся в состоянии exited. Политика перезапуска лишь повторяет попытки вслепую, не зная о готовности зависимости, и маскирует гонку вместо её устранения.

Часть 5. Общий сетевой стек как в поде (продвинутая)

Задание

1. Запустите «основной» контейнер с веб-сервером и второй контейнер в его сетевом пространстве имён:

   docker run -d --name lab06-pod busybox:1.37 httpd -f -p 8080 -h /etc
   docker run --rm --network container:lab06-pod busybox:1.37 wget -qO- http://127.0.0.1:8080/hostname
   docker exec lab06-pod hostname
   

   Почему второй контейнер получил ответ по адресу 127.0.0.1?

2. Предсказание. Совпадут ли адреса и MAC-адреса интерфейсов? Увидит ли второй контейнер процессы первого? Проверьте:

   docker exec lab06-pod ip -4 addr
   docker run --rm --network container:lab06-pod busybox:1.37 ip -4 addr
   docker run --rm --network container:lab06-pod busybox:1.37 ps
   docker inspect -f '{{.HostConfig.NetworkMode}}' lab06-pod
   

3. Попробуйте запустить во втором контейнере ещё один сервер на том же порту и опубликовать порт у второго контейнера:

   docker run --rm --network container:lab06-pod busybox:1.37 httpd -f -p 8080
   docker run --rm --network container:lab06-pod -p 9999:80 busybox:1.37 true
   

   Объясните обе ошибки.

4. То же в Compose. Поднимите проект части 3 (./up.sh) и выполните отладочный сервис из профиля debug, разделяющий сетевой стек backend:

   docker compose config --services
   docker compose --profile debug config --services
   docker compose run --rm debug ip -4 addr
   docker compose run --rm debug wget -qO- http://127.0.0.1:8000/api/health
   docker compose run --rm debug nslookup db
   

   Почему debug не появился в обычном up, но запустился командой run без ключа --profile?

5. Сопоставьте увиденное с моделью пода Kubernetes (тема 7): что в поде играет роль lab06-pod, что — второго контейнера, и какое ограничение пункта 3 будет действовать и в поде.

6. Уберите стенд: ./down.sh.

Что должно получиться

Второй контейнер получает содержимое /etc/hostname первого — тот же идентификатор, что выводит docker exec lab06-pod hostname: петлевой интерфейс у контейнеров общий. Вывод ip -4 addr в обоих контейнерах одинаков — тот же eth0@ifN, тот же адрес; ps во втором контейнере показывает только его собственный процесс: общим стал лишь сетевой стек, пространство имён PID отдельное. HostConfig.NetworkMode у lab06-pod — bridge, а у второго контейнера был бы container:<идентификатор>.

Второй httpd на порту 8080 завершается ошибкой вида bind: Address in use — пространство портов общее. Публикация порта у второго контейнера отклоняется ещё до запуска: Docker сообщает о конфликте параметров, потому что порты публикуются для сетевого стека, а им владеет первый контейнер.

debug отсутствует в config --services без профиля и появляется с --profile debug. Команда docker compose run debug называет сервис явно, и Compose включает его профиль автоматически. Внутри debug видны оба интерфейса backend (из lab06_front и BACK_SUBNET), 127.0.0.1:8000 отвечает {"status": "ok"}, имя db разрешается — у отладочного контейнера та же сетевая видимость, что у backend. В Kubernetes роль lab06-pod играет служебный контейнер pause, удерживающий сетевое пространство имён пода, роль второго контейнера — любой прикладной или вспомогательный контейнер пода. Два контейнера одного пода так же не могут слушать один порт.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод и объяснение расхождений. Особенно полезны в журнале таблица «направление — по имени — по адресу — что помешало» для частей 1 и 3 и таблица диагнозов части 4 с указанием, какая команда подтвердила каждую гипотезу. В конце сформулируйте несколько предложений собственных выводов: какие механизмы изоляции вы наблюдали и на каком уровне (DNS, маршрутизация, netfilter) действует каждый.

Контрольные вопросы

1. Почему контейнеры в стандартной сети bridge не находят друг друга по имени, а в пользовательской сети находят? Где физически работает сервер 127.0.0.11 и как до него доходит запрос?
2. Каждая сеть Docker — отдельный мост, а хост пересылает пакеты между интерфейсами. Что именно не даёт контейнеру одной сети обратиться к контейнеру другой сети по IP-адресу? Как это выглядит в Docker Engine 29 и в более ранних версиях?
3. Почему адрес контейнера доступен с самого хоста без публикации порта, но недоступен с другой машины, даже если на ней прописать маршрут к подсети контейнеров?
4. Проследите путь пакета от внешнего клиента до контейнера с портом, опубликованным как -p 8080:80: какие таблицы и цепочки netfilter он проходит и что меняется в его заголовке? Почему правила ufw к нему не применяются?
5. Зачем Docker запускает docker-proxy, если публикацию выполняет DNAT? С какого адреса видит клиента приложение в контейнере в каждом из двух случаев?
6. Чем -p 127.0.0.1:8080:80 отличается от -p 8080:80 на уровне правил netfilter? От какой атаки защищает правило в таблице raw?
7. Что делает internal: true с сетью Compose? Почему контейнер во внутренней сети не может выйти наружу, а процесс хоста может обратиться к нему?
8. Чем ошибка bad address отличается от ошибки по таймауту при обращении frontend к db? О каких механизмах изоляции говорит каждая из них?
9. Почему depends_on без условия не устраняет гонку старта, а condition: service_healthy устраняет? Почему проверка здоровья backend не должна обращаться к базе данных?
10. Почему политика перезапуска маскирует гонку старта, а не устраняет её? В каком случае приложение с restart: unless-stopped и без проверки здоровья всё-таки поднимется и чем это плохо?
11. Что общего у --network container:, network_mode: "service:…" в Compose и пода Kubernetes? Какие пространства имён при этом общие, а какие нет?
12. Какие задачи, решённые в этой работе вручную или в Compose, Compose не решает при отказе хоста или контейнера после запуска, и какой механизм оркестратора закрывает этот пробел?