Docker live restore: контейнеры работают при рестарте dockerd

Когда live restore действительно полезен

По умолчанию жизненный цикл контейнеров тесно связан с Docker daemon: его завершение может остановить работающие контейнеры. Live restore меняет это поведение и позволяет контейнерным процессам продолжать выполнение, когда dockerd временно недоступен. Это уменьшает окно простоя при плановом рестарте daemon или его сбое, особенно если сервис способен работать автономно без команд управления. Но во время недоступности daemon вы не сможете нормально выполнять `docker exec`, создавать новые контейнеры, менять их конфигурацию или получать актуальное состояние через Docker API. Поэтому режим полезен как операционная страховка, а не как замена оркестратору, второму узлу или внешнему health-check.

Совет: Перед изменением сохраните копию текущего daemon.json и зафиксируйте способ установки Docker. Это ускорит откат, если демон не запустится.

Как включить live restore безопасно

На Linux конфигурация daemon обычно находится в `/etc/docker/daemon.json`; на Docker Desktop параметр задаётся через настройки Docker Engine. Если JSON уже содержит другие ключи, добавьте `"live-restore": true`, не перезаписывая существующую конфигурацию. После сохранения проверьте валидность JSON и примените изменение штатным способом вашей системы. На production-хосте делайте это в контролируемое окно: синтаксическая ошибка в daemon.json способна оставить Docker daemon неработоспособным, даже если сами контейнеры ещё продолжают жить. После возврата dockerd обязательно проверьте, что он снова видит контейнеры и может ими управлять.

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

Что live restore не умеет

Live restore относится только к ситуации, когда daemon недоступен, а контейнерный процесс остаётся работоспособным. Если процесс внутри контейнера упал, закончилась память, отказал диск или перезагрузился весь сервер, эта функция не спасёт сервис. Docker отдельно указывает, что live restore не поддерживается для Windows containers; на Docker Desktop for Windows он относится к Linux-контейнерам. Docker документирует live restore при обновлении Engine только для patch-релизов; major upgrade и пропуск релизов могут не позволить новому daemon восстановить управление уже работающими контейнерами. Именно поэтому live restore нужно сочетать с restart policy, мониторингом приложения и проверенной процедурой обновления.

Важно: Live restore защищает от недоступности daemon, а не от отказа хоста. Для реальной HA нужен второй узел или кластер.

Как проверить режим до production

Запустите тестовый контейнер с простым HTTP-сервисом и проверьте его доступность извне. Затем перезапустите dockerd и продолжайте отправлять запросы к приложению в момент, когда Docker CLI временно недоступен. После возврата daemon выполните `docker ps`, проверьте логи, сетевую доступность и возможность обычного управления контейнером. Такой тест важнее самого факта наличия ключа в daemon.json: он проверяет весь сценарий обслуживания — systemd, firewall, балансировщик, приложение и возвращение управления. Если контейнер пишет данные, дополнительно убедитесь, что после восстановления нет ошибок файловой системы или приложения.

Как сочетать live restore с обслуживанием сервиса

На практике live restore полезнее всего как часть заранее описанной процедуры обслуживания. Перед изменением Docker Engine проверьте, что сервис не зависит от регулярных команд со стороны daemon и не теряет функциональность, если несколько минут недоступны `docker exec` или Docker API. Если перед контейнером стоит reverse proxy или load balancer, отдельно выясните, по какому сигналу он считает узел здоровым: проверка только Docker API может ошибочно убрать рабочий сервис из ротации, хотя сам процесс продолжает отвечать. Для stateful-приложений полезно проверить не только HTTP-ответ, но и запись/чтение данных во время перезапуска dockerd. После возврата daemon убедитесь, что мониторинг снова видит контейнер и что управление не осталось в частично восстановленном состоянии. Такая процедура превращает `live-restore` из скрытой настройки в контролируемый эксплуатационный механизм. Если же цель — пережить reboot сервера, потерю сети всего узла или аппаратный отказ, заранее проектируйте отдельный уровень отказоустойчивости: репликацию, второй хост, swarm/Kubernetes или внешний managed service.

Что происходит при долгой недоступности dockerd

Live restore рассчитан на сохранение уже работающих standalone-контейнеров, но длительная недоступность daemon имеет отдельный операционный риск: Docker обычно читает stdout/stderr контейнеров через FIFO. Документация предупреждает, что если daemon долго не читает поток, буфер может заполниться; для стандартного буфера Docker приводит размер 64 КБ. После заполнения контейнер может заблокироваться на попытке записи логов, хотя его основной процесс формально не завершился. Поэтому тест live restore должен включать не только HTTP-проверку, но и сервис, который активно пишет логи. Ещё одно ограничение касается обновлений: Docker документирует live restore для patch-релизов Engine, но не обещает сохранение управления при major upgrade или при пропуске релизов. Если новая версия daemon не восстановит связь с работающими контейнерами, управлять ими через Docker уже нельзя до ручного завершения. Наконец, восстановление зависит от неизменности важных daemon-параметров, например bridge IP и storage/graph driver. Поэтому перед обслуживанием зафиксируйте версию Engine и ключевые настройки, не совмещайте upgrade с сетевой миграцией и после возврата dockerd обязательно проверьте `docker ps`, управление контейнером и живой трафик.

Пошаговый порядок действий

1. Сделайте резервную копию фактически используемого daemon.json.
2. Добавьте верхнеуровневый ключ `"live-restore": true`.
3. Проверьте синтаксис JSON и примените изменение через штатное управление Docker service.
4. Оставьте тестовый контейнер запущенным и перезапустите dockerd.
5. Во время недоступности daemon проверьте реальный запрос к сервису.
6. После возврата dockerd убедитесь, что контейнер снова виден и управляется.

Краткая таблица

• Перезапуск dockerd. может сохранить уже работающий контейнер. не основной механизм
• Падение процесса контейнера. не помогает. может перезапустить
• Reboot всего хоста. процесс не переживает reboot. может поднять контейнер после старта Docker
• Отказ физического узла. не помогает. на том же узле не помогает

Контрольный список

• daemon стартует без ошибок
• контейнер доступен во время рестарта dockerd
• после возврата работает Docker CLI
• restart policy настроена отдельно
• есть мониторинг daemon и приложения

Что учитывать

Условия меняются. Страница отражает состояние на 2026-09-20; при расхождении с официальной документацией приоритет у первоисточника.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Live restore). Пример и формулировки — редакция N1RO на 2026-09-20.

• Live restore