Контейнеризация и архитектура Docker

В теме 2 были рассмотрены два способа разделить один сервер между нагрузками: виртуальная машина с собственным ядром под управлением гипервизора и механизмы ядра Linux — пространства имён и группы управления ресурсами, — которые изолируют процессы без второго ядра. Механизмы ядра оказались лёгкими, но сами по себе неудобными: чтобы вручную собрать из unshare, mount и записей в /sys/fs/cgroup изолированную среду для веб-сервера, нужно знать десятки деталей, а получившуюся среду нельзя передать коллеге или перенести на другой сервер.

Контейнеризация решает именно эту задачу. Она добавляет к механизмам изоляции формат упаковки — образ, содержащий файловую систему приложения со всеми зависимостями, — и программу, которая по одной команде создаёт из образа изолированный процесс с заданными ограничениями. Docker сделал эту модель массовой, а стандарты Open Container Initiative (OCI) отделили её от конкретного продукта.

Изложение построено так. Сначала контейнер сопоставляется с виртуальной машиной, затем вводятся понятия образа и контейнера. После этого рассматривается, какими пространствами имён и cgroups Docker изолирует контейнер и как это наблюдать с хоста, как устроена слоистая файловая система, из каких компонентов состоит Docker Engine (от клиента до runc) и почему на macOS и Windows контейнеры работают внутри Linux-ВМ. Завершает тему жизненный цикл контейнера. Сборка образов из Dockerfile рассматривается в теме 4, параметры запуска и обработка сигналов — в теме 5, сеть контейнеров — в теме 6.

Контейнер как модель изоляции процессов

Контейнеризация решает практическую задачу: запускать приложения изолированно и воспроизводимо, не создавая для каждого приложения отдельную виртуальную машину. В отличие от VM, контейнер не содержит собственного ядра операционной системы. Контейнер — это набор процессов, которые выполняются на ядре хоста, но «видят» ограниченную картину системы: свои процессы, свою файловую систему, свои сетевые интерфейсы и свои квоты ресурсов. Эта изоляция достигается механизмами ядра Linux, а Docker предоставляет удобную модель упаковки и запуска.

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

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

Сопоставление с виртуализацией

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

Виртуальная машина представляет собой полноценную вычислительную среду с собственной операционной системой. Гипервизор обеспечивает аппаратную изоляцию: гостевая система не имеет прямого доступа к ресурсам хоста или других виртуальных машин. Границы изоляции проходят на уровне виртуального оборудования, что обеспечивает высокую степень безопасности. Даже если гостевая операционная система подвергнется компрометации, злоумышленнику потребуется преодолеть дополнительный барьер в виде гипервизора, чтобы получить доступ к хостовой системе.

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

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

Сценарии предпочтительного использования

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

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

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

Сравнительная характеристика

Различия двух подходов по основным характеристикам сведены в таблицу; рисунок ниже показывает их программные стеки.

Контейнер и образ: назначение и взаимосвязь

В Docker используются две взаимосвязанные сущности: образ и контейнер. Образ — это подготовленный артефакт, который описывает, что именно будет запущено. Контейнер — это экземпляр выполнения, который определяет, как именно это будет запущено в конкретный момент времени.

Образ (image) представляет собой файловую систему приложения и набор метаданных запуска. В образ не входит ядро операционной системы и драйверы устройств: контейнеры используют ядро системы-хоста. Назначение образа — обеспечить переносимость и воспроизводимость: если используется один и тот же образ, приложение стартует в одинаковом наборе файлов и зависимостей (при условии совместимости архитектуры и платформы). Образ хранится локально или в реестре и может быть версионирован.

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

Из этой модели следует ключевая практика эксплуатации. Изменения, выполненные внутри работающего контейнера, относятся к его слою записи и не являются надёжным способом сопровождения: при пересоздании контейнера они исчезают. Поэтому корректный процесс обновления приложения заключается в создании новой версии образа и запуске нового контейнера, а не во внесении изменений в уже запущенный экземпляр.

Изоляция контейнеров: пространства имён и группы управления ресурсами

Контейнеры в Linux не являются отдельными операционными системами. Это процессы, которым ядро предоставляет изолированные представления части ресурсов и одновременно применяет количественные ограничения на потребление этих ресурсов. В Docker данная модель скрыта за простым интерфейсом запуска, однако для понимания поведения контейнеров в эксплуатации важно знать, какими механизмами изоляция и ограничения реализуются.

Изоляция обеспечивается пространствами имён (namespaces). Пространство имён можно понимать как механизм, который заставляет процесс «видеть» только выделенный ему набор системных объектов. Например, в контейнере может быть собственная нумерация процессов, собственная конфигурация сети и отдельное дерево монтирования файловых систем. Для контейнеризации чаще всего используются несколько типов пространств имён.

PID namespace определяет, какие процессы видимы и как они нумеруются внутри контейнера. Благодаря этому процессы контейнера не видят процессы хоста и других контейнеров, а внутри контейнера основной процесс получает идентификатор PID 1. Этот факт имеет практические последствия: PID 1 в Linux обладает особыми обязанностями по обработке сигналов и «сборке» завершившихся дочерних процессов; поэтому некоторые приложения в роли PID 1 требуют корректной настройки, а в реальных системах нередко используют специализированные минимальные процессы-инициализаторы.

Network namespace предоставляет контейнеру отдельный сетевой стек: сетевые интерфейсы, таблицы маршрутизации, правила фильтрации. С точки зрения процессов внутри контейнера сеть выглядит «своей», хотя физически пакеты всё равно проходят через подсистему хоста. Именно на базе network namespaces Docker строит модели виртуальных сетей и изоляции взаимодействия между контейнерами.

Mount namespace формирует отдельное дерево монтирования. Это позволяет контейнеру иметь свою корневую файловую систему, собранную из слоёв образа, а также подключать дополнительные хранилища (например, тома) в заданные точки. Mount namespace тесно связан с механизмом слоистой файловой системы контейнера: процессы контейнера видят единое дерево каталогов, хотя на уровне реализации оно составлено из нескольких слоёв.

UTS namespace изолирует такие атрибуты, как имя хоста и доменное имя узла, что полезно для корректного поведения приложений, которые используют эти значения. IPC namespace изолирует механизмы межпроцессного взаимодействия (объекты System V IPC и очереди сообщений POSIX), снижая риск нежелательных пересечений между контейнерами.

User namespace позволяет отображать идентификаторы пользователей и групп контейнера на другие идентификаторы на хосте ⁶. Это важно для безопасности: процесс может иметь высокие привилегии внутри контейнера, но соответствовать непривилегированному пользователю на хосте. На этой возможности основаны режимы запуска без прав суперпользователя (rootless), которые уменьшают последствия возможной компрометации приложения. Важно, однако, что по умолчанию Docker пространство имён пользователей не создаёт: процесс, работающий в контейнере от root, на хосте тоже имеет UID 0. Его возможности урезаны другими средствами — сокращённым набором привилегий (capabilities), фильтром системных вызовов seccomp и профилем AppArmor или SELinux, — но это всё ещё root ядра хоста. Отображение идентификаторов включается явно: режимом userns-remap демона, при котором UID 0 контейнера соответствует непривилегированному диапазону идентификаторов хоста ⁸, или запуском всего Docker без прав root (rootless mode). Эти вопросы подробно рассматриваются в теме 11.

Одной из целей контейнеризации является также управляемое распределение ресурсов. Для этого ядро предоставляет механизм групп управления ресурсами (cgroups). Через cgroups можно ограничивать и учитывать потребление процессорного времени, оперативной памяти, дискового ввода-вывода и числа процессов, а также собирать статистику использования ресурсов. Современные дистрибутивы используют cgroups v2 с единой иерархией (тема 2): для каждого контейнера Docker создаёт отдельную группу, на хосте с systemd — с именем вида docker-<идентификатор>.scope внутри system.slice, и записывает в её файлы memory.max, cpu.max и pids.max значения ключей --memory, --cpus и --pids-limit. Практическая ценность cgroups проявляется в мультисервисных системах: без ограничений один контейнер способен занять всю память или создать избыточную нагрузку на CPU и тем самым нарушить работу других сервисов. В эксплуатационной практике задавать лимиты — это способ сделать поведение системы предсказуемым и снизить влияние ошибок и пиков нагрузки.

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

Наблюдение изоляции с хоста

Утверждение «контейнер — это процесс хоста» проверяется несколькими командами. Запустим веб-сервер и узнаем глобальный PID его основного процесса (здесь и далее в теме выводы Docker приведены по документации и сокращены; идентификаторы и номера на конкретной машине будут другими):

docker run -d --name web -p 8080:80 nginx:1.28
docker inspect --format '{{.State.Status}} pid={{.State.Pid}} cmd={{.Config.Cmd}}' web

3f1c9a2b7d4e8c0f5a6b1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a
running pid=24817 cmd=[nginx -g daemon off;]

Первая строка — полный идентификатор созданного контейнера, вторая — его состояние и PID основного процесса в пространстве имён хоста. Этот процесс виден обычной командой ps на хосте, а файлы /proc/<pid>/cgroup и /proc/<pid>/ns показывают, в какой группе cgroups и в каких пространствах имён он находится:

ps -o pid,ppid,user,cmd -p 24817
cat /proc/24817/cgroup
sudo readlink /proc/24817/ns/pid /proc/self/ns/pid
cat /proc/24817/uid_map

    PID    PPID USER     CMD
  24817   24795 root     nginx: master process nginx -g daemon off;
0::/system.slice/docker-3f1c9a2b7d4e8c0f5a6b1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a.scope
pid:[4026532671]
pid:[4026531836]
         0          0 4294967295

Из этого вывода следуют четыре наблюдения. Процесс nginx на хосте — обычный процесс с PID 24817, принадлежащий пользователю root. Он находится в отдельной группе cgroups v2, имя которой содержит идентификатор контейнера. Его пространство имён PID отличается от пространства оболочки хоста (номера в ссылках разные), поэтому внутри контейнера этот же процесс имеет PID 1 — это видно и по журналу nginx, где мастер-процесс подписывается как 1#1. Наконец, отображение UID 0 0 4294967295 — тождественное: весь диапазон идентификаторов внутри совпадает с диапазоном снаружи, то есть отдельного пространства имён пользователей у контейнера нет. Родительский процесс с PID 24795 — это containerd-shim-runc-v2, роль которого разобрана ниже, в разделе об архитектуре Docker.

Файловая система контейнера: слои образа, слой записи и внешнее хранение данных

Когда контейнер создаётся из образа, Docker должен предоставить процессам контейнера корневую файловую систему, которая выглядит как обычное дерево каталогов. При этом образ состоит из слоёв «только чтение», а контейнер должен иметь возможность изменять файлы в ходе работы. Эта задача решается при помощи объединённой (слоистой) файловой системы, где к слоям образа добавляется верхний слой с возможностью записи.

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

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

Слоистая файловая система влияет и на производительность. Для большинства приложений накладные расходы невелики, однако при интенсивной записи слой записи и механизмы copy-on-write могут создавать дополнительные издержки. Это обстоятельство учитывается при проектировании политики хранения данных контейнерных приложений.

Слои образа и overlay2 в выводе инспекции

В Linux слоистая файловая система Docker реализуется драйвером overlay2 поверх файловой системы ядра OverlayFS ²¹⁰. OverlayFS объединяет несколько каталогов: нижние (lowerdir) доступны только для чтения и соответствуют слоям образа, верхний (upperdir) принимает все записи, а объединённый (merged) — то, что процесс контейнера видит как /. При первой записи в файл из нижнего слоя файл целиком копируется в верхний (copy-on-write); удаление файла нижнего слоя записывается в верхний как специальный файл-«затирание» (whiteout). Именно поэтому изменение большого файла в контейнере стоит копирования всего файла, а удаление файла из базового образа не уменьшает размер образа.

Список слоёв образа хранится в его метаданных. Каждый слой идентифицируется хешем SHA-256 своего несжатого содержимого (diff ID):

docker image inspect nginx:1.28 --format '{{range .RootFS.Layers}}{{println .}}{{end}}'
docker history nginx:1.28 --format '{{.Size}}\t{{.CreatedBy}}' | head -4

sha256:7914c8f600f5...
sha256:0a3f4c8e9b51...
sha256:5e2d7b1a6c84...
sha256:9c1f8a3d2e07...
sha256:4b6e0d9f3a12...
sha256:e8a2c5f7b931...
sha256:2d9b4e6a8c05...
0B      CMD ["nginx" "-g" "daemon off;"]
0B      STOPSIGNAL SIGQUIT
0B      EXPOSE map[80/tcp:{}]
0B      ENTRYPOINT ["/docker-entrypoint.sh"]

Первый слой — базовая файловая система Debian, следующие — установка nginx и стартовых скриптов (хеши здесь сокращены). Строки docker history нулевого размера соответствуют инструкциям, которые меняют только метаданные образа, а не файлы, — подробно это разбирается в теме 4. Два образа с одинаковым базовым слоем хранят его на диске один раз, а контейнер добавляет к слоям образа только свой верхний слой.

Следует оговорить, что начиная с Docker Engine 29 новые установки по умолчанию используют хранилище образов containerd (containerd image store): в выводе docker info драйвер хранилища тогда отображается как overlayfs с пометкой io.containerd.snapshotter.v1, а файлы слоёв лежат в каталоге containerd, а не в /var/lib/docker/overlay2. Механизм объединения каталогов от этого не меняется — это та же OverlayFS ядра.

Архитектура Docker: клиент, демон и компоненты исполнения

Docker включает клиентскую утилиту (CLI) и серверный компонент Docker Engine (демон). Клиент направляет запросы демону, а демон управляет объектами Docker: образами, контейнерами, сетями, томами и процессом сборки. Этот подход отделяет интерфейс управления от реализации операций и позволяет централизованно вести состояние объектов.

На более низком уровне выполнение контейнеров делегируется специализированным компонентам. Компонент containerd отвечает за управление жизненным циклом контейнеров и взаимодействие с хранилищами образов, а runc выполняет непосредственный запуск контейнера, настраивая изоляцию через пространства имён и ограничения ресурсов через cgroups. Такое разделение упрощает поддержку и развитие системы: высокоуровневые функции управления (образы, сети, тома) отделены от механизма запуска процессов ¹.

Между containerd и runc находится ещё один компонент — прослойка (shim) containerd-shim-runc-v2. Цепочка запуска выглядит так: клиент docker передаёт запрос демону dockerd по REST API через сокет /var/run/docker.sock; dockerd вызывает containerd по gRPC; containerd запускает для контейнера процесс shim; shim вызывает runc, который создаёт пространства имён и cgroups, запускает в них основной процесс контейнера и завершается ⁹. После этого родителем процесса контейнера остаётся shim. Он держит открытыми стандартные потоки контейнера (из них Docker формирует журнал), ожидает завершения процесса и сохраняет код выхода. Благодаря этому dockerd и containerd можно перезапустить или обновить, не останавливая работающие контейнеры (при включённом параметре демона live-restore). Цепочку видно в дереве процессов хоста:

ps -eo pid,ppid,cmd --forest | grep -E 'containerd-shim|nginx' | grep -v grep

  24795       1 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 3f1c9a2b7d4e... -address /run/containerd/containerd.sock
  24817   24795  \_ nginx: master process nginx -g daemon off;
  24866   24817      \_ nginx: worker process
  24867   24817      \_ nginx: worker process

Обратим внимание: родитель shim — процесс с PID 1 хоста (systemd), а не dockerd; пространство имён containerd, в котором Docker создаёт свои контейнеры, называется moby.

Docker Desktop и WSL2: контейнеры внутри Linux-ВМ

Контейнер использует ядро хоста, а Linux-контейнеру нужно ядро Linux. Поэтому на macOS и Windows Docker не может запустить Linux-контейнер напрямую, и Docker Desktop решает эту задачу виртуальной машиной: на macOS — небольшой ВМ с Linux-дистрибутивом LinuxKit под управлением фреймворка виртуализации Apple, на Windows — служебным дистрибутивом docker-desktop в WSL2, который сам является лёгкой ВМ под Hyper-V ⁷. Демон dockerd, containerd и все контейнеры работают внутри этой ВМ, а клиент docker на хосте обращается к демону через проброшенный сокет. Ядро, на котором исполняется контейнер, легко узнать:

docker info --format '{{.OperatingSystem}} | {{.KernelVersion}} | {{.Architecture}}'
docker run --rm ubuntu:24.04 uname -r

Docker Desktop | 6.10.14-linuxkit | aarch64
6.10.14-linuxkit

Этот вывод (по документации, для Mac с процессором Apple) показывает, что контейнер исполняется на ядре linuxkit служебной ВМ, а не на ядре macOS. На Linux-хосте обе команды вернут версию ядра самого хоста, например 6.8.0-85-generic.

Из этого устройства следуют практические особенности, которые иначе выглядят загадочно. Процессы контейнеров не видны в мониторе активности macOS или диспетчере задач Windows — виден только процесс ВМ. Память и процессоры для контейнеров ограничены настройками ВМ в Docker Desktop, а не объёмом памяти компьютера. Каталоги хоста, подключаемые в контейнер, передаются через механизм общих папок ВМ (на macOS — virtiofs), поэтому интенсивный файловый ввод-вывод в них заметно медленнее, чем внутри ВМ. Опубликованный порт -p 8080:80 пробрасывается из ВМ на localhost хоста отдельным сетевым компонентом Docker Desktop. На компьютере с процессором Apple ВМ имеет архитектуру arm64, и образы, собранные только для amd64, запускаются через эмуляцию с заметной потерей скорости. Внутри самой WSL2 можно установить и обычный Docker Engine — тогда он работает в ВМ WSL2 так же, как на любом Linux-хосте.

Совместимость контейнерной экосистемы обеспечивается стандартами OCI (Open Container Initiative). OCI определяет три спецификации: спецификацию среды исполнения (runtime-spec), которая описывает каталог rootfs с файлом config.json и операции create, start, kill, delete над контейнером ³; спецификацию формата образа (image-spec), которая задаёт манифест, конфигурацию и слои в виде архивов tar, адресуемых по хешу содержимого ⁴; спецификацию распространения (distribution-spec), которая стандартизует HTTP API реестра для загрузки и получения образов ⁵. runc — эталонная реализация первой из них, а реестры Docker Hub, GitHub Container Registry и реестры облачных поставщиков реализуют третью. Благодаря этому образы и средства запуска могут быть взаимозаменяемыми в пределах стандарта, а инфраструктура не оказывается жестко привязанной к одному программному продукту.

Жизненный цикл и базовые операции

Контейнер создаётся из образа, получает параметры запуска и запускает основной процесс. Контейнер считается запущенным, пока выполняется основной процесс. Это объясняет типичную ситуацию, когда контейнер «сразу останавливается»: обычно причиной является корректное завершение основного процесса, а не ошибка платформы.

Docker предоставляет механизмы автоматического перезапуска контейнеров при завершении работы — политики перезапуска --restart (no, on-failure, unless-stopped, always), которые подробно рассматриваются в теме 5. Однако эти механизмы являются локальными и не заменяют оркестрацию. Оркестрация решает задачи распределения экземпляров по узлам, управления обновлениями, масштабирования и восстановления при отказах — и будет рассматриваться далее в курсе.

Журналы и инспекция конфигурации

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

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

Команда docker logs выводит то, что основной процесс писал в стандартные потоки; Docker сохраняет эти строки драйвером журналирования (по умолчанию json-file) в файл на хосте. Команда docker inspect с шаблоном --format извлекает отдельные поля из JSON-описания контейнера:

docker logs --tail 3 web
docker inspect --format '{{.State.Status}} exit={{.State.ExitCode}} restarts={{.RestartCount}} mem={{.HostConfig.Memory}}' web
docker stop web && docker inspect --format '{{.State.Status}} exit={{.State.ExitCode}}' web

2026/10/22 09:30:12 [notice] 1#1: start worker processes
2026/10/22 09:30:12 [notice] 1#1: start worker process 29
2026/10/22 09:30:12 [notice] 1#1: start worker process 30
running exit=0 restarts=0 mem=0
web
exited exit=0

Значение mem=0 означает, что лимит памяти не задан. Код выхода после docker stop равен 0, потому что nginx корректно обработал сигнал завершения; приложение, которое не обрабатывает SIGTERM и было завершено принудительно через 10 секунд, получило бы код 137 — разбор кодов выхода и сигналов приводится в теме 5.

Реестры образов

Образы хранятся в реестрах — публичных или частных. Реестр предоставляет интерфейсы для публикации и получения образов и позволяет использовать образы как типовые артефакты поставки. Для сопровождения существенна политика версионирования: в учебных работах часто применяются теги, однако в эксплуатационных сценариях предпочтительнее исключать неоднозначность и фиксировать конкретные версии (включая возможность использования идентификатора содержимого).

Идентификатор содержимого, или дайджест (digest), — это хеш SHA-256 манифеста образа, записываемый как nginx@sha256:…. Тег — изменяемая ссылка: владелец репозитория может в любой момент перенести тег 1.28 на новую сборку с исправлениями, и два docker pull nginx:1.28 с разницей в неделю дадут разные образы. Дайджест неизменяем по построению: изменение любого байта манифеста, а значит и любого слоя, на который он ссылается, меняет хеш ⁴. Дайджест скачанного образа хранится в его метаданных:

docker image inspect nginx:1.28 --format '{{index .RepoDigests 0}}'
docker run -d nginx@sha256:5f0e9a7c1b2d...   # запуск строго определённой сборки

nginx@sha256:5f0e9a7c1b2d...

Для многоплатформенного образа тег указывает на список манифестов (image index) с отдельными манифестами для amd64, arm64 и других архитектур; Docker выбирает манифест, соответствующий платформе хоста. Использование дайджестов при сборке и развертывании рассматривается в теме 4.

В реальных системах реестр выступает частью цепочки поставки: он позволяет централизованно хранить утверждённые версии образов, управлять доступом и проводить дополнительные проверки (например, сканирование на уязвимости). Эти вопросы будут подробно рассмотрены в главах, посвящённых безопасности и сопровождению.

Ограничения и типичные ошибки интерпретации

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

Вторая ошибка — полагать, что root в контейнере безопасен, «потому что это контейнер». Без пространства имён пользователей root в контейнере — это UID 0 хоста; от полного контроля над хостом его отделяют capabilities, seccomp и профили LSM, а любой подключённый каталог хоста доступен ему с правами root ¹¹. Поэтому монтирование в контейнер сокета /var/run/docker.sock или корня хоста равносильно выдаче прав root на хосте.

Третья ошибка — переносить на Docker Desktop выводы, сделанные на Linux-хосте, и наоборот. На macOS и Windows контейнеры работают в Linux-ВМ, поэтому их процессы не видны в системе, лимиты ограничены ресурсами ВМ, а пути вроде /var/lib/docker существуют только внутри ВМ.

Четвёртая ошибка — считать, что «контейнер упал», если он перешёл в состояние Exited сразу после запуска. Контейнер живёт ровно столько, сколько его основной процесс; команда, которая выполнила работу и завершилась с кодом 0, — штатный случай. Диагностика начинается с docker ps -a (код выхода в столбце STATUS) и docker logs.

Пятая ошибка — путать ограничение и изоляцию. Пространства имён не мешают процессу израсходовать всю память хоста, а cgroups не скрывают от него чужие процессы. Контейнер без --memory и --pids-limit изолирован, но не ограничен.

Итоги темы

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

Наблюдение с хоста показывает механизм без посредников: процесс контейнера виден в ps под глобальным PID, его группа cgroups v2 называется по идентификатору контейнера, номера пространств имён отличаются от номеров хоста, а тождественное отображение UID напоминает, что без явной настройки root в контейнере остаётся root хоста. Родителем процесса является containerd-shim-runc-v2, который позволяет перезапускать демон без остановки контейнеров, а runc после создания контейнера уже не работает.

Совместимость экосистемы держится на трёх спецификациях OCI: среды исполнения, формата образа и распространения. Образ адресуется неизменяемым дайджестом, тег же — лишь изменяемый указатель на него. На macOS и Windows вся эта машинерия работает внутри Linux-ВМ Docker Desktop, что объясняет и невидимость контейнеров для хостовой ОС, и особенности производительности общих каталогов.

Следующая тема переходит от запуска готовых образов к их сборке: инструкции Dockerfile, кэш слоёв BuildKit, многоэтапная сборка и публикация в реестр.

Литература

1. Docker Documentation. What is Docker? Docker architecture. — https://docs.docker.com/get-started/docker-overview/ (дата обращения: 22.10.2026).
2. Docker Documentation. OverlayFS storage driver. — https://docs.docker.com/engine/storage/drivers/overlayfs-driver/ (дата обращения: 22.10.2026).
3. Open Container Initiative. Runtime Specification. — https://github.com/opencontainers/runtime-spec (дата обращения: 22.10.2026).
4. Open Container Initiative. Image Format Specification. — https://github.com/opencontainers/image-spec (дата обращения: 22.10.2026).
5. Open Container Initiative. Distribution Specification. — https://github.com/opencontainers/distribution-spec (дата обращения: 22.10.2026).
6. Linux man-pages. user_namespaces(7) — overview of Linux user namespaces. — https://man7.org/linux/man-pages/man7/user_namespaces.7.html (дата обращения: 22.10.2026).
7. Docker Documentation. Docker Desktop WSL 2 backend on Windows. — https://docs.docker.com/desktop/features/wsl/ (дата обращения: 22.10.2026).
8. Docker Documentation. Isolate containers with a user namespace. — https://docs.docker.com/engine/security/userns-remap/ (дата обращения: 22.10.2026).
9. containerd Documentation. — https://containerd.io/docs/ (дата обращения: 22.10.2026).
10. The Linux Kernel Documentation. Overlay Filesystem. — https://docs.kernel.org/filesystems/overlayfs.html (дата обращения: 22.10.2026).
11. Rice L. Container Security: Fundamental Technology Concepts that Protect Containerized Applications. — O'Reilly Media, 2020.

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

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

1. Почему контейнер запускается за доли секунды, а виртуальная машина — за десятки секунд? Что общего у всех контейнеров на одном хосте?
2. Чем образ отличается от контейнера? Что происходит со слоем записи при удалении контейнера?
3. Какие пространства имён использует Docker для контейнера и за что отвечает каждое из них? Почему основной процесс контейнера имеет PID 1?
4. Использует ли Docker пространство имён пользователей по умолчанию? Как проверить это по файлу /proc/<pid>/uid_map и как включить отображение UID?
5. Как по выводу docker inspect, ps и /proc/<pid>/cgroup показать, что контейнер — это процесс хоста в отдельной группе cgroups?
6. Чем ограничение ресурсов через cgroups отличается от изоляции через пространства имён? Приведите пример контейнера, который изолирован, но не ограничен.
7. Как OverlayFS объединяет слои образа и слой записи? Что такое copy-on-write и whiteout и почему удаление файла из базового слоя не уменьшает размер образа?
8. Какую роль в цепочке запуска играют dockerd, containerd, containerd-shim-runc-v2 и runc? Почему родителем процесса контейнера является shim, а не демон?
9. Какие три спецификации определяет OCI и что стандартизует каждая из них?
10. Почему на macOS и Windows Docker Desktop работает внутри Linux-ВМ? Какие практические следствия из этого вытекают?
11. Чем дайджест образа отличается от тега и почему два docker pull по одному тегу могут дать разные образы?
12. Почему контейнер переходит в состояние Exited сразу после выполнения команды echo и почему это не является ошибкой?
13. Что показывает команда docker logs и откуда Docker берёт эти данные?
14. Почему монтирование /var/run/docker.sock в контейнер равносильно выдаче прав root на хосте?
15. Какой код выхода получит контейнер, процесс которого не обработал SIGTERM при docker stop, и почему?

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

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

# Среда
docker version                      # версии клиента и сервера
docker info                         # драйвер хранилища, среда исполнения, cgroups, ядро

# Запуск и состояние
docker run -d --name web -p 8080:80 nginx:1.28
docker ps -a                        # все контейнеры, включая остановленные, с кодом выхода
docker inspect --format '{{.State.Status}} pid={{.State.Pid}} exit={{.State.ExitCode}}' web
docker logs --tail 20 web           # стандартные потоки основного процесса
docker stats --no-stream            # CPU, память и лимиты всех контейнеров
docker exec -it web sh              # команда в пространствах имён контейнера

# Образы и слои
docker history nginx:1.28
docker image inspect nginx:1.28 --format '{{range .RootFS.Layers}}{{println .}}{{end}}'
docker image inspect nginx:1.28 --format '{{index .RepoDigests 0}}'
docker system df                    # место, занятое образами, контейнерами, томами

# Наблюдение с хоста (Linux)
ps -eo pid,ppid,cmd --forest | grep -A3 containerd-shim
cat /proc/$(docker inspect -f '{{.State.Pid}}' web)/cgroup
cat /proc/$(docker inspect -f '{{.State.Pid}}' web)/uid_map

# Очистка
docker rm -f web                    # удалить контейнер вместе со слоем записи
docker image rm nginx:1.28          # удалить образ (prune -f удаляет только висячие)

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

1. Docker Documentation. Docker overview — https://docs.docker.com/get-started/docker-overview/. Официальное описание архитектуры клиента, демона, образов и реестров.
2. Open Container Initiative — https://opencontainers.org/. Отправная точка к трём спецификациям: runtime-spec, image-spec и distribution-spec.
3. Evans J. How Containers Work! — https://wizardzines.com/zines/containers/. Иллюстрированный зин о пространствах имён, cgroups, overlay и capabilities; лучший способ быстро собрать картину целиком.
4. Kerrisk M. Namespaces in operation — серия статей LWN 2013 года, начало: https://lwn.net/Articles/531114/. Пространства имён на уровне системных вызовов, в том числе подробный разбор user namespaces.
5. Rice L. Container Security. — O'Reilly Media, 2020. Книга о механизмах изоляции контейнеров и их пределах, включая построение контейнера вручную на Go.
6. The Linux Kernel Documentation. Overlay Filesystem — https://docs.kernel.org/filesystems/overlayfs.html. Точное описание lowerdir, upperdir, whiteout и copy-up.
7. Docker Documentation. Rootless mode — https://docs.docker.com/engine/security/rootless/. Как запустить Docker без прав root и какие ограничения при этом возникают.
8. Docker Documentation. Docker Desktop WSL 2 backend — https://docs.docker.com/desktop/features/wsl/. Устройство Docker Desktop на Windows и рекомендации по размещению файлов проекта.

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

От chroot к Docker

Изоляция процессов развивалась почти сорок лет. Системный вызов chroot (Unix Version 7, 1979) менял для процесса корневой каталог, но не изолировал ни процессы, ни сеть. FreeBSD Jails (2000) добавили к нему отдельные таблицы процессов, сетевые адреса и ограничение прав root. Solaris Zones (2004) довели идею до полноценных «контейнеров» с управлением ресурсами. В Linux механизмы появлялись по частям: mount namespace в 2002 году, cgroups в 2008-м, PID и network namespaces в 2006–2009 годах, и в 2008 году проект LXC собрал их в инструмент для запуска системных контейнеров. Docker, представленный в 2013 году, сначала использовал LXC, а затем собственную библиотеку libcontainer (ставшую runc). Его вклад был не в изоляции, а в формате образа со слоями, реестре и одной команде docker run, которые сделали контейнер единицей поставки программ.

Rootless-контейнеры

В режиме без прав root демон Docker и все контейнеры работают от обычного пользователя внутри пространства имён пользователей. UID 0 в контейнере отображается на UID этого пользователя, а остальные идентификаторы — на диапазон из /etc/subuid. Побег из такого контейнера даёт злоумышленнику права обычного пользователя, а не root хоста. Платой являются ограничения: сеть строится в пространстве пользователя (slirp4netns или pasta) и работает медленнее, порты ниже 1024 по умолчанию недоступны, часть драйверов хранилища и лимитов cgroups требует дополнительной настройки. Похожую модель по умолчанию использует Podman.

Лабораторная работа 3. Контейнеризация и архитектура Docker

• Раздел курса: тема 3 «Контейнеризация и архитектура Docker»

Введение

В лабораторной работе 2 изолированная среда была получена ценой второго ядра: виртуальная машина загружалась десятки секунд, а её процессы были не видны хосту. Эта работа задаёт контейнеру те же вопросы. Что именно изолировано и чем? Видит ли хост процессы контейнера? Сколько длится запуск? Что происходит с данными, записанными внутри? Ответы проверяются командами Docker и наблюдением за контейнером со стороны хоста — через /proc, ps и файлы cgroups, о которых шла речь в темах 2 и 3.

Работа состоит из семи частей. Базовая часть — части 1–5 и 7: проверка среды, жизненный цикл контейнера, слои образа и эфемерность слоя записи, пространства имён и cgroups, сравнение с ВМ. Часть 6 («сломать и починить» контейнер, который сразу завершается) выполняется по желанию.

Цель работы

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

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

• проверить установку Docker и найти в docker info драйвер хранилища, среду исполнения, версию cgroups и корневой каталог;
• объяснить по шагам, что делает docker run, и связать состояние контейнера с жизнью его основного процесса;
• показать, что два контейнера из одного образа разделяют слои образа, но имеют разные слои записи, и что изменения в слое записи теряются при удалении контейнера;
• найти процесс контейнера на хосте, его группу cgroups и пространства имён, и доказать, что без настройки user namespace root в контейнере — это root хоста;
• задать контейнеру лимит памяти, проверить его в файлах cgroups и воспроизвести завершение по OOM;
• диагностировать контейнер, который завершается сразу после запуска, по docker ps -a, docker logs и docker inspect;
• измерить время запуска контейнера и сравнить его со временем загрузки ВМ.

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

Необходимый материал изложен в теме 3: разделы «Сопоставление с виртуализацией», «Контейнер и образ», «Изоляция контейнеров» (в том числе подраздел «Наблюдение изоляции с хоста»), «Файловая система контейнера», «Архитектура Docker» и «Жизненный цикл и базовые операции». Пространства имён и cgroups v2 как механизмы ядра разобраны в теме 2.

Образы работы: hello-world (официальный проверочный образ), nginx:1.28, ubuntu:24.04. В образе ubuntu:24.04 нет утилит ps (пакет procps) и ip (пакет iproute2): это минимальный образ, и в заданиях даны способы обойтись без них.

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

• Linux: Ubuntu 24.04 с Docker Engine 27 или новее и плагином Compose v2, установленными по инструкции docs.docker.com/engine/install/ubuntu/. Чтобы выполнять docker без sudo, пользователя добавляют в группу docker (sudo usermod -aG docker $USER, затем повторный вход); следует помнить, что членство в этой группе равносильно правам root.
• Windows 11: Docker Desktop последней версии с бэкендом WSL2, либо Docker Engine, установленный внутри дистрибутива Ubuntu 24.04 в WSL2. Windows 10 снята с поддержки в октябре 2025 года и не рассматривается.
• macOS: Docker Desktop последней версии; он поддерживает текущую и две предыдущие версии macOS.
• Ресурсы: 2 ядра, 4 ГБ памяти, 5 ГБ на диске; доступ к Docker Hub.
• Проверка готовности:

docker version --format 'client {{.Client.Version}}, server {{.Server.Version}}'

Если сервер недоступен, демон Docker не запущен: на Linux — sudo systemctl start docker, на Windows и macOS — запуск Docker Desktop.

На Docker Desktop контейнеры работают внутри Linux-ВМ (тема 3, подраздел «Docker Desktop и WSL2»), поэтому команды части 4, выполняемые «на хосте» (ps, /proc/<pid>), на macOS и Windows нужно выполнять внутри этой ВМ. Попасть в её пространства имён можно привилегированным контейнером:

docker run -it --rm --privileged --pid=host ubuntu:24.04 nsenter -t 1 -m -u -n -i sh

Внутри такого сеанса команды ps, cat /proc/<pid>/cgroup и readlink /proc/<pid>/ns/pid выполняются так же, как на Linux-хосте.

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

Части выполняются по порядку. В заданиях с предсказанием результат записывается в журнал до выполнения команды. Контейнеры каждой части удаляются в её конце, образы — в конце работы.

Параметры работы задаются вариантом; номер выбирается произвольно. Далее в тексте используется вариант 1; при другом варианте порт, имена и лимиты подставляются из таблицы.

Окончательная очистка после работы:

docker rm -f web-server container-b container-a-new isolation-test limited-256 limited-128 oom-test broken-web 2>/dev/null
docker image rm nginx:1.28 ubuntu:24.04 hello-world

Команда docker image prune -f для очистки не подходит: она удаляет только «висячие» образы без тегов (dangling), а образы nginx:1.28 и ubuntu:24.04 имеют теги и останутся на месте. Удалить все образы, не используемые контейнерами, можно командой docker image prune -a, но она затронет и образы других проектов на машине.

Часть 1. Установка Docker и проверка среды контейнеризации

Задание

1. Установите Docker по официальной документации для своей ОС. Запишите версию Docker Engine и версию ОС хоста.

2. Выполните команды и сохраните их вывод:

   # Версия Docker и сведения о среде
   docker version
   
   # Подробная информация о конфигурации Docker Engine
   docker info
   

3. В выводе docker info найдите и запишите: драйвер хранилища (Storage Driver), драйвер и версию cgroups (Cgroup Driver, Cgroup Version), среду исполнения по умолчанию (Default Runtime), корневой каталог (Docker Root Dir), операционную систему и версию ядра (Operating System, Kernel Version), число контейнеров и образов.

4. Запишите предсказание: какие шаги выполнит Docker при команде docker run hello-world, если образа нет локально? Почему контейнер завершится сам? Затем выполните:

   docker run hello-world
   docker ps -a --filter ancestor=hello-world
   

5. Сравните вывод с предсказанием. Объясните по шагам, что сделали клиент, демон, containerd и runc.

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

Фрагмент docker info на Ubuntu 24.04 с Docker Engine 29 (по документации; на других версиях строки могут отличаться):

 Server Version: 29.0.1
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Cgroup Driver: systemd
 Cgroup Version: 2
 Default Runtime: runc
 Operating System: Ubuntu 24.04.3 LTS
 Kernel Version: 6.8.0-85-generic
 Docker Root Dir: /var/lib/docker

На версиях до 29 и на установках, обновлённых со старых версий, драйвер хранилища отображается как overlay2 — это классическое хранилище образов Docker; механизм в обоих случаях — OverlayFS ядра. На Docker Desktop поле Operating System содержит Docker Desktop, а версия ядра — ядро его Linux-ВМ.

Вывод docker run hello-world начинается со строк о загрузке образа:

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
...
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.
...

Сам текст сообщения перечисляет шаги: клиент обратился к демону, демон загрузил образ из Docker Hub, создал из него контейнер и запустил программу, вывод которой передал клиенту. Контейнер завершился со статусом Exited (0), потому что его основной процесс напечатал сообщение и закончил работу. Образ без тега получил тег latest по умолчанию; в остальной работе образы указываются с точной версией.

Часть 2. Жизненный цикл контейнера

Задание

1. Запустите контейнер с веб-сервером nginx в фоновом режиме и дождитесь, пока сервер начнёт отвечать (цикл нужен, потому что docker run -d возвращает управление до того, как nginx откроет порт):

   docker run -d --name web-server -p 8080:80 nginx:1.28
   until curl -fsS -o /dev/null http://localhost:8080; do sleep 0.5; done
   curl -s http://localhost:8080 | grep -o '<title>.*</title>'
   

2. Убедитесь, что контейнер работает, и запишите его состояние (docker ps).

3. Исследуйте информацию о контейнере:

   # Подробная конфигурация контейнера
   docker inspect web-server
   
   # Отдельные поля
   docker inspect --format 'image={{.Config.Image}} ip={{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}} pid={{.State.Pid}}' web-server
   docker inspect --format '{{json .NetworkSettings.Ports}} {{json .Config.Entrypoint}} {{json .Config.Cmd}}' web-server
   
   # Журналы контейнера
   docker logs web-server
   
   # Потребление ресурсов
   docker stats web-server --no-stream
   

   Запишите используемый образ, IP-адрес контейнера, проброшенные порты, точку входа и команду запуска.

4. Исследуйте переходы между состояниями контейнера:

   docker stop web-server
   docker ps -a --filter name=web-server
   
   docker start web-server
   docker ps --filter name=web-server
   
   docker restart web-server
   docker logs web-server --tail 5
   

   Запишите, как изменяется столбец STATUS после каждой операции. Предскажите и проверьте: изменится ли PID основного процесса на хосте после docker restart (docker inspect --format '{{.State.Pid}}' web-server)? Доступен ли http://localhost:8080 после перезапуска?

5. Исследуйте поведение контейнера при завершении основного процесса. Предскажите статус контейнера и код выхода, затем выполните:

   docker run --name instant-exit ubuntu:24.04 echo "Процесс завершён"
   docker run --name exit-three ubuntu:24.04 sh -c 'exit 3'
   docker ps -a --filter name=instant-exit --filter name=exit-three
   

   Объясните, почему контейнеры перешли в состояние Exited, и сопоставьте это с контейнером nginx, который продолжает работать.

6. Выполните очистку: docker rm -f web-server instant-exit exit-three.

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

Образец (идентификаторы и время будут другими):

<title>Welcome to nginx!</title>
CONTAINER ID   IMAGE        COMMAND                  CREATED          STATUS          PORTS                                     NAMES
3f1c9a2b7d4e   nginx:1.28   "/docker-entrypoint.…"   12 seconds ago   Up 11 seconds   0.0.0.0:8080->80/tcp, [::]:8080->80/tcp   web-server
image=nginx:1.28 ip=172.17.0.2 pid=24817
{"80/tcp":[{"HostIp":"0.0.0.0","HostPort":"8080"},{"HostIp":"::","HostPort":"8080"}]} ["/docker-entrypoint.sh"] ["nginx","-g","daemon off;"]

После docker stop статус — Exited (0) … ago, после start и restart — Up … seconds. PID на хосте после перезапуска меняется: остановка завершает процесс, а запуск создаёт новый процесс в тех же настройках контейнера; слой записи при этом сохраняется. Контейнер instant-exit имеет статус Exited (0), exit-three — Exited (3): код выхода основного процесса становится кодом выхода контейнера. nginx продолжает работать, потому что запущен с daemon off; и не завершается, пока его не остановят.

Часть 3. Образ и контейнер: слоистая файловая система и эфемерность

Задание

1. Загрузите образ и исследуйте его слои:

   docker pull nginx:1.28
   docker history nginx:1.28
   docker image inspect nginx:1.28 --format '{{len .RootFS.Layers}} слоёв, {{.Size}} байт'
   docker image inspect nginx:1.28 --format '{{index .RepoDigests 0}}'
   docker images nginx:1.28
   

   Запишите число слоёв, размер образа и его дайджест. Объясните, почему строк в docker history больше, чем слоёв в RootFS.Layers.

2. Создайте два контейнера из одного образа:

   docker run -d --name container-a nginx:1.28
   docker run -d --name container-b nginx:1.28
   

3. Предскажите, будет ли виден файл, созданный в контейнере A, в контейнере B. Проверьте:

   docker exec container-a sh -c "echo 'Контейнер A' > /tmp/test.txt"
   docker exec container-a cat /tmp/test.txt
   docker exec container-b cat /tmp/test.txt
   docker diff container-a
   

   Объясните результат и вывод docker diff.

4. Проверьте эфемерность слоя записи:

   # Изменить стартовую страницу nginx в контейнере A
   docker exec container-a sh -c "echo '<h1>Изменённая страница</h1>' > /usr/share/nginx/html/index.html"
   docker exec container-a cat /usr/share/nginx/html/index.html
   
   # Удалить контейнер A и создать новый из того же образа
   docker rm -f container-a
   docker run -d --name container-a-new nginx:1.28
   docker exec container-a-new head -4 /usr/share/nginx/html/index.html
   

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

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

   docker system df
   docker ps -s --filter name=container
   

   Запишите, сколько места занимают образы и сколько — контейнеры. Объясните, почему два контейнера из одного образа занимают существенно меньше места, чем две копии образа.

6. Выполните очистку: docker rm -f container-b container-a-new.

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

Образ nginx состоит примерно из семи слоёв и занимает около 190 МБ (точные числа зависят от сборки и архитектуры). Строк в docker history больше, потому что инструкции CMD, EXPOSE, ENTRYPOINT, STOPSIGNAL меняют только метаданные и создают строки нулевого размера без слоя. Файл /tmp/test.txt в контейнере B не найден (cat: /tmp/test.txt: No such file or directory), а docker diff container-a показывает строки вида C /tmp и A /tmp/test.txt — изменения, записанные в верхний слой контейнера A. После удаления контейнера A изменённая страница пропала: новый контейнер получил новый пустой слой записи поверх тех же слоёв образа, и index.html снова начинается со стандартного заголовка nginx. В docker ps -s у контейнеров размер слоя записи — единицы килобайт или байты, а в скобках указан «виртуальный» размер вместе с образом; образ хранится на диске один раз.

Часть 4. Механизмы изоляции контейнера

Задание

1. Запустите контейнер в интерактивном режиме:

   docker run -it --name isolation-test ubuntu:24.04 bash
   

   Внутри контейнера выполните команды и сохраните вывод:

   # Имя хоста (UTS namespace)
   hostname
   
   # Процессы (PID namespace); утилиты ps в образе нет, список берётся из /proc
   ls /proc | grep -E '^[0-9]+$'
   cat /proc/1/cmdline; echo
   
   # Сетевые интерфейсы (network namespace); утилиты ip в образе нет
   cat /proc/net/dev
   hostname -I
   
   # Пользователь и отображение идентификаторов (user namespace НЕ используется по умолчанию)
   id
   cat /proc/self/uid_map
   
   # Корневая файловая система (mount namespace)
   ls /
   cat /etc/os-release | head -2
   
   # Ядро — общее с хостом
   uname -r
   

   Если нужна полноценная утилита ps, её можно установить в этот контейнер: apt-get update && apt-get install -y procps. Такое изменение попадёт только в слой записи этого контейнера.

2. Не выходя из контейнера, откройте второй терминал на хосте и найдите процесс контейнера со стороны хоста (на Docker Desktop — в сеансе nsenter, см. «Перечень оснащения»):

   PID=$(docker inspect --format '{{.State.Pid}}' isolation-test)
   ps -o user,pid,ppid,cmd -p $PID
   ps -o pid,cmd -p $(ps -o ppid= -p $PID)
   cat /proc/$PID/cgroup
   sudo readlink /proc/$PID/ns/pid /proc/$PID/ns/net /proc/$PID/ns/uts
   readlink /proc/self/ns/pid /proc/self/ns/net /proc/self/ns/uts
   hostname; uname -r
   

3. Сопоставьте наблюдения. Объясните, какие пространства имён отвечают за каждое из наблюдаемых различий, кто является родителем процесса контейнера и почему, и что означает строка 0 0 4294967295 в uid_map. Предскажите и проверьте: каким пользователем на хосте принадлежит процесс bash контейнера?

4. Выйдите из контейнера командой exit и выполните docker ps -a --filter name=isolation-test. Почему контейнер остановился?

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

Образец вывода внутри контейнера (сокращён):

4f2a9c1e7b3d
1
9
10
bash
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  eth0:    1046      11    0    0    0     0          0         0        0       0    0    0    0     0       0          0
172.17.0.2
uid=0(root) gid=0(root) groups=0(root)
         0          0 4294967295
...
PRETTY_NAME="Ubuntu 24.04.3 LTS"
6.8.0-85-generic

и на хосте:

USER         PID    PPID CMD
root       31502   31480 bash
    PID CMD
  31480 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 4f2a9c1e7b3d... -address /run/containerd/containerd.sock
0::/system.slice/docker-4f2a9c1e7b3d....scope
pid:[4026532790]
net:[4026532793]
uts:[4026532788]
pid:[4026531836]
net:[4026531840]
uts:[4026531838]

Имя хоста в контейнере — короткий идентификатор контейнера (UTS namespace). Внутри видны только PID 1 (bash) и процессы самой команды ls | grep (PID namespace), а на хосте тот же bash имеет PID 31502 и виден обычной командой ps — в отличие от процессов ВМ в лабораторной работе 2. В контейнере свои интерфейсы lo и eth0 (network namespace) и своё дерево файлов Ubuntu (mount namespace), но ядро то же, что у хоста: uname -r совпадает. Номера всех пространств имён процесса контейнера отличаются от номеров оболочки хоста. Родитель — containerd-shim-runc-v2. Отображение 0 0 4294967295 тождественное: отдельного user namespace нет, и процесс bash принадлежит на хосте пользователю root (UID 0). После exit основной процесс bash завершился, поэтому контейнер перешёл в Exited (0).

Часть 5. Ограничение ресурсов через cgroups

Задание

1. Запустите два контейнера с различными лимитами памяти и проверьте лимиты тремя способами — через docker stats, через файлы cgroups внутри контейнера и через конфигурацию:

   docker run -d --name limited-256 --memory=256m nginx:1.28
   docker run -d --name limited-128 --memory=128m nginx:1.28
   docker stats --no-stream limited-256 limited-128
   docker exec limited-256 cat /sys/fs/cgroup/memory.max /sys/fs/cgroup/memory.swap.max
   docker inspect --format '{{.HostConfig.Memory}} {{.HostConfig.MemorySwap}}' limited-256
   

   Запишите столбцы MEM USAGE / LIMIT и значения файлов. Объясните, почему memory.swap.max не равен нулю, хотя подкачка не настраивалась.

2. Запишите предсказание: что произойдёт с процессом, который бесконечно наращивает потребление памяти, в контейнере с лимитом 64 МиБ и запретом подкачки? Каким будет код выхода? Затем проверьте. Команда tail /dev/zero ищет конец «строки» в бесконечном потоке нулевых байтов и поэтому накапливает его в памяти без ограничения; ключ --memory-swap, равный --memory, запрещает контейнеру использовать подкачку, иначе процесс мог бы долго «уходить» в swap вместо завершения:

   docker run --name oom-test --memory=64m --memory-swap=64m ubuntu:24.04 tail /dev/zero
   echo "код выхода: $?"
   docker inspect oom-test --format 'OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}}'
   

3. На Linux-хосте найдите запись ядра о завершении процесса: sudo dmesg | grep -i -A1 'memory cgroup out of memory' | tail -2 (или journalctl -k | grep -i oom | tail -3). Объясните механизм OOM Killer и его связь с cgroups: какой процесс был выбран и почему не пострадали процессы вне контейнера.

4. Выполните очистку: docker rm -f isolation-test limited-256 limited-128 oom-test.

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

NAME          CPU %     MEM USAGE / LIMIT   MEM %     NET I/O       BLOCK I/O     PIDS
limited-256   0.00%     9.1MiB / 256MiB     3.55%     1.05kB / 0B   0B / 12.3kB   13
limited-128   0.00%     8.9MiB / 128MiB     6.95%     1.05kB / 0B   0B / 12.3kB   13
268435456
268435456
268435456 536870912
код выхода: 137
OOMKilled=true ExitCode=137

Лимит в docker stats совпадает с заданным, а файл memory.max внутри контейнера содержит его же в байтах: контейнер видит свою группу cgroups как корень /sys/fs/cgroup благодаря пространству имён cgroup. Если --memory-swap не задан, Docker устанавливает его равным удвоенному --memory, то есть разрешает столько же подкачки, сколько памяти; поэтому memory.swap.max равен 256 МиБ, а MemorySwap — 512 МиБ. Контейнер oom-test завершается в течение секунды с кодом 137 (128 + 9, сигнал SIGKILL) и признаком OOMKilled=true; в журнале ядра — строка вида Memory cgroup out of memory: Killed process 32011 (tail) …. Ядро выбирает жертву только среди процессов группы, исчерпавшей свой лимит, поэтому остальная система не затрагивается. Если на хосте нет подкачки, результат одинаков и без --memory-swap; с подкачкой и без этого ключа процесс сначала заполнил бы 64 МиБ разрешённого swap, и время до завершения было бы больше и менее предсказуемо.

Часть 6. Контейнер, который сразу завершается: сломать и починить

Эта часть выполняется по желанию.

Задание

1. Запустите nginx с «неправильной» командой — без директивы daemon off;:

   docker run -d --name broken-web -p 8080:80 nginx:1.28 nginx
   

2. Предскажите, будет ли контейнер работать и будет ли отвечать curl http://localhost:8080. Проверьте через несколько секунд: docker ps -a --filter name=broken-web.

3. Проведите диагностику так, как если бы причина была неизвестна: посмотрите код выхода и статус, журнал (docker logs broken-web), команду запуска (docker inspect --format '{{json .Config.Cmd}}' broken-web) и сравните её с командой образа (docker image inspect --format '{{json .Config.Cmd}}' nginx:1.28).

4. Сформулируйте причину через понятие основного процесса контейнера и исправьте запуск:

   docker rm broken-web
   docker run -d --name broken-web -p 8080:80 nginx:1.28 nginx -g 'daemon off;'
   until curl -fsS -o /dev/null http://localhost:8080; do sleep 0.5; done; echo OK
   

5. Второй вариант поломки — конфликт портов: не удаляя broken-web, запустите ещё один контейнер с -p 8080:80. Прочитайте сообщение об ошибке, определите, какой контейнер занимает порт (docker ps --filter publish=8080), и запустите второй контейнер на другом порту хоста. Затем удалите оба контейнера.

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

Первый запуск даёт статус Exited (0) через секунду, а журнал пуст или содержит только сообщения стартового скрипта. Команда nginx без daemon off; запускает мастер-процесс, который порождает фоновую копию и сам немедленно завершается с кодом 0; для Docker завершение основного процесса означает завершение контейнера, и фоновая копия уничтожается вместе с ним. В образе по умолчанию команда равна ["nginx","-g","daemon off;"], а передача аргумента nginx после имени образа её заменила. После исправления curl возвращает страницу. Во втором случае docker run сообщает об ошибке вида Bind for 0.0.0.0:8080 failed: port is already allocated, а контейнер остаётся в состоянии Created: порт хоста может быть опубликован только одним контейнером.

Часть 7. Сравнение контейнера и виртуальной машины

Задание

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

   time docker run --rm ubuntu:24.04 true
   

2. Заполните сравнительную таблицу на основании наблюдений этой и предыдущей лабораторной работы; в строках со временем и памятью укажите числа из журнала.

   Характеристика	Виртуальная машина (VirtualBox)	Контейнер (Docker)
   Наличие собственного ядра ОС
   Время запуска среды
   Механизм изоляции процессов
   Механизм изоляции сети
   Видимость процессов с хоста
   Пользователь root внутри и на хосте
   Накладные расходы на дисковое пространство
   Ограничение потребления памяти и реакция на его превышение

3. Сформулируйте, в каких сценариях из лабораторной работы 1 уместнее ВМ, а в каких — контейнеры, и почему на практике их часто сочетают.

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

time docker run --rm ubuntu:24.04 true при уже загруженном образе обычно показывает real от 0,3 до 1 секунды на Linux; это время создания пространств имён, cgroups и слоя записи, запуска процесса и удаления контейнера, а не загрузки ОС. Разница с загрузкой ВМ из лабораторной работы 2 — один–два порядка. В таблице ожидаются, в частности, такие выводы: процессы контейнера видны с хоста, а процессы ВМ — нет; root контейнера по умолчанию совпадает с root хоста, root гостя ВМ — нет; превышение лимита памяти в контейнере завершает процесс внутри группы (OOM), а гость ВМ просто видит меньше памяти и решает проблему своим собственным OOM Killer.

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

Журнал ведётся для себя: для каждого задания с предсказанием записываются предсказание, команда, значимые строки фактического вывода и объяснение расхождения. Отдельно стоит записать условия: ОС хоста, Docker Engine или Docker Desktop, версию Docker и значения Storage Driver и Cgroup Version. Эти записи пригодятся в темах 4–6, где те же контейнеры будут собираться, ограничиваться и соединяться в сеть.

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

1. Какие действия выполняют клиент, dockerd, containerd, shim и runc при обработке команды docker run, если указанный образ отсутствует локально? Какой из этих процессов остаётся родителем процесса контейнера и зачем?
2. Почему контейнер завершает работу сразу после выполнения команды echo? Почему nginx, запущенный без daemon off;, ведёт себя так же?
3. Объясните различие между образом и контейнером. Можно ли изменить содержимое образа, записав файл внутри работающего контейнера?
4. Два контейнера созданы из одного образа. Изменение файла в первом контейнере не отражается во втором. Какой механизм это обеспечивает и что показывает docker diff?
5. Почему строк в docker history больше, чем слоёв образа? Чем дайджест образа отличается от тега?
6. Перечислите пространства имён Linux, используемые при контейнеризации, и поясните роль каждого. Какое пространство имён отвечает за то, что контейнер видит собственный PID 1, и под каким PID этот процесс виден на хосте?
7. Почему процесс, работающий в контейнере от root, по умолчанию является root и на хосте? Какие механизмы ограничивают его возможности и как включить отображение идентификаторов?
8. Чем ограничение ресурсов через cgroups отличается от изоляции через пространства имён? Почему для воспроизводимого OOM в части 5 потребовался ключ --memory-swap?
9. Что означает код выхода 137 и как отличить завершение по OOM от завершения командой docker kill?
10. Что произойдёт с данными, записанными в файловую систему контейнера, если контейнер будет удалён? Каким образом можно сохранить данные между пересозданиями контейнера?
11. Почему на macOS и Windows процессы контейнеров не видны в системном мониторе, а на Linux видны в ps?