Управление контейнерами в среде выполнения

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

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

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

Параметры запуска контейнера

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

Переменные окружения и аргументы команды

Одним из основных способов передачи конфигурации контейнеру являются переменные окружения (environment variables). Они задаются при запуске и доступны процессу внутри контейнера точно так же, как переменные окружения в обычной операционной системе. Переменные окружения удобны тем, что позволяют отделить конфигурацию от образа: один и тот же артефакт может быть запущен с разными параметрами подключения к базе данных, адресами внешних сервисов или режимами работы приложения. Этот принцип — конфигурация в окружении, а не в коде — сформулирован в методологии «двенадцати факторов» ¹⁴ и поддерживается ключами -e и --env-file команды docker run ¹.

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

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

Точка входа и команда по умолчанию

Для правильного понимания параметров запуска необходимо различать два механизма, определяющих поведение контейнера при старте: точку входа (entrypoint) и команду по умолчанию (cmd). Точка входа задаёт основной исполняемый файл или сценарий, который будет вызван при запуске контейнера. Команда по умолчанию определяет аргументы, передаваемые точке входа. Если точка входа не задана, команда по умолчанию сама является запускаемой программой. Оболочка участвует в запуске не в зависимости от наличия точки входа, а в зависимости от формы записи: exec-форма (JSON-массив, CMD ["python", "app.py"]) запускает программу напрямую, а shell-форма (строка, CMD python app.py) превращается в /bin/sh -c "python app.py" ³.

Взаимодействие двух инструкций в обеих формах задаётся таблицей из справочника Dockerfile ³. Для краткости e1 e2 — точка входа, c1 c2 — команда.

Из таблицы видны две неочевидные вещи. Shell-форма ENTRYPOINT полностью игнорирует CMD и аргументы docker run. Сочетание exec-формы ENTRYPOINT с shell-формой CMD передаёт программе бессмысленные аргументы /bin/sh -c .... Работоспособная комбинация для «параметризуемой команды» — обе инструкции в exec-форме:

ENTRYPOINT ["python", "-m", "http.server"]
CMD ["8000"]

docker run --rm demo:entry            # python -m http.server 8000
docker run --rm demo:entry 9000       # python -m http.server 9000: аргументы заменили CMD
docker run --rm --entrypoint python demo:entry -V   # ENTRYPOINT заменяется только ключом --entrypoint

Если CMD не задан и в самом образе, он наследуется от базового образа: в python:3.12-slim это CMD ["python3"], поэтому docker run -it python:3.12-slim открывает интерпретатор.

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

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

Проброс портов и сетевые параметры

Контейнер по умолчанию работает в изолированном сетевом пространстве. Приложение внутри контейнера может слушать сетевой порт, но это не означает, что порт доступен извне. Для предоставления доступа к сервису из внешней сети используется проброс портов (port mapping): при запуске контейнера указывается соответствие между портом хостовой машины и портом внутри контейнера.

Различие между инструкцией EXPOSE и публикацией порта разобрано в теме 4. Здесь достаточно формы ключа -p, которая задаёт адрес хоста, порт хоста и порт контейнера ²:

docker run -d -p 8080:8000 demo:1.0             # все адреса хоста, порт 8080 -> 8000 контейнера
docker run -d -p 127.0.0.1:8080:8000 demo:1.0   # только локальный адрес хоста
docker run -d -p 8000 demo:1.0                  # случайный свободный порт хоста

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

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

Ограничение ресурсов

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

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

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

Ключи docker run переводятся в файлы интерфейса cgroup v2 ⁵¹³. Ключ --cpus=0.5 записывается в cpu.max как квота 50 000 мкс процессорного времени на период 100 000 мкс: за каждые 100 мс контейнер может занять процессор не более чем на 50 мс суммарно по всем ядрам, после чего его потоки ждут начала следующего периода. Ключ --memory=64m записывается в memory.max как 67 108 864 байта.

docker run --rm --cpus=0.5 --memory=64m python:3.12-slim \
    cat /sys/fs/cgroup/cpu.max /sys/fs/cgroup/memory.max

50000 100000
67108864

Отдельно задаётся подкачка. Если указан --memory, но не указан --memory-swap, контейнер при наличии на хосте раздела подкачки может дополнительно использовать столько же подкачки, сколько памяти, то есть всего вдвое больше лимита ⁵. Тогда приложение, превысившее лимит, не завершается, а замедляется из-за вытеснения страниц на диск, и опыт с OOM становится невоспроизводимым. Значение --memory-swap, равное --memory, запрещает подкачку, и превышение лимита приводит к OOM:

docker run --name oom --memory=64m --memory-swap=64m python:3.12-slim \
    python -c "b = bytearray(200 * 1024 * 1024)"
docker inspect --format '{{.State.ExitCode}} {{.State.OOMKilled}}' oom

137 true

Код 137 означает гибель от сигнала SIGKILL, а поле OOMKilled уточняет, что сигнал послал механизм OOM ядра, а не пользователь. В журнале контейнера при этом нет никакого сообщения от приложения: оно не получило возможности что-либо записать.

Политика перезапуска

При запуске контейнера можно задать политику перезапуска (restart policy), которая определяет поведение среды выполнения при завершении контейнера. Существуют несколько вариантов: контейнер не перезапускается; перезапускается всегда; перезапускается только в случае ошибки; перезапускается всегда, кроме явной остановки пользователем.

Перезапуск выполняет демон Docker, а не сам контейнер, поэтому политика действует и после перезагрузки хоста, если демон запускается автоматически. Явная команда docker stop всегда останавливает контейнер, при любой политике: иначе контейнер с always было бы невозможно остановить. Чтобы контейнер, падающий сразу после старта, не загружал хост, перед каждым перезапуском добавляется задержка, удваивающаяся начиная со 100 мс; она сбрасывается, если контейнер проработал не менее 10 с ⁴. Число выполненных перезапусков видно в поле RestartCount:

docker run -d --name crash --restart=on-failure:3 python:3.12-slim \
    python -c "import sys; print('старт'); sys.exit(1)"
sleep 5
docker inspect --format '{{.RestartCount}} {{.State.Status}} {{.State.ExitCode}}' crash

3 exited 1

После третьего перезапуска контейнер остаётся в состоянии exited, а docker logs crash содержит четыре строки «старт» — первый запуск и три повторных.

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

Связь параметров запуска с воспроизводимостью

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

Основной процесс и завершение контейнера

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

Процесс PID 1

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

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

Особая роль PID 1 закреплена в ядре. Для обычного процесса у каждого сигнала есть действие по умолчанию (англ. default disposition): для SIGTERM и SIGINT это завершение процесса ⁶. Для процесса init пространства имён PID ядро действие по умолчанию не применяет: сигнал, для которого init не установил обработчик, просто отбрасывается. Это касается и сигналов, посланных из родительского пространства имён, то есть с хоста; исключение составляют только SIGKILL и SIGSTOP, присланные из родительского пространства, — они доставляются принудительно ⁷. Защита задумана для настоящего init, гибель которого означает гибель всей системы, но в контейнере у неё неожиданное следствие: программа, которая вне контейнера корректно умирает по SIGTERM, просто потому что не трогает обработку сигналов, будучи PID 1, на SIGTERM не реагирует вовсе.

docker run -d --name sleeper python:3.12-slim python -c "import time; time.sleep(600)"
time docker stop sleeper    # около 10 с: SIGTERM отброшен ядром, через 10 с пришёл SIGKILL
docker run -d --init --name sleeper2 python:3.12-slim python -c "import time; time.sleep(600)"
time docker stop sleeper2   # доли секунды: PID 1 — docker-init, Python — обычный процесс

Во втором случае PID 1 становится маленькая программа инициализации docker-init (это tini), которая устанавливает обработчики, пересылает полученные сигналы дочернему процессу и собирает завершившиеся процессы-«зомби» ². Python больше не PID 1, к нему применяется действие по умолчанию, и он завершается по SIGTERM.

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

Обработка сигналов и корректное завершение

Когда пользователь или среда выполнения инициирует остановку контейнера, Docker отправляет процессу PID 1 сигнал SIGTERM. Этот сигнал предлагает процессу завершиться корректно: закрыть сетевые соединения, сбросить буферы данных, освободить ресурсы. Если процесс не завершается в течение установленного времени ожидания (по умолчанию 10 секунд), Docker отправляет сигнал SIGKILL, который принудительно прекращает выполнение процесса без возможности корректного завершения.

Проблема состоит в том, что не все приложения корректно обрабатывают SIGTERM. Если приложение запущено через оболочку (shell), например через CMD ["sh", "-c", "python app.py; echo done"], то PID 1 получает оболочка, а не приложение. Оболочка, как правило, не передаёт полученный сигнал дочернему процессу, а сама, будучи PID 1 без обработчика SIGTERM, этот сигнал не получает вовсе — его отбрасывает ядро. В результате приложение не получает уведомления о необходимости завершения и продолжает работать до истечения тайм-аута, после чего принудительно завершается сигналом SIGKILL. Такое поведение приводит к потере данных, незавершённым транзакциям и увеличению времени остановки контейнера.

Для избежания этой проблемы рекомендуется использовать exec-форму инструкций CMD и ENTRYPOINT в Dockerfile (например, CMD ["python", "app.py"] вместо CMD python app.py). В exec-форме приложение становится процессом PID 1 непосредственно и получает сигналы напрямую. Альтернативный подход — использование легковесного процесса инициализации (init process), который берёт на себя роль PID 1 и корректно передаёт сигналы основному приложению. Docker предоставляет встроенную поддержку такого механизма через параметр запуска --init.

Пример выше намеренно содержит вторую команду после python app.py. Многие оболочки, получив через -c единственную простую команду, не порождают дочерний процесс, а заменяют себя программой системным вызовом exec; так поступает bash и, в зависимости от версии, dash, который в Debian и в образах python:*-slim вызывается как /bin/sh. Тогда sh -c "python app.py" даёт PID 1 = python, и проблема маскируется. Оптимизация не гарантирована и пропадает от любой второй команды, поэтому полагаться на неё нельзя. В сценариях-обёртках (англ. entrypoint script), которые подготавливают окружение и затем запускают приложение, последнюю команду явно записывают через exec:

#!/bin/sh
# docker-entrypoint.sh: подготовка, затем замена оболочки приложением
set -e
python manage.py check
exec python app.py "$@"

Сигнал и время остановки

Сигнал, который docker stop посылает первым, и время ожидания до SIGKILL настраиваются. Инструкция STOPSIGNAL в Dockerfile задаёт сигнал остановки для образа: например, nginx завершает обслуживание текущих запросов по SIGQUIT, поэтому в официальном образе nginx записано STOPSIGNAL SIGQUIT ³. Время ожидания задаётся при запуске ключом --stop-timeout или при остановке ключом -t:

docker run -d --stop-timeout 30 --name api demo:1.0   # сервису нужно до 30 с на завершение
docker stop -t 3 api                                  # для этой остановки ждать только 3 с

Время ожидания должно быть больше, чем приложению реально нужно на завершение текущих запросов, иначе корректное завершение превращается в принудительное. В Kubernetes та же пара «сигнал — ожидание — SIGKILL» задаётся полем terminationGracePeriodSeconds (по умолчанию 30 с), подробно — в теме 7.

Коды завершения

Код завершения PID 1 становится кодом завершения контейнера и виден в docker ps -a и docker inspect. Если процесс убит сигналом, Docker, следуя соглашению оболочек, сообщает код 128 + номер сигнала ²⁶.

Код 137 сам по себе не различает OOM и принудительную остановку: различие даёт поле .State.OOMKilled, рассмотренное выше. В Kubernetes те же коды видны в поле lastState.terminated.exitCode пода, а OOM отображается причиной OOMKilled (тема 7).

Типичные причины немедленного завершения контейнера

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

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

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

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

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

Инспекция и сопровождение контейнера

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

Журналы приложения

Основным источником информации о поведении приложения в контейнере являются журналы (logs). В контейнерной модели стандартной практикой считается направление вывода приложения в стандартные потоки: стандартный поток вывода (stdout) и стандартный поток ошибок (stderr). Docker перехватывает эти потоки и сохраняет их содержимое, предоставляя доступ через команду docker logs.

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

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

По умолчанию Docker использует драйвер json-file: каждая строка вывода записывается как JSON-объект в файл /var/lib/docker/containers/<id>/<id>-json.log на хосте, и без настройки файл растёт неограниченно ¹¹. Ротация задаётся для отдельного контейнера ключами --log-opt или для всех новых контейнеров в /etc/docker/daemon.json:

docker run -d --log-opt max-size=10m --log-opt max-file=3 --name api demo:1.0
docker logs --since 5m --timestamps api

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

При таких параметрах журнал контейнера занимает не более 3 × 10 МБ = 30 МБ, а docker logs показывает только то, что осталось в этих файлах. Настройки daemon.json применяются к контейнерам, созданным после перезапуска демона; существующие контейнеры сохраняют прежние параметры.

Инспекция конфигурации контейнера

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

Инспекция также позволяет проверить фактические ограничения ресурсов, назначенные контейнеру, его сетевой адрес в контейнерной сети, политику перезапуска и другие параметры, которые могли быть заданы при запуске. Это делает docker inspect инструментом верификации: инженер может убедиться, что контейнер запущен именно с теми параметрами, которые были запланированы.

Полный вывод docker inspect — JSON-документ на сотни строк, поэтому нужные поля извлекают шаблоном Go через --format. Сетевые адреса хранятся по сетям, к которым подключён контейнер, поэтому адрес получают перебором range, а не устаревшим полем верхнего уровня .NetworkSettings.IPAddress, которое в современных версиях Docker пусто или отсутствует:

docker inspect --format '{{.State.Status}} pid={{.State.Pid}} restarts={{.RestartCount}}' api
docker inspect --format '{{range $net, $cfg := .NetworkSettings.Networks}}{{$net}} {{$cfg.IPAddress}}{{end}}' api
docker inspect --format '{{json .Config.Env}}' api
docker inspect --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}} {{.HostConfig.RestartPolicy.Name}}' api

running pid=48213 restarts=0
bridge 172.17.0.2
["PORT=8000","PATH=/usr/local/bin:...","GREETING=..."]
134217728 500000000 on-failure

Поле .State.Pid — номер процесса с точки зрения хоста: внутри контейнера тот же процесс имеет PID 1. Ограничения хранятся в базовых единицах: память в байтах (128 МиБ = 134 217 728), процессор в миллиардных долях ядра (--cpus=0.5 = 500 000 000).

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

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

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

Мониторинг потребления ресурсов

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

docker stats --no-stream api

CONTAINER ID   NAME   CPU %   MEM USAGE / LIMIT   MEM %    NET I/O         BLOCK I/O   PIDS
3b1f0c2d9e4a   api    0.02%   19.6MiB / 128MiB    15.31%   3.1kB / 2.4kB   0B / 0B     1

Значения берутся из счётчиков cgroup контейнера. Столбец LIMIT равен --memory, если лимит задан, и объёму памяти хоста (или ВМ Docker Desktop), если нет. MEM USAGE в cgroup v2 — это потребление памяти за вычетом неактивного файлового кэша, поэтому оно может расходиться с RSS процесса, который показывает ps.

Проверка работоспособности: HEALTHCHECK

Контейнер в состоянии running означает лишь, что PID 1 жив. Процесс может зависнуть, исчерпать пул соединений или потерять доступ к базе данных, оставаясь «работающим». Инструкция HEALTHCHECK задаёт команду, которую Docker периодически выполняет внутри контейнера: код 0 означает «здоров», код 1 — «нездоров» ³.

HEALTHCHECK --interval=10s --timeout=3s --start-period=5s --retries=3 \
    CMD ["python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/', timeout=2)"]

Первая проверка выполняется через --interval после старта; неудачи в течение --start-period не учитываются; состояние unhealthy выставляется после --retries неудач подряд. Значения по умолчанию — 30 с, 30 с, 0 с и 3. Состояние видно в docker ps (Up 1 minute (healthy)) и подробно — в docker inspect:

docker inspect --format '{{.State.Health.Status}} {{.State.Health.FailingStreak}}' api

healthy 0

Важное ограничение: сам Docker Engine на состояние unhealthy не реагирует — не перезапускает контейнер и не убирает его из балансировки. Состояние используют внешние механизмы: Docker Compose ждёт healthy перед запуском зависимых сервисов (тема 6). Kubernetes инструкцию HEALTHCHECK игнорирует и использует собственные пробы livenessProbe и readinessProbe (тема 7). Команду проверки следует писать средствами, которые точно есть в образе: в python:3.12-slim нет curl, поэтому проверка выполнена интерпретатором Python.

На уровне единичного контейнера docker stats является инструментом оперативного наблюдения. Для систематического мониторинга, хранения истории метрик и настройки оповещений требуются внешние системы наблюдаемости, которые рассматриваются в теме, посвящённой безопасности и наблюдаемости контейнерных приложений.

Границы допустимого вмешательства

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

Неизменяемость среды и обновление приложений

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

Суть принципа неизменяемости

В традиционной модели эксплуатации серверов обновление приложения нередко выполнялось путём ручного копирования файлов, установки пакетов и изменения конфигурации на работающем сервере. Такой подход порождает ряд проблем. Состояние сервера постепенно отклоняется от первоначального описания (явление, известное как «дрейф конфигурации», configuration drift). Воспроизвести точное состояние системы на другом узле становится невозможно без детальной документации каждого выполненного действия. Откат к предыдущей версии затруднён, поскольку изменения накапливаются без формальной фиксации.

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

Цикл обновления приложения

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

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

Ошибки ручной модификации контейнера

Несмотря на ясность принципа неизменяемости, на практике возникает соблазн внести «быстрое исправление» непосредственно в работающий контейнер. Типичные примеры: ручная правка конфигурационного файла через docker exec, установка дополнительного пакета для решения текущей проблемы, изменение прав доступа к файлам внутри контейнера.

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

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

Принцип неизменяемости можно не только соблюдать, но и обеспечить технически. Ключ --read-only монтирует корневую файловую систему контейнера только для чтения: слой записи не используется, и ни приложение, ни злоумышленник, получивший выполнение кода, не могут изменить файлы образа. Каталоги, куда приложению всё же нужно писать временные файлы, монтируются отдельно как tmpfs — файловая система в оперативной памяти ¹⁰:

docker run --rm --read-only python:3.12-slim touch /tmp/x
docker run --rm --read-only --tmpfs /tmp:size=16m python:3.12-slim sh -c 'touch /tmp/x && echo ok'

touch: cannot touch '/tmp/x': Read-only file system
ok

Попытка запустить так существующее приложение сразу показывает, куда оно пишет: каждый каталог, вызывающий ошибку, либо переносится в tmpfs (временные данные), либо в том (данные, которые нужно сохранить), либо означает ошибку проектирования. В Kubernetes тот же режим задаётся полем readOnlyRootFilesystem контекста безопасности (тема 11).

Границы применимости принципа неизменяемости

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

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

Docker-тома и монтирование каталогов хоста

Как было показано в теме 3, всё, что процесс записывает в файловую систему контейнера, попадает в слой записи, а слой записи удаляется вместе с контейнером. Цикл обновления из предыдущего раздела удаляет контейнер при каждом выпуске новой версии, поэтому база данных, хранящая файлы в слое записи, теряла бы все данные при каждом обновлении. Кроме того, запись через overlay2 медленнее записи в обычную файловую систему: первое изменение файла из нижнего слоя копирует его целиком в слой записи. Docker предлагает три способа подключить к дереву каталогов контейнера хранилище, не связанное со слоем записи: именованный том, монтирование каталога хоста и tmpfs. Схема на рисунке ниже показывает, откуда берутся данные в каждом из трёх случаев.

Именованные тома

Том (англ. volume) — объект Docker со своим именем и жизненным циклом, независимым от контейнеров ⁸. Драйвер local, используемый по умолчанию, хранит данные тома в каталоге /var/lib/docker/volumes/<имя>/_data на хосте; в Docker Desktop этот каталог находится внутри служебной Linux-ВМ, а не в файловой системе macOS или Windows. Том подключается к контейнеру ключом -v имя:путь или, в более явной записи, --mount:

docker volume create notes-data
docker run -d --name db -v notes-data:/var/lib/postgresql/data \
    -e POSTGRES_PASSWORD=secret postgres:17
# эквивалентная запись
docker run -d --name db --mount type=volume,src=notes-data,dst=/var/lib/postgresql/data \
    -e POSTGRES_PASSWORD=secret postgres:17
docker volume inspect --format '{{.Mountpoint}}' notes-data

/var/lib/docker/volumes/notes-data/_data

Том переживает контейнер потому, что контейнер лишь ссылается на него по имени. Команда docker rm db удаляет слой записи контейнера, но не том; новый контейнер, запущенный с тем же -v notes-data:..., увидит те же файлы. Именно это позволяет обновлять базу данных заменой контейнера: образ postgres:17 заменяется новым выпуском, а данные остаются в томе. Удаляется том только явно:

docker volume ls
docker volume rm notes-data        # ошибка, если том подключён к существующему контейнеру
docker volume prune                # удаляет неиспользуемые анонимные тома
docker volume prune --all          # удаляет все неиспользуемые тома, включая именованные

Кроме именованных, бывают анонимные тома. Их создаёт инструкция VOLUME в Dockerfile или ключ -v с одним путём (-v /data); имя — случайная строка из 64 шестнадцатеричных символов. Анонимный том удаляется вместе с контейнером, если контейнер удалён с ключом -v или запущен с --rm, иначе он остаётся «сиротой» и занимает диск, пока его не удалит docker volume prune. Полезное свойство томов: если пустой том подключается к каталогу, в котором в образе уже есть файлы, Docker перед запуском копирует эти файлы в том вместе с владельцем и правами ⁸.

Монтирование каталогов хоста

Монтирование каталога хоста (англ. bind mount) делает видимым в контейнере произвольный каталог или файл хоста ⁹. Docker им не управляет: путь выбирает пользователь, данные лежат там, где лежали, и изменения видны одновременно с обеих сторон, потому что это один и тот же каталог.

docker run -d --name web -v "$PWD/site:/usr/share/nginx/html:ro" -p 8080:80 nginx:1.29
docker run -d --name web2 --mount type=bind,src="$PWD/site",dst=/usr/share/nginx/html,readonly -p 8081:80 nginx:1.29

Два синтаксиса ведут себя по-разному при отсутствии пути на хосте: -v молча создаёт пустой каталог, владельцем которого будет root, а --mount завершается ошибкой. Вторая реакция обычно полезнее: опечатка в пути обнаруживается сразу, а не превращается в пустой сайт. Монтирование закрывает собой содержимое образа по тому же пути — файлы образа в /usr/share/nginx/html в контейнере не видны, — и, в отличие от тома, ничего из образа в каталог хоста не копирует.

Монтирование каталогов хоста незаменимо при разработке (код правится на хосте, приложение в контейнере видит изменения без пересборки образа) и для передачи конфигурации. В эксплуатации оно делает контейнер зависимым от структуры каталогов конкретного хоста, а монтирование чувствительных путей (/, /etc, /var/run/docker.sock) с правами записи фактически даёт контейнеру управление хостом. На macOS и Windows каталог передаётся из хоста во ВМ Docker Desktop механизмом общего доступа к файлам, поэтому операции с множеством мелких файлов там заметно медленнее, чем в томе.

Права доступа и UID

Ядро проверяет права на файлы по числовым UID и GID, а имена пользователей существуют только в файлах /etc/passwd хоста и образа и могут не совпадать ¹². Пространство имён пользователей Docker по умолчанию не использует, поэтому UID 1000 в контейнере — это UID 1000 на хосте. Отсюда типичная ошибка: образ запускает приложение как USER 10001 (тема 4), а каталог хоста принадлежит пользователю хоста с UID 1000 и правами 755:

mkdir -p data
docker run --rm --user 10001 -v "$PWD/data:/data" python:3.12-slim touch /data/x

touch: cannot touch '/data/x': Permission denied

Исправлений три, и выбор зависит от сценария. При разработке контейнер запускают с UID пользователя хоста: --user "$(id -u):$(id -g)". В эксплуатации каталог хоста передают во владение UID приложения (sudo chown 10001:10001 data). Для именованного тома достаточно в Dockerfile создать каталог точки монтирования с нужным владельцем (RUN mkdir /data && chown 10001:10001 /data): при первом подключении пустого тома Docker скопирует каталог вместе с владельцем. Ослаблять права до 777 не следует — это открывает каталог всем пользователям хоста.

Выбор способа хранения

Том решает задачу сохранности данных при пересоздании контейнера, но только в пределах одного хоста: при отказе диска или переносе нагрузки на другой узел данные тома теряются или остаются недоступны. Резервное копирование тома выполняется вспомогательным контейнером, который подключает том и каталог хоста одновременно:

docker run --rm -v notes-data:/data:ro -v "$PWD:/backup" python:3.12-slim \
    tar czf /backup/notes-data.tgz -C /data .

Хранилище, независимое от узла, — сетевые тома, PersistentVolume и объектные хранилища — рассматривается в темах 8 и 10, а описание томов вместе с сервисами в одном файле — в теме 6, посвящённой Docker Compose.

Итоги темы

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

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

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

Изменяемые данные выносятся за пределы слоя записи. Именованный том — объект Docker с собственным жизненным циклом — переживает удаление контейнера и потому позволяет обновлять даже СУБД заменой контейнера; монтирование каталога хоста связывает контейнер с конкретным путём хоста и удобно при разработке; tmpfs даёт временное хранилище в памяти и вместе с --read-only делает неизменяемость технически обеспеченной. Во всех трёх случаях права проверяются по числовым UID, что связывает выбор пользователя в образе (тема 4) с владельцем данных на хосте.

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

Литература

1. Docker Documentation. Running containers. — https://docs.docker.com/engine/containers/run/ (дата обращения: 22.10.2026).
2. Docker Documentation. docker container run. — https://docs.docker.com/reference/cli/docker/container/run/ (дата обращения: 22.10.2026).
3. Docker Documentation. Dockerfile reference. — https://docs.docker.com/reference/dockerfile/ (дата обращения: 22.10.2026).
4. Docker Documentation. Start containers automatically. — https://docs.docker.com/engine/containers/start-containers-automatically/ (дата обращения: 22.10.2026).
5. Docker Documentation. Resource constraints. — https://docs.docker.com/engine/containers/resource_constraints/ (дата обращения: 22.10.2026).
6. signal(7) — Linux manual page. — https://man7.org/linux/man-pages/man7/signal.7.html (дата обращения: 22.10.2026).
7. pid_namespaces(7) — Linux manual page. — https://man7.org/linux/man-pages/man7/pid_namespaces.7.html (дата обращения: 22.10.2026).
8. Docker Documentation. Volumes. — https://docs.docker.com/engine/storage/volumes/ (дата обращения: 22.10.2026).
9. Docker Documentation. Bind mounts. — https://docs.docker.com/engine/storage/bind-mounts/ (дата обращения: 22.10.2026).
10. Docker Documentation. tmpfs mounts. — https://docs.docker.com/engine/storage/tmpfs/ (дата обращения: 22.10.2026).
11. Docker Documentation. JSON File logging driver. — https://docs.docker.com/engine/logging/drivers/json-file/ (дата обращения: 22.10.2026).
12. Rice L. Container Security: Fundamental Technology Concepts that Protect Containerized Applications. — O'Reilly Media, 2020.
13. The Linux Kernel Documentation. Control Group v2. — https://docs.kernel.org/admin-guide/cgroup-v2.html (дата обращения: 22.10.2026).
14. Wiggins A. The Twelve-Factor App. III. Config. — https://12factor.net/config (дата обращения: 22.10.2026).

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

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

1. Что будет запущено, если в образе задан ENTRYPOINT ["python"] и CMD ["app.py"], а контейнер стартует командой docker run образ -V? А если ENTRYPOINT записан в shell-форме?
2. Почему exec-форма CMD не запускает оболочку, а shell-форма запускает, и как это влияет на доставку сигналов?
3. Почему ядро не применяет к PID 1 действие сигнала по умолчанию и какие сигналы, посланные с хоста, всё же доставляются?
4. Как --init решает проблему сигналов и проблему процессов-«зомби»?
5. Что означают коды выхода 0, 1, 125, 127, 137 и 143? Как отличить OOM от docker kill, если код в обоих случаях 137?
6. Во что превращаются ключи --cpus=0.5 и --memory=64m в файлах cgroup v2? Почему без --memory-swap опыт с OOM невоспроизводим?
7. Чем различаются политики on-failure:3, always и unless-stopped после выхода с кодом 0, с кодом 1 и после docker stop?
8. Что делает Docker Engine с контейнером в состоянии unhealthy? Кто использует это состояние?
9. Почему docker stop контейнера с STOPSIGNAL SIGQUIT не посылает SIGTERM? Как задать время ожидания перед SIGKILL?
10. Почему без ротации журнал контейнера может заполнить диск и как это предотвращается?
11. Почему правка файла через docker exec переживает docker restart, но не docker rm?
12. Где лежат данные именованного тома, почему они переживают удаление контейнера и как удалить том?
13. Чем монтирование каталога хоста отличается от тома при подключении к непустому каталогу образа и при отсутствии пути на хосте?
14. Почему права в смонтированном каталоге проверяются по UID, а не по имени пользователя, и как это проявляется при USER 10001?
15. Что даёт --read-only и почему вместе с ним почти всегда нужен --tmpfs?

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

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

# запуск и параметры
docker run -d --name api -e KEY=val -p 127.0.0.1:8080:8000 app:1.0
docker run -d --name api --cpus=0.5 --memory=256m --memory-swap=256m app:1.0
docker run -d --name api --restart=unless-stopped app:1.0
docker run -d --name api --init --stop-timeout 30 app:1.0
docker run -d --name api --read-only --tmpfs /tmp:size=64m app:1.0
docker run -d --name api --log-opt max-size=10m --log-opt max-file=3 app:1.0
docker run --rm --entrypoint sh -it app:1.0      # заменить ENTRYPOINT для отладки
docker update --restart=no --memory=512m --memory-swap=512m api   # изменить параметры на ходу

# остановка
docker stop api            # SIGTERM (или STOPSIGNAL), через 10 с SIGKILL
docker stop -t 30 api      # ждать 30 с
docker kill api            # сразу SIGKILL
docker kill -s HUP api     # послать произвольный сигнал

# инспекция
docker ps -a --format 'table {{.Names}}\t{{.Status}}'
docker logs -f --since 10m --timestamps api
docker inspect --format '{{.State.Status}} {{.State.ExitCode}} {{.State.OOMKilled}} {{.RestartCount}}' api
docker inspect --format '{{range $n, $c := .NetworkSettings.Networks}}{{$n}} {{$c.IPAddress}}{{end}}' api
docker inspect --format '{{json .State.Health}}' api
docker inspect --format '{{json .Mounts}}' api
docker stats --no-stream
docker top api
docker exec api sh -c 'tr "\0" " " < /proc/1/cmdline'

# тома и монтирование
docker volume create data
docker run -d -v data:/var/lib/app app:1.0
docker run -d --mount type=bind,src="$PWD/conf",dst=/etc/app,readonly app:1.0
docker volume ls
docker volume inspect data
docker volume rm data
docker volume prune            # неиспользуемые анонимные тома
docker volume prune --all      # все неиспользуемые тома
docker run --rm -v data:/data:ro -v "$PWD:/backup" python:3.12-slim tar czf /backup/data.tgz -C /data .

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

1. Docker Documentation. Running containers — https://docs.docker.com/engine/containers/run/. Справочник по docker run: точка входа, сигналы, ресурсы, перезапуск, пользователь. Основной источник по параметрам запуска.
2. man7.org. pid_namespaces(7) — https://man7.org/linux/man-pages/man7/pid_namespaces.7.html. Раздел о процессе init пространства имён точно формулирует, какие сигналы ему доставляются; короткий и исчерпывающий ответ на вопрос «почему контейнер не останавливается».
3. man7.org. signal(7) — https://man7.org/linux/man-pages/man7/signal.7.html. Таблица сигналов, их номеров и действий по умолчанию; нужна, чтобы читать коды выхода 128 + N.
4. Репозиторий tini — https://github.com/krallin/tini. README объясняет на примерах, зачем контейнеру программа инициализации и что происходит с «зомби» без неё; именно tini встроен в Docker как docker-init.
5. Docker Documentation. Storage — https://docs.docker.com/engine/storage/ и разделы Volumes, Bind mounts, tmpfs mounts. Полные правила наполнения томов, синтаксис --mount, особенности Docker Desktop.
6. Docker Documentation. Resource constraints — https://docs.docker.com/engine/containers/resource_constraints/. Все ключи ограничения памяти и процессора с точной семантикой --memory-swap и --memory-reservation.
7. The Linux Kernel Documentation. Control Group v2 — https://docs.kernel.org/admin-guide/cgroup-v2.html. Разделы о контроллерах cpu и memory: что такое cpu.max, memory.max, memory.high и события memory.events, из которых Docker узнаёт об OOM.
8. Docker Documentation. Rootless mode — https://docs.docker.com/engine/security/rootless/ и Isolate containers with a user namespace — https://docs.docker.com/engine/security/userns-remap/. Два способа сделать root в контейнере непривилегированным на хосте и их ограничения.
9. Wiggins A. The Twelve-Factor App — https://12factor.net/. Факторы III (конфигурация), VI (процессы), IX (утилизируемость) и XI (журналы) — исходные формулировки принципов, на которых держится эта тема.
10. Rice L. Container Security. — O'Reilly Media, 2020. Главы о пространствах имён, контейнерах от root и монтировании каталогов хоста: почему -v /:/host равносилен доступу к хосту.

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

Почему контейнеру нужна программа инициализации

Помимо сигналов, у PID 1 есть вторая обязанность — собирать «зомби». Когда процесс завершается, ядро хранит его запись в таблице процессов, пока родитель не прочитает код выхода вызовом wait. Если родитель умер раньше, осиротевший процесс передаётся процессу init своего пространства имён, и предполагается, что init вызывает wait за всех. Приложение, ставшее PID 1, об этом не знает: если оно порождает дочерние процессы (например, веб-сервер запускает внешние утилиты, а те — свои подпроцессы), осиротевшие потомки после завершения навсегда остаются «зомби». Каждый занимает идентификатор процесса, и при лимите pids.max в cgroup контейнер со временем перестаёт порождать процессы вовсе. Программы tini и dumb-init решают обе задачи: устанавливают обработчики всех сигналов и пересылают их потомку, а в цикле вызывают wait для любых завершившихся процессов. Kubernetes по умолчанию такую программу не добавляет, поэтому образы, рассчитанные на кластер, часто включают tini прямо в ENTRYPOINT.

Root в контейнере: userns-remap и rootless

По умолчанию UID 0 в контейнере — это UID 0 хоста, и защита держится на отобранных capabilities, профиле seccomp и пространствах имён. Docker умеет и иначе. Режим userns-remap включает пространство имён пользователей: UID 0 контейнера отображается на непривилегированный диапазон UID хоста (например, 100000–165535), и файл, созданный root контейнера в томе, на хосте принадлежит UID 100000. Rootless-режим идёт дальше: от непривилегированного пользователя работает сам демон Docker, сети реализуются в пространстве пользователя, а лимиты cgroup требуют делегирования через systemd. Оба режима заметно снижают ущерб от выхода из контейнера, но меняют поведение томов и монтирования каталогов хоста — владельцы файлов на хосте становятся «чужими» числами — и несовместимы с частью возможностей (например, с --privileged или публикацией портов ниже 1024 без настройки). В Kubernetes поддержка пространств имён пользователей для подов (hostUsers: false) появилась значительно позже, чем в Docker; контекст безопасности пода рассматривается в теме 11.

Лабораторная работа 5. Управление контейнерами в среде выполнения

• Раздел курса: тема 5 «Управление контейнерами в среде выполнения»

Введение

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

Результаты работы готовят к темам 6–8: сетевому взаимодействию и Docker Compose, где параметры запуска фиксируются в файле, и Kubernetes, где те же механизмы — сигналы и время на завершение, коды выхода, OOM, пробы, тома — появляются в виде полей манифеста. На этом этапе важно увидеть контейнер не как «чёрный ящик», а как управляемый объект со своим жизненным циклом.

Работа состоит из базовой и продвинутой частей. Базовая часть (части 1–6) — основа работы: параметры запуска, PID 1 и сигналы, лимиты памяти и политики перезапуска, инспекция и HEALTHCHECK, неизменяемое обновление, тома и монтирование каталогов хоста. Продвинутая часть (часть 7) углублённая и выполняется по желанию: корневая файловая система только для чтения, ротация журналов и время остановки.

Цель работы

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

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

• запускать контейнер с заданными переменными окружения, ограничениями процессора и памяти, политикой перезапуска и пробросом портов и проверять их по docker inspect;
• определять процесс с PID 1 в контейнере и объяснять по времени docker stop и коду выхода, получило ли приложение SIGTERM;
• воспроизводить завершение по OOM (код 137, OOMKilled) и срабатывание политики on-failure:3;
• собирать диагностические сведения штатными средствами: журналы, конфигурация, метрики, состояние HEALTHCHECK;
• обновлять приложение пересозданием контейнера из нового образа и выполнять откат;
• сохранять данные в именованном томе при пересоздании контейнера, подключать каталог хоста и устранять ошибку прав доступа по UID.

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

Теоретический материал раскрыт в теме 5: разделы «Параметры запуска контейнера», «Основной процесс и завершение контейнера», «Инспекция и сопровождение контейнера», «Неизменяемость среды и обновление приложений», «Docker-тома и монтирование каталогов хоста». Ниже — только справочные сведения, нужные по ходу работы.

Сигналы остановки. docker stop посылает основному процессу SIGTERM (или сигнал из STOPSIGNAL) и через тайм-аут, по умолчанию 10 с, — SIGKILL. docker kill посылает SIGKILL немедленно. Ядро не применяет к PID 1 действие сигнала по умолчанию: если PID 1 не установил обработчик SIGTERM, сигнал отбрасывается, и контейнер останавливается только через SIGKILL по тайм-ауту.

Формы инструкции CMD. Exec-форма (CMD ["python", "app.py"]) запускает процесс напрямую — он становится PID 1 и получает сигналы от среды выполнения. Shell-форма (CMD python app.py) запускает процесс через /bin/sh -c. Если оболочка выполняет несколько команд, она остаётся PID 1, не пересылает сигнал дочернему процессу и сама его не получает; если команда одна, оболочка может заменить себя программой через exec, и проблема маскируется.

Коды выхода. 0 — успешное завершение; 1 — ошибка приложения; 137 = 128 + 9 — SIGKILL (OOM, docker kill, тайм-аут docker stop); 143 = 128 + 15 — SIGTERM.

В образе python:3.12-slim нет утилит ps и curl, поэтому процессы внутри контейнера смотрят через /proc, а проверку HEALTHCHECK выполняет Python.

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

• ОС: Ubuntu 24.04 (физическая машина, виртуальная машина или WSL2) с cgroup v2 либо macOS или Windows с Docker Desktop. Проверка версии cgroup — docker info --format '{{.CgroupVersion}}', ожидается 2.
• Docker Engine 27 или новее; проверка готовности — docker version, docker info.
• Образ python:3.12-slim, сетевой доступ к Docker Hub.
• Утилиты curl и time (встроенная команда bash), текстовый редактор.
• Ресурсы: 2 ядра, не менее 2 ГБ свободной оперативной памяти, 1 ГБ свободного места на диске; свободные TCP-порты из своего варианта.

Архив окружения не нужен: все файлы создаются по ходу работы.

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

Все команды выполняются в каталоге ~/lab05 в одном окне терминала. Выберите вариант и задайте переменные — они используются в командах ниже:

mkdir -p ~/lab05 && cd ~/lab05
export APP_PORT=8091 MEM=64m APP_UID=10001 GREETING_VAR="вариант 1"   # значения из своего варианта

Перед каждым экспериментом записывайте в журнал предсказание, после — фактический результат и объяснение. Контейнеры каждой части удаляются в её конце; если команда docker run сообщает о конфликте имени, удалите оставшийся контейнер командой docker rm -f ИМЯ. Сервер в контейнере стартует около секунды, поэтому перед curl в командах стоит sleep 2.

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

Задание

1. В каталоге ~/lab05 создайте файл app.py:

   from http.server import HTTPServer, SimpleHTTPRequestHandler
   import os
   import signal
   import sys
   
   VERSION = "v1"
   port = int(os.environ.get("PORT", 8000))
   greeting = os.environ.get("GREETING", "default")
   
   class Handler(SimpleHTTPRequestHandler):
       def do_GET(self):
           self.send_response(200)
           self.send_header("Content-Type", "text/plain; charset=utf-8")
           self.end_headers()
           self.wfile.write(f"{greeting} ({VERSION}), порт {port}\n".encode())
   
       def log_message(self, format, *args):
           sys.stderr.write("%s - %s\n" % (self.address_string(), format % args))
   
   server = HTTPServer(("0.0.0.0", port), Handler)
   
   def shutdown(signum, frame):
       sys.stderr.write(f"получен сигнал {signum}, завершаюсь корректно\n")
       sys.stderr.flush()
       server.server_close()
       sys.exit(0)
   
   signal.signal(signal.SIGTERM, shutdown)
   signal.signal(signal.SIGINT, shutdown)
   
   sys.stderr.write(f"запуск, PID={os.getpid()}, порт={port}\n")
   sys.stderr.flush()
   server.serve_forever()
   

2. Создайте Dockerfile:

   FROM python:3.12-slim
   
   WORKDIR /app
   
   COPY app.py .
   
   ENV PORT=8000
   ENV GREETING="контейнерное приложение"
   
   EXPOSE 8000
   
   # проверка работоспособности; порт 8000 записан явно — к этому вернёмся в части 4
   HEALTHCHECK --interval=10s --timeout=3s --start-period=5s --retries=3 \
       CMD ["python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/', timeout=2)"]
   
   CMD ["python", "-u", "app.py"]
   

   Обратите внимание на exec-форму CMD и флаг -u интерпретатора Python (вывод без буферизации): они нужны в части 2 для корректной работы с сигналами и журналом.

3. Соберите образ:

   docker build -t lab05-app:v1 .
   

4. Предскажите ответ приложения без ключа -e и с ним: в коде значение по умолчанию default, в Dockerfile — ENV GREETING. Запустите оба варианта:

   docker run -d --name lab05-run0 -p $((APP_PORT+10)):8000 lab05-app:v1
   docker run -d --name lab05-run1 -e GREETING="$GREETING_VAR" -p $APP_PORT:8000 lab05-app:v1
   sleep 2
   curl http://localhost:$((APP_PORT+10))
   curl http://localhost:$APP_PORT
   docker rm -f lab05-run0
   

5. Запустите второй контейнер с ограничениями ресурсов и политикой перезапуска и проверьте сохранённые параметры:

   docker run -d --name lab05-run2 \
       --cpus=0.5 \
       --memory=$MEM \
       --restart=on-failure:3 \
       -p $((APP_PORT+1)):8000 \
       lab05-app:v1
   
   docker inspect lab05-run2 \
       --format '{{.HostConfig.NanoCpus}} {{.HostConfig.Memory}} {{.HostConfig.RestartPolicy}}'
   docker exec lab05-run2 cat /sys/fs/cgroup/cpu.max /sys/fs/cgroup/memory.max
   

   Поясните, как полученные значения соотносятся с ключами --cpus, --memory, --restart.

6. Оставьте контейнер lab05-run1 запущенным до части 2; контейнер lab05-run2 удалите: docker rm -f lab05-run2.

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

Ответы приложения (для варианта 1):

контейнерное приложение (v1), порт 8000
вариант 1 (v1), порт 8000

Значение default из кода не появляется ни разу: ENV GREETING в Dockerfile уже задаёт переменную, а ключ -e перекрывает значение из образа. Порядок приоритетов: -e при запуске, затем ENV образа, затем значение по умолчанию в коде.

Для варианта 1 docker inspect и cgroup показывают:

500000000 67108864 {on-failure 3}
50000 100000
67108864

NanoCpus — доли ядра в миллиардных (0,5 × 10⁹), Memory — байты (64 × 1 048 576), cpu.max — квота 50 000 мкс на период 100 000 мкс.

Часть 2. PID 1 и обработка сигналов

Задание

1. Определите процесс с PID 1 в работающем контейнере — снаружи и изнутри:

   docker top lab05-run1
   docker exec lab05-run1 sh -c 'tr "\0" " " < /proc/1/cmdline; echo'
   docker exec lab05-run1 sh -c 'for p in /proc/[0-9]*; do printf "%s\t%s\n" "${p#/proc/}" "$(tr "\0" " " < $p/cmdline)"; done'
   

   Последняя команда — замена ps в образе без procps: она перебирает каталоги /proc/<PID>. Зафиксируйте PID процесса на хосте (docker top) и внутри контейнера.

2. Выполните корректную остановку с измерением времени:

   time docker stop lab05-run1
   docker logs lab05-run1 2>&1 | tail -3
   docker inspect --format '{{.State.ExitCode}}' lab05-run1
   

3. Пересоздайте контейнер с запуском через оболочку. Команда ; echo done нужна, чтобы оболочка не могла заменить себя Python через exec и гарантированно осталась PID 1:

   docker rm lab05-run1
   docker run -d --name lab05-shell \
       -p $APP_PORT:8000 \
       --entrypoint sh \
       lab05-app:v1 \
       -c "python -u app.py; echo done"
   sleep 2
   

4. Предскажите время остановки и код выхода. Проверьте PID 1 и остановите контейнер:

   docker exec lab05-shell sh -c 'tr "\0" " " < /proc/1/cmdline; echo'
   time docker stop lab05-shell
   docker logs lab05-shell 2>&1 | tail -3
   docker inspect --format '{{.State.ExitCode}}' lab05-shell
   

   Объясните, почему не сработал обработчик SIGTERM в Python и почему не завершилась сама оболочка.

5. Повторите шаги 3–4 с командой -c "python -u app.py" (без ; echo done), предварительно удалив контейнер. Если PID 1 окажется python, а не sh, объясните, что сделала оболочка.

6. Сравните с процессом без обработчика сигналов — с ключом --init и без него:

   docker run -d --name lab05-sleep python:3.12-slim python -c "import time; time.sleep(600)"
   docker run -d --init --name lab05-sleep-init python:3.12-slim python -c "import time; time.sleep(600)"
   sleep 1
   docker exec lab05-sleep-init sh -c 'tr "\0" " " < /proc/1/cmdline; echo'
   time docker stop lab05-sleep
   time docker stop lab05-sleep-init
   docker inspect --format '{{.Name}} {{.State.ExitCode}}' lab05-sleep lab05-sleep-init
   

7. Выполните принудительное завершение:

   docker run -d --name lab05-kill -p $((APP_PORT+2)):8000 lab05-app:v1
   sleep 2
   time docker kill lab05-kill
   docker logs lab05-kill 2>&1 | tail -3
   docker inspect --format '{{.State.ExitCode}}' lab05-kill
   

8. Удалите контейнеры части: docker rm -f lab05-shell lab05-sleep lab05-sleep-init lab05-kill.

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

Сводная таблица (время — порядок величины):

В первом случае журнал заканчивается строкой получен сигнал 15, завершаюсь корректно. Во втором SIGTERM получила оболочка, у которой нет обработчика, а для PID 1 ядро сигнал без обработчика отбрасывает; Python сигнала не получил вовсе, и через 10 с оба процесса убиты SIGKILL. Строки done в журнале тоже нет: оболочка убита, не дойдя до неё. В опыте шага 5 результат зависит от версии dash в образе: если PID 1 — python, оболочка выполнила последнюю команду через exec, и остановка проходит корректно. Внутри контейнера PID приложения равен 1, а docker top показывает другой номер — PID того же процесса в пространстве имён хоста.

Часть 3. Лимиты памяти, OOM и политики перезапуска

Задание

1. Предскажите код выхода и содержимое журнала. Запустите процесс, которому нужно 200 МБ, с лимитом памяти из варианта и запретом подкачки:

   docker run --name lab05-oom --memory=$MEM --memory-swap=$MEM lab05-app:v1 \
       python -c "b = bytearray(200 * 1024 * 1024); print('выделено')"
   echo "код выхода: $?"
   docker inspect --format '{{.State.ExitCode}} {{.State.OOMKilled}}' lab05-oom
   docker logs lab05-oom
   

2. Повторите опыт без --memory-swap (контейнер lab05-oom2) и объясните результат с учётом наличия подкачки на хосте (free -h, строка Swap). Удалите оба контейнера.

3. Запустите контейнер, который завершается с ошибкой сразу после старта, с политикой on-failure:3:

   docker run -d --name lab05-crash --restart=on-failure:3 lab05-app:v1 \
       python -c "import sys; print('старт'); sys.exit(1)"
   sleep 5
   docker inspect --format '{{.RestartCount}} {{.State.Status}} {{.State.ExitCode}}' lab05-crash
   docker logs lab05-crash
   

4. Сравните с политикой always для процесса, завершающегося успешно:

   docker run -d --name lab05-always --restart=always lab05-app:v1 python -c "print('ok')"
   sleep 5
   docker inspect --format '{{.RestartCount}} {{.State.Status}}' lab05-always
   docker stop lab05-always
   docker inspect --format '{{.RestartCount}} {{.State.Status}}' lab05-always
   

   Объясните, почему RestartCount у always растёт, хотя код выхода 0, и почему контейнер не перезапустился после docker stop.

5. Удалите контейнеры: docker rm -f lab05-crash lab05-always.

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

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

код выхода: 137
137 true

Журнал пуст: строка выделено не напечатана, приложение не успело ничего записать. Без --memory-swap на хосте с подкачкой процесс может выжить (Docker разрешает столько же подкачки, сколько памяти) и напечатать выделено, если 200 МБ укладываются в удвоенный лимит; при MEM=64m этого не хватает, и результат снова 137. Такой опыт невоспроизводим, поэтому в эксплуатации --memory-swap задают явно.

Политика on-failure:3:

3 exited 1
старт
старт
старт
старт

Четыре строки — первый запуск и три перезапуска; после исчерпания попыток контейнер остаётся в состоянии exited. У always счётчик за 5 с успевает вырасти до нескольких единиц (задержка между перезапусками удваивается от 100 мс), а после docker stop состояние exited и счётчик больше не меняется: явная остановка отменяет перезапуск при любой политике.

Часть 4. Инспекция и диагностика работающего контейнера

Задание

1. Запустите контейнер для этой части:

   docker run -d --name lab05-diag \
       -e GREETING="диагностика" \
       --memory=$MEM \
       -p $APP_PORT:8000 \
       lab05-app:v1
   

2. Сразу и через 15 с посмотрите состояние HEALTHCHECK:

   docker ps --filter name=lab05-diag --format '{{.Names}}\t{{.Status}}'
   sleep 15
   docker ps --filter name=lab05-diag --format '{{.Names}}\t{{.Status}}'
   docker inspect --format '{{.State.Health.Status}} {{.State.Health.FailingStreak}}' lab05-diag
   

3. Сгенерируйте нагрузку запросами и изучите журнал двумя способами:

   for i in $(seq 1 20); do curl -s http://localhost:$APP_PORT > /dev/null; done
   docker logs lab05-diag 2>&1 | tail -5
   docker logs --tail 5 --timestamps lab05-diag
   docker logs lab05-diag 2>/dev/null | wc -l
   

   Зафиксируйте, в какой поток (stdout или stderr) пишет приложение — это видно по последней команде, — откуда в журнале запросы с адреса 127.0.0.1 и какую информацию даёт флаг --timestamps.

4. Снимите конфигурацию и состояние контейнера. IP-адрес хранится по сетям, поэтому извлекается перебором range:

   docker inspect lab05-diag \
       --format '{{.State.Status}} {{.State.Pid}} {{range $n, $c := .NetworkSettings.Networks}}{{$n}}={{$c.IPAddress}}{{end}}'
   docker inspect lab05-diag --format '{{json .Config.Env}}' | python3 -m json.tool
   

5. Получите снимок потребления ресурсов и сопоставьте LIMIT с переданным --memory:

   docker stats --no-stream lab05-diag
   

6. Осмотрите файловую систему контейнера:

   docker exec lab05-diag sh -c "ls /app && head -3 /etc/os-release"
   

7. Найдите ошибку. Запустите тот же образ на другом порту приложения и через 40 с проверьте состояние:

   docker run -d --name lab05-port -e PORT=9000 -p $((APP_PORT+3)):9000 lab05-app:v1
   sleep 2
   curl http://localhost:$((APP_PORT+3))
   sleep 40
   docker ps --filter name=lab05-port --format '{{.Names}}\t{{.Status}}'
   docker inspect --format '{{json .State.Health.Log}}' lab05-port | python3 -m json.tool | tail -8
   

   Приложение отвечает, но контейнер помечен как нездоровый. Найдите причину в Dockerfile и предложите исправление, при котором проверка следует за переменной PORT.

8. Удалите контейнеры: docker rm -f lab05-diag lab05-port.

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

Сразу после старта статус Up 1 second (health: starting), через 15 с — Up 16 seconds (healthy), healthy 0. Все строки журнала приложения идут в stderr (docker logs ... 2>/dev/null | wc -l даёт 0), среди них есть запросы проверки 127.0.0.1 - "GET / HTTP/1.1" 200 -, выполняемые каждые 10 с. Инспекция:

running 52731 bridge=172.17.0.2
[
    "GREETING=диагностика",
    "PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
    ...
    "PORT=8000"
]

docker stats выводит строку вида:

CONTAINER ID   NAME         CPU %     MEM USAGE / LIMIT   MEM %     NET I/O           BLOCK I/O   PIDS
3b1f0c2d9e4a   lab05-diag   0.01%     17.9MiB / 64MiB     27.97%    12.1kB / 9.8kB    0B / 0B     1

LIMIT равен лимиту варианта; без --memory там был бы объём памяти хоста. ls /app показывает app.py, /etc/os-release — Debian. В шаге 7 приложение слушает порт 9000 и отвечает через опубликованный порт, а проверка обращается к порту 8000, где никто не слушает: после трёх неудач подряд статус становится (unhealthy), а в журнале проверок видно Connection refused. Исправление — читать порт в проверке из той же переменной окружения, например вынести проверку в файл healthcheck.py, использующий os.environ.get("PORT", "8000"), и указать HEALTHCHECK CMD ["python", "/app/healthcheck.py"]. Сам Docker на unhealthy не реагирует: контейнер продолжает работать.

Часть 5. Неизменяемое обновление приложения

Задание

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

   docker run -d --name lab05-prod -p $APP_PORT:8000 lab05-app:v1
   sleep 2
   curl http://localhost:$APP_PORT
   

2. Примените антипаттерн — измените файл прямо внутри работающего контейнера:

   docker exec lab05-prod sed -i 's/VERSION = "v1"/VERSION = "v1-hotfix"/' /app/app.py
   docker exec lab05-prod grep VERSION /app/app.py
   curl http://localhost:$APP_PORT
   

   Объясните, почему ответ не изменился, хотя файл изменён.

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

   docker restart lab05-prod
   sleep 2
   curl http://localhost:$APP_PORT
   docker rm -f lab05-prod
   docker run --rm lab05-app:v1 grep VERSION /app/app.py
   

   Объясните, почему правка пережила docker restart, но не пережила docker rm.

4. Выполните корректное обновление через пересборку. Замените в app.py строку VERSION = "v1" на VERSION = "v2" и соберите новый образ:

   sed -i 's/VERSION = "v1"/VERSION = "v2"/' app.py
   docker build -t lab05-app:v2 .
   docker image ls lab05-app --format 'table {{.Repository}}:{{.Tag}}\t{{.ID}}\t{{.Size}}'
   

5. Выполните управляемое обновление — запустите новый контейнер из обновлённого образа:

   docker run -d --name lab05-prod -p $APP_PORT:8000 lab05-app:v2
   sleep 2
   curl http://localhost:$APP_PORT
   

6. Выполните откат к предыдущей версии:

   docker rm -f lab05-prod
   docker run -d --name lab05-prod-rollback -p $APP_PORT:8000 lab05-app:v1
   sleep 2
   curl http://localhost:$APP_PORT
   docker rm -f lab05-prod-rollback
   

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

Последовательность ответов:

контейнерное приложение (v1), порт 8000          # шаг 1
контейнерное приложение (v1), порт 8000          # шаг 2: файл изменён, процесс — нет
контейнерное приложение (v1-hotfix), порт 8000   # шаг 3: после docker restart
VERSION = "v1"                                   # шаг 3: образ не изменился
контейнерное приложение (v2), порт 8000          # шаг 5
контейнерное приложение (v1), порт 8000          # шаг 6: откат

Python прочитал app.py один раз при запуске, поэтому правка файла не меняет работающий процесс. docker restart перезапускает процесс в том же контейнере, слой записи которого сохранился вместе с правкой, — так «быстрое исправление» становится незаметной частью конкретного контейнера. docker rm удаляет слой записи, и правка исчезает; образ v1 не менялся. Обновление и откат сводятся к запуску контейнера из нужного тега.

Часть 6. Тома и монтирование каталогов хоста

Задание

1. Создайте именованный том и дважды запустите одноразовые контейнеры, которые дописывают строку в файл тома. Предскажите число строк после второго запуска, учитывая, что контейнеры удаляются (--rm):

   docker volume create lab05-data
   docker run --rm -v lab05-data:/data lab05-app:v1 sh -c 'date >> /data/visits.log; wc -l < /data/visits.log'
   docker run --rm -v lab05-data:/data lab05-app:v1 sh -c 'date >> /data/visits.log; wc -l < /data/visits.log'
   docker volume inspect --format '{{.Mountpoint}} {{.Driver}}' lab05-data
   

   На Linux содержимое тома можно увидеть на хосте: sudo cat /var/lib/docker/volumes/lab05-data/_data/visits.log. В Docker Desktop каталог находится внутри служебной ВМ и с хоста не виден.

2. Сравните с анонимным томом:

   docker run --name lab05-anon -v /data lab05-app:v1 sh -c 'echo test > /data/x'
   docker volume ls
   docker rm -v lab05-anon
   docker volume ls
   

3. Подключите каталог хоста только для чтения:

   mkdir -p conf && echo "из каталога хоста" > conf/greeting.txt
   docker run --rm -v "$PWD/conf:/conf:ro" lab05-app:v1 cat /conf/greeting.txt
   docker run --rm -v "$PWD/conf:/conf:ro" lab05-app:v1 sh -c 'echo x > /conf/new.txt'
   

4. Предскажите результат и проверьте: что произойдёт, если смонтировать каталог conf поверх /app?

   docker run --rm -v "$PWD/conf:/app" lab05-app:v1
   echo "код выхода: $?"
   

5. Сломайте и почините. Запустите контейнер от пользователя с UID из варианта и попробуйте записать в каталог хоста:

   mkdir -p data
   ls -ln -d data
   docker run --rm --user $APP_UID -v "$PWD/data:/data" lab05-app:v1 sh -c 'echo test > /data/x && echo записано'
   

   Найдите причину по выводу ls -ln и исправьте запуск так, чтобы запись прошла, не меняя права каталога на 777. Проверьте владельца созданного файла командой ls -ln data.

6. Выполните ту же запись от UID варианта в именованный том lab05-data и объясните результат.

7. Очистка: docker volume rm lab05-data, rm -rf conf data.

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

Два запуска печатают 1 и 2: том пережил удаление обоих контейнеров. docker volume inspect выводит /var/lib/docker/volumes/lab05-data/_data local. Анонимный том появляется в docker volume ls с именем из 64 шестнадцатеричных символов и исчезает после docker rm -v.

Каталог хоста читается (из каталога хоста), а запись завершается ошибкой sh: 1: cannot create /conf/new.txt: Read-only file system. Монтирование поверх /app закрывает файлы образа:

python: can't open file '/app/app.py': [Errno 2] No such file or directory
код выхода: 2

В шаге 5 каталог data принадлежит UID пользователя хоста (обычно 1000) с правами drwxr-xr-x, а процесс работает с UID 10001, поэтому запись запрещена:

sh: 1: cannot create /data/x: Permission denied

Исправление для разработки — запуск с --user "$(id -u):$(id -g)": файл создаётся, и ls -ln data показывает владельцем ваш UID. Для эксплуатации — передать каталог во владение UID приложения (sudo chown $APP_UID data). В шаге 6 запись в том тоже запрещена: корень нового тома принадлежит root. Исправляют это в образе — создают каталог точки монтирования с владельцем $APP_UID, тогда Docker при первом подключении пустого тома скопирует владельца. На macOS с Docker Desktop механизм общего доступа к файлам подменяет владельцев, и ошибка шага 5 может не воспроизвестись.

Часть 7. Продвинутая: файловая система только для чтения, журналы и время остановки

Задание

1. Запустите приложение с корневой файловой системой только для чтения и проверьте, что оно работает, а запись запрещена везде, кроме tmpfs:

   docker run -d --name lab05-ro --read-only --tmpfs /tmp:size=8m -p $APP_PORT:8000 lab05-app:v1
   sleep 2
   curl http://localhost:$APP_PORT
   docker exec lab05-ro sh -c 'echo x > /app/x' ; docker exec lab05-ro sh -c 'echo x > /tmp/x && df -h /tmp'
   docker rm -f lab05-ro
   

2. Ограничьте журнал контейнера и наполните его запросами:

   docker run -d --name lab05-logs --log-opt max-size=1k --log-opt max-file=2 -p $APP_PORT:8000 lab05-app:v1
   sleep 2
   for i in $(seq 1 100); do curl -s http://localhost:$APP_PORT > /dev/null; done
   docker logs lab05-logs 2>&1 | wc -l
   docker inspect --format '{{.LogPath}}' lab05-logs
   

   На Linux посмотрите файлы журнала: sudo ls -l "$(dirname "$(docker inspect --format '{{.LogPath}}' lab05-logs)")". Объясните, почему docker logs выдаёт меньше 100 строк запросов.

3. Задайте время ожидания остановки для контейнера, который не реагирует на SIGTERM:

   docker run -d --name lab05-st --stop-timeout 2 --entrypoint sh lab05-app:v1 -c "python -u app.py; echo done"
   sleep 1
   time docker stop lab05-st
   docker rm -f lab05-logs lab05-st
   

4. Итоговая очистка: docker image rm lab05-app:v1 lab05-app:v2.

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

Приложение в режиме --read-only отвечает как обычно (оно ничего не пишет на диск), запись в /app даёт Read-only file system, запись в /tmp проходит, а df показывает tmpfs размером 8,0 МБ. При max-size=1k и max-file=2 журнал занимает не более двух файлов по 1 КиБ (<id>-json.log и <id>-json.log.1), и docker logs возвращает лишь последние десятки строк. Остановка контейнера с оболочкой в роли PID 1 занимает около 2 с вместо 10: тайм-аут перед SIGKILL взят из --stop-timeout.

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

Ведите журнал для себя: для каждого эксперимента записывайте предсказание, команду, фактический вывод (ключевые строки) и объяснение расхождения. Удобно собрать таблицу из части 2 (PID 1, время остановки, код выхода), пары «до — после» из части 5 и ответы на вопросы «почему» из частей 3 и 6. Записи о кодах 137 и 143, OOMKilled и RestartCount понадобятся в теме 7, где те же явления видны в kubectl describe pod.

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

1. В части 1 значение default из кода не появилось ни разу. В каком порядке применяются значение по умолчанию в коде, ENV в Dockerfile и -e при запуске?
2. Что происходит, если контейнер запущен с ограничением --memory=64m, а приложение пытается выделить 200 МБ? Почему результат может зависеть от --memory-swap и от наличия подкачки на хосте, и как по docker inspect отличить OOM от docker kill?
3. Почему процесс с PID 1 в контейнере не завершается по SIGTERM, если не установил обработчик, хотя тот же процесс вне контейнера завершился бы?
4. Почему sh -c "python app.py; echo done" гарантированно оставляет оболочку в роли PID 1, а sh -c "python app.py" — не всегда? Как правильно завершать сценарий-обёртку?
5. Что делает ключ --init и почему с ним процесс без обработчика SIGTERM завершается с кодом 143, а без него — с кодом 137?
6. Сколько раз будет запущен процесс при политике on-failure:3, если он всегда завершается с кодом 1? Что изменится при коде 0 и при политике always?
7. Почему в части 4 контейнер оказался unhealthy, хотя приложение отвечало, и что Docker Engine делает с нездоровым контейнером?
8. Какие задачи диагностики решаются с помощью docker logs, docker inspect и docker stats? Приведите по одному эксплуатационному сценарию для каждого инструмента.
9. Почему правка внутри контейнера пережила docker restart, но не docker rm? Почему это делает ручную правку опаснее, а не безопаснее?
10. Почему данные в именованном томе переживают удаление контейнера, а данные в слое записи — нет? Где на хосте находятся данные тома?
11. Почему запись от --user 10001 в каталог хоста, принадлежащий пользователю с UID 1000, запрещена? Какие есть способы исправления и почему не стоит ставить права 777?
12. Чем монтирование каталога хоста отличается от именованного тома при подключении к непустому каталогу образа?