Политики перезапуска Docker: руководство

Инфографика о политиках перезапуска контейнеров Docker

Docker предоставляет четыре политики перезапуска контейнеров: no, always, on-failure и unless-stopped. Выбирайте политику по поведению при ошибках и перезагрузке хоста. Для большинства production-сценок подходят always или unless-stopped; on-failure позволяет ограничить число попыток. В статье — примеры команд, сценарии отказов, дерево принятия решений, плейбук восстановления и частые вопросы.

Быстрые ссылки

Доступные политики
Применение политики перезапуска
Циклы перезапуска
Ограничение числа повторных попыток
Расследование причин остановки контейнеров
Резюме

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

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

Доступные политики

В настоящее время доступны четыре политики перезапуска:

no — политика, которая никогда не запускает контейнер автоматически. Это поведение по умолчанию для всех контейнеров, созданных через docker run.
always — Docker будет поддерживать контейнер постоянно запущенным. Если контейнер останавливается, он будет немедленно перезапущен. Вы всё ещё можете вручную остановить контейнер через docker stop, но Docker поднимет его снова при следующем старте демона.
on-failure — контейнер будет перезапущен, если он завершился с ошибкой (ненулевой код выхода). Docker не будет автоматически поднимать контейнер после перезапуска демона, если только сам демон не инициировал рестарт согласно этой политике.
unless-stopped — работает аналогично always, но Docker никогда не будет перезапускать контейнер, если он был вручную остановлен пользователем.

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

Принятие решения о политике может быть непростым. always часто кажется естественным выбором, но поведение при рестарте демона может быть упущено из виду. Если вы хотите, чтобы контейнеры надёжно оставались остановленными после выполнения docker stop, используйте unless-stopped.

Docker определяет ошибку по коду выхода основного процесса контейнера. Код выхода 0 считается успешным выполнением, код 1 и выше интерпретируется как ошибка — это соответствует стандартной Unix-практике.

Когда Docker перезапускает контейнер, это эквивалентно повторному запуску docker run. Это означает, что будет вызван скрипт ENTRYPOINT образа. Скрипты и системы инициализации должны быть устойчивы к многократным вызовам.

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

Запустить контейнер с конкретной политикой перезапуска можно с флагом --restart при docker run:

docker run --name httpd --restart always httpd:latest

Если вы используете Docker Compose, добавьте поле restart в docker-compose.yml:

services:
  httpd:
    image: httpd:latest
    restart: always

Политику перезапуска существующего контейнера можно изменить с помощью docker update. Передайте команде имя контейнера. Имена контейнеров можно найти через docker ps -a.

docker update --restart-policy unless-stopped httpd

docker update можно применять к контейнерам как в рабочем, так и в остановленном состоянии.

Циклы перезапуска

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

Второй важный момент — команда docker stop. Docker уважает явное использование docker stop, поэтому контейнер не будет немедленно перезапущен после выполнения этой команды. Если вы действительно хотите перезапустить контейнер, используйте docker restart.

Важно: такие защитные механизмы не снимают ответственности за корректную обработку ошибок в приложении. Нужно предусмотреть логирование, экшены повторной инициализации и защиту от race conditions при многократных вызовах ENTRYPOINT.

Ограничение числа повторных попыток

Политика on-failure позволяет указать, сколько попыток перезапуска следует предпринять. Docker откажется и оставит контейнер в остановленном состоянии, если он несколько раз подряд не может успешно запуститься.

docker run httpd:latest --restart on-failure:5

В этом примере Docker попытается перезапустить контейнер пять раз после ошибки (ненулевой код выхода). Если контейнер не удастся запустить на пятой попытке, дальнейших попыток не будет. Это полезно для контейнеров, где постоянная ошибка старта вряд ли решится без вмешательства оператора.

Расследование причин остановки контейнеров

Чтобы узнать, почему контейнер остановился, выполните docker ps -a. Команда покажет все контейнеры, как остановленные, так и запущенные. Найдите нужный контейнер и посмотрите столбец “Status”; для остановленных контейнеров в скобках будет указан код выхода. Если код больше нуля, контейнер завершился из-за ошибки.

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

docker logs my-container

Поток логов агрегирует stdout и stderr контейнера. Если ошибка туда попала, вы увидите её в последних строках вывода.

Когда политики перезапуска не помогают

Если основной процесс внутри контейнера сразу падает с аппаратной или системной ошибкой (например, отсутствует бинарник), автоматические перезапуски просто расходуют ресурсы и не исправляют проблему.
При логических ошибках в init-скриптах множественные перезапуски могут усугубить состояние (например, повторное создание неизменяемых ресурсов).
Для кратковременных batch-задач политика always и unless-stopped не подходят — такие задачи должны завершаться и фиксироваться внешними планировщиками.

В этих случаях лучше комбинировать политики с мониторингом, alerting и механиками автоматического отката/блокировки.

Критерии приёмки

Контейнер с политикой always восстанавливается автоматически после краша и после перезапуска демона.
Контейнер с unless-stopped не поднимается после ручного docker stop даже при перезапуске демона.
on-failure:N делает не более N попыток перезапуска при последовательных ошибках старта.
Логи доступны после остановки контейнера и содержат записи об ошибке.

Плейбук: быстрое восстановление сервиса

Шаги для инженера SRE/DevOps при падении сервиса:

Проверить статус контейнера

docker ps -a | grep

Посмотреть последние 200 строк логов

docker logs --tail 200

Если это transient-ошибка, вручную перезапустить и наблюдать

docker restart

Если контейнер зациклен на перезапусках, временно изменить политику на no и зафиксировать проблему

docker update --restart-policy no

Если требуется откат образа, запустить предыдущую стабильную версию и задать корректную политику

docker run --name  --restart unless-stopped :

После устранения причины восстановить желаемую политику и задокументировать RCA.

Important: перед изменением политики убедитесь, что мониторинг и алерты настроены, чтобы избежать скрытых падений.

Дерево принятия решений (Mermaid)

flowchart TD
  A[Начало: контейнер падает] --> B{Контейнер должен оставаться остановленным после docker stop?}
  B -- Да --> C[Выбрать unless-stopped]
  B -- Нет --> D{Нужна автоматическая рестарт после каждого падения?}
  D -- Да --> E[Выбрать always]
  D -- Нет --> F{Перезапуски только при ошибках процесса?}
  F -- Да --> G[Выбрать on-failure и указать лимит]
  F -- Нет --> H[Выбрать no]
  C --> I[Настроить мониторинг и логи]
  E --> I
  G --> I
  H --> I

Чек-листы по ролям

Для инженера DevOps:

Проверить и задокументировать требуемое поведение при рестарте демона.
Настроить правильную политику (always/unless-stopped/on-failure/no).
Убедиться в наличии логирования и метрик контейнера.

Для разработчика приложения:

Сделать ENTRYPOINT идемпотентным.
Обеспечить понятные коды выхода и подробное логирование ошибок.

Для SRE/оператора:

Настроить алерты на частые рестарты.
Подготовить playbook восстановления и rollback-процедуры.

Факты и полезные числа

Минимальное время работы контейнера перед началом мониторинга рестартов: 10 секунд.
Код выхода 0 = успех; код >= 1 = ошибка (Unix-поведение).
on-failure:N ограничивает количество попыток рестарта до N.

Альтернативные подходы

Использовать оркестраторы (Kubernetes, Docker Swarm) для сложных сценариев управления жизненным циклом и самовосстановления с продвинутыми стратегиями (readiness/liveness probes, backoff-политики).
Для batch-обработок использовать планировщик заданий (cron, Airflow) вместо политики always.

Best practices

Для сервисов, критичных к доступности, используйте unless-stopped и обеспечьте наблюдаемость.
Не полагайтесь исключительно на политику перезапуска: логируйте причину падения и настраивайте алерты.
Делайте ENTRYPOINT устойчивым к повторным вызовам.

Часто задаваемые вопросы

Нужно ли менять политику перед деплоем на production?

Да — проверьте, что политика соответствует модели эксплуатации: долгоживущие сервисы обычно always/unless-stopped, кратковременные задачи — no.

Как увидеть, сколько раз контейнер перезапускался?

Команда docker ps показывает счётчик рестартов в колонке “NAMES”/“RESTARTS” (в зависимости от версии клиента) и в статусе контейнера.

Полезны ли restart-политики в Kubernetes?

Kubernetes имеет свои механизмы управления перезапусками (restartPolicy, probes). В оркестраторе чаще используют собственные стратегии, а не Docker restart-политику.

Резюме

Политики перезапуска Docker помогают обеспечить доступность контейнеризированных сервисов и управлять поведением после крашей и перезагрузок хоста. Выбор между always, unless-stopped, on-failure и no зависит от характера приложения: сервис или одноразовая задача. Комбинируйте политики с логированием, мониторингом и playbook’ами восстановления.

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