Що таке restart policy і які варіанти існують?

docs.questions.sections.docker~4 хв читання

Docker restart policy автоматизує resilience container. Crash? Daemon рестартує. Host reboot? Container повертається. Чотири опції trade-off контроль vs автоматизація по-різному, обирай за тим, що хочеш, щоб container переживав.

Теорія

TL;DR

--restart=<policy> на docker run (або restart: <policy> у Compose) ставить політику.
Чотири значення: no, on-failure[:N], always, unless-stopped.
Прод-дефолт: unless-stopped, переживає crash і host reboot, поважає ручний stop.
Дефолт, якщо не вказано: no, container виходить і лишається exited.
Restart-policy спрацьовує на exit container, незалежно від того, чи exit чистий (0) чи ні. Фільтр по коду це те, що додає on-failure.

Чотири політики

Політика	На exit (будь-який код)	На exit код 0	Після host-reboot	Поважає ручний stop
`no` (дефолт)	ні	ні	ні	n/a
`on-failure[:N]`	так, якщо код != 0, до N разів	ні	ні (не переживає reboot)	так
`always`	так	так	так	ні (рестартує навіть після stop)
`unless-stopped`	так	так	так (якщо було running)	так

`no` — дефолт

bash

docker run myapp
# Crash → exited. Лишається exited.
# Host reboot → container не повертається.

Нормально для одноразових команд (docker run --rm для CI-job). Неправильно для будь-якого сервісу, що має крутитися.

`on-failure[:N]` — рестарт на crash до N разів

bash

docker run --restart=on-failure myjob       # необмежено retry на non-zero exit
docker run --restart=on-failure:5 myjob     # макс 5 retry

Бери для batch-job, що мають retry на transient failure, але врешті здаватися. Host-reboot їх не повертає (вони job, не service).

`always` — рестарт незважаючи ні на що

bash

docker run --restart=always mysvc
# Crash, чистий exit, host reboot → daemon його повертає кожного разу.
# Навіть після `docker stop` daemon його рестартує.

Назва буквальна: ЗАВЖДИ. Включно після ручного stop, щоб реально зупинити, маєш зробити docker rm. Дивує; зазвичай хочеш unless-stopped.

`unless-stopped` — прод-дефолт

bash

docker run --restart=unless-stopped mysvc
# Crash → restart. Host reboot → restart. Ручний `docker stop` → ЛИШАЄТЬСЯ зупинений.

Правильна політика для 95% довгоживучих сервісів. Daemon рестартує на failure або reboot; поважає твій намір, коли ти зупиняєш вручну.

Як взаємодіє з daemon

На exit container: daemon перевіряє політику і вирішує, чи рестартувати.
На рестарт daemon (systemctl restart docker): container з always і unless-stopped (що були running до рестарту) повертаються. on-failure НІ, він per-exit only.
На host reboot: те саме, що рестарт daemon.
Daemon використовує експоненційний backoff між retry: 100мс, 200мс, 400мс, ... до cap. Запобігає hot-loop crash-шторму.

Compose-синтаксис

yaml

services:
  api:
    image: myapp
    restart: unless-stopped       # найпоширеніше
  worker:
    image: myworker
    restart: on-failure            # job-style
  oneoff:
    image: alpine
    command: echo hi
    restart: "no"                  # one-shot

Нота: "no" у YAML треба брати у лапки, інакше YAML парсить як boolean false.

Типові помилки

Забути поставити політику на довгоживучий сервіс

bash

# НЕПРАВИЛЬНО: дефолт "no"; container не переживає host reboot
docker run -d --name api -p 80:80 myapp

# ПРАВИЛЬНО
docker run -d --name api -p 80:80 --restart=unless-stopped myapp

Це найпоширеніша operations-помилка на single-host деплоях. Container працює, ідеш додому, host рестартується вночі, сервіс down і телефон дзвонить.

Брати always і дивуватися, що ручний stop не тримається

bash

$ docker run -d --name api --restart=always myapp
$ docker stop api
$ docker ps          # api повернувся

always буквально означає завжди. Бери unless-stopped, якщо хочеш, щоб ручний stop поважався.

Crash-loop без фільтра exit-коду

bash

# Container exit з кодом 0, але ти хочеш рестарт тільки на failure
docker run --restart=always myjob
# Рестартує вічно, навіть на чистих exit. Скоріш за все не те, що хочеш.

# Краще:
docker run --restart=on-failure myjob

Забути, що on-failure не переживає reboot

Якщо container paused або running, коли ти reboot'аєш, on-failure його не повертає. Бери unless-stopped, якщо потрібне виживання reboot.

Restart policy + healthcheck

Docker restart-policy реагує на exit процесу, не на unhealthy healthcheck. Unhealthy container, що не вийшов, не рестартується Docker. Щоб діяти на healthcheck:

Swarm замінює unhealthy task новими (налаштовується).
Compose з condition: service_healthy лише gate'ує startup, не runtime-рестарт.
Звичайний Docker: external watchdog (autoheal-container, кастомний скрипт) може docker restart на основі health-статусу.

bash

# willfarrell/autoheal: моніторить і auto-restart unhealthy container
docker run -d \
    --name autoheal \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -e AUTOHEAL_CONTAINER_LABEL=autoheal \
    willfarrell/autoheal

docker run -d --label=autoheal=true --health-cmd="..." myapp

Реальне застосування

Прод single-host сервіси: unless-stopped всюди, майже без винятків.
CI / build container: без restart-policy (дефолт no). Крутяться, виходять, лишаються exited.
Background-worker: on-failure:N, щоб transient-краши retry, а permanently-broken job урешті здавалося.
Критична інфраструктура (host від нього залежить): іноді always виправдане, наприклад, security-агент, що має бути up незважаючи на.

Питання для поглиблення

Q: Яка різниця між always і unless-stopped?

A: always рестартує навіть після ручного docker stop. unless-stopped ні. Обидва переживають crash і host reboot; різниця в тому, чи поважається твій намір (docker stop).

Q: Чи застосовується restart-policy, якщо я docker rm container?

A: Ні, як видалено, нема чого рестартувати. Політики оперують на існуючих container.

Q: Як побачити, яка політика у container?

A: docker inspect <name> --format '{{.HostConfig.RestartPolicy.Name}}'. Повертає always, unless-stopped, on-failure або порожнє для no.

Q: Чи --restart застосовується у Swarm-сервісі?

A: Ні. Swarm-сервіси беруть restart_policy: у deploy-config (з condition: any|on-failure|none, delay, max_attempts). Флаг --restart для standalone-container.

Q: (Senior) Коли НЕ варто використовувати restart-policy взагалі?

A: Коли щось інше відповідальне за life-cycle container. K8s-pod керується kubelet, Docker restart-policy нерелевантна всередині K8s-pod (і ігнорується). Те саме для systemd-managed container через docker run --rm з unit. Правило: один restart-authority per container; обери оркестрацію, що володіє ним.

Приклади

Production-style сервіс з кількома шарами resilience

bash

$ docker run -d \
    --name api \
    --restart=unless-stopped \
    -p 3000:3000 \
    -v api_data:/data \
    --health-cmd='curl -f http://localhost:3000/health || exit 1' \
    --health-interval=30s \
    --memory=512m \
    myapp:1.0

Crash процесу → daemon рестартує через політику.
Host reboot → container повертається.
Ручний docker stop → лишається зупиненим (ти знаєш, що зробив).
Healthcheck робить статус видимим для моніторингу + reverse proxy.

Compose: різні політики per service

yaml

services:
  api:
    image: myapp
    restart: unless-stopped

  worker:
    image: myworker
    restart: on-failure        # batch retry

  migrator:
    image: mymigrator
    restart: "no"               # one-shot, не рестартити
    profiles: [migrate]         # opt-in profile

Різні форми роботи, різні політики. Migrator має крутитися раз і лишатися exited.

Cap retry, щоб запобігти нескінченних циклів

bash

$ docker run -d --name flaky --restart=on-failure:3 myjob

# Після 3 non-zero exit daemon припиняє пробувати.
$ docker ps -a --filter name=flaky --format '{{.Status}}'
Exited (1) 5 seconds ago     # фінальний стан, без retry

on-failure:N це safety-net для job, що можуть падати назавжди. Без cap daemon retry'їть нескінченно.

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.

Коментарі

Ще немає коментарів