Процесс, настройки и ресурсы контейнера

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

Главный процесс

Контейнер работает, пока работает его главный процесс. В обычном отдельном пространстве процессов у него номер PID 1. Дополнительная команда docker exec выполняется рядом с ним; завершение этой команды не останавливает основную программу.

-d отсоединяет терминал пользователя. Сам сервер внутри должен продолжать работать на переднем плане. Например, CMD ["python", "server.py"] запускает Python напрямую. Если оболочка отправит сервер в фон через & и сама завершится, контейнер может закончить работу вместе с ней.

Настройка для одного запуска

Переменная окружения — именованная строка, которую программа читает при работе. Например, один и тот же загрузчик обрабатывает разные даты:

docker run --rm -e BATCH_DATE=2026-10-08 alpine:3.21 printenv BATCH_DATE

Команда выведет 2026-10-08. Значение передано этому запуску; исходный образ остался прежним. В реальном Docker несколько настроек можно хранить в файле строками ИМЯ=значение и передать через --env-file.

Для просмотра настроек длительного процесса подходит inspect:

docker run -d --name demo-batch -e BATCH_DATE=2026-10-08 alpine:3.21 sleep 3600
docker inspect demo-batch

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

Лимиты памяти и CPU

docker run -d --name demo-worker --memory 256000000 --cpus 0.5 alpine:3.21 sleep 3600
docker inspect demo-worker

Здесь лимит памяти указан в байтах: 256000000, то есть 256 MB. --cpus 0.5 ограничивает процессорное время половиной одного CPU, а не закрепляет программу за «половиной ядра». Реальное потребление работающих контейнеров показывает docker stats на компьютере.

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

Даём программе завершиться

Обычно docker stop отправляет сигнал SIGTERM, просьбу завершить работу. Программа может обработать его: перестать принимать новые задачи, дописать результат, закрыть соединение. Если за отведённое время процесс не завершился, Docker отправляет SIGKILL, принудительную остановку.

docker stop demo-worker
docker inspect -f '{{.State.ExitCode}}' demo-worker
docker inspect -f '{{.State.OOMKilled}}' demo-worker

Код выхода зависит от программы и способа завершения. Код 137 соответствует SIGKILL; поле OOMKilled помогает отличить нехватку памяти от других причин принудительного завершения. Успешность обработки данных дополнительно проверяют по самому результату: повтор после прерванной записи должен учитывать уже сохранённую часть.

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

Попробуйте в учебном терминале

Запустите процесс с точными лимитами, передайте дату другому экземпляру и остановите подготовленный stoppable. Проверяются настройки и состояние. Песочница не измеряет настоящий CPU/RAM и не моделирует работу ядра при нехватке памяти.

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