Docker Live Restore: держать контейнеры при падении демона

Фотография сервера с контейнерами и терминалом

Live Restore в Docker позволяет контейнерам продолжать работу, когда демон Docker останавливается (обновление пакета, сбой, ручной рестарт). Включается временно флагом –live-restore или постоянно через /etc/docker/daemon.json. Это уменьшает простой, но имеет ограничения: журналы могут теряться при продолжительном отсутствии демона, и обновления мажорных версий Docker не поддерживают Live Restore.

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

Почему это важно
Как работает Live Restore
Включение временно и постоянно
Тестирование и проверка
Длительная работа без демона
Ограничения и подводные камни
Альтернативы и лучшие практики
Методичка для оператора
Критерии приёмки
Резюме

Почему это важно

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

Краткое определение. Live Restore — это режим, при котором демон Docker не останавливает уже запущенные контейнеры при своей остановке и повторно подключается к ним после перезапуска.

Важно: Live Restore не делает контейнеры «самодостаточными» — он просто предотвращает их немедленное завершение при падении демона.

Как работает Live Restore

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

Ключевые аспекты поведения:

Контейнеры сохраняют свои PID и сетевые сокеты на уровне ОС.
CLI-команды docker не будут работать, пока демон не будет доступен.
Логи буферизуются в FIFO, закономерности логирования зависят от драйвера логов.

Включение Live Restore временно и постоянно

Вариант 1 — однократный запуск демона с флагом:

sudo dockerd --live-restore

Вариант 2 — постоянное включение через конфигурацию демона. Откройте или создайте файл /etc/docker/daemon.json и добавьте:

{
  "live-restore": true
}

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

sudo systemctl reload docker

Проверка статуса: остановите демон и убедитесь, что контейнеры остаются запущенными:

sudo systemctl stop docker
# в другом терминале: docker ps (не сработает, т.к. демон остановлен)
# но процессы контейнеров будут продолжать выполняться на хосте

При старте демона он автоматически обнаружит текущие контейнеры и восстановит их в управление.

Тестирование и проверка

Минимальная последовательность тестов после включения Live Restore:

Включите Live Restore в конфиге или запустите dockerd с флагом.
Запустите контролируемый контейнер:

docker run -d --name test-sleep busybox sleep 3000

Остановите демон:

sudo systemctl stop docker

На хосте проверьте процессы контейнера (ps, ss/netstat для сокетов).
Перезапустите демон:

sudo systemctl start docker

Убедитесь, что контейнер снова видим в docker ps и сохранил состояние.

Критерии приёмки приведены ниже.

Длительная работа без демона

Live Restore позволяет контейнерам работать длительное время без демона, но есть ограничения:

Логи. Docker использует FIFO‑буфер для передачи логов от контейнера демону. По умолчанию размер буфера — 64K (приблизительно 64 КБ). Если демон не считывает буфер, он может заполниться и потерять новые строки логов. Размер можно увеличить через параметр ядра:

echo  | sudo tee /proc/sys/fs/pipe-max-size

Где — значение в байтах; менять нужно осторожно и тестировать.

Мониторинг и метрики. Агентам, которые интегрируются с демоном Docker, потребуется альтернативный канал сбора метрик, пока демон недоступен.
Управление жизненным циклом. Команды docker start/stop/rm недоступны до возвращения демона.

Важно: Live Restore хорошо подходит для минимизации кратковременных простоев, но не заменяет планирование обновлений и обработку длительных операций.

Ограничения и подводные камни

Обновления мажорных версий. При обновлении Docker между мажорными версиями (например, 19.03 → 20.10) Live Restore не позволяет избежать рестарта: демон будет перезапущен и контейнеры могут быть прерваны.
Смена сетевых настроек. Изменение опций демона, влияющих на сеть (IP bridge, настройки CNI), может привести к некорректному восстановлению контейнеров. В таких случаях придётся остановить и пересоздать контейнеры.
Windows-контейнеры. Live Restore пока не поддерживается для Windows-контейнеров; для Windows‑хостов Live Restore доступен только для Linux‑контейнеров через Docker Desktop (Preferences > Daemon > Advanced).
Ловушки конфигурации. Не используйте Live Restore как замену процесса безопасного изменения конфигурации демона. Для правки настроек планируйте окно обслуживания или испольуйте systemctl reload docker.

Совет: проводите обновления конфигурации и тесты на стендах перед применением в продакшн.

Альтернативы и лучшие практики

Оркестраторы (Kubernetes, Nomad). Управляют перезапуском контейнеров на кластере и минимизируют влияние одиночного хоста.
Политики рестарта контейнеров. В docker-compose или в Dockerfile используйте restart: always или --restart unless-stopped, чтобы контейнеры автоматически поднимались после перезапуска хоста.
HA стопка: репликация сервисов и балансировка нагрузки устраняют зависимость от одного экземпляра.
Системные snapshot и контроль версий конфигурации для быстрого восстановления.

Контрпример: если ваши контейнеры сильно зависят от соединений с локальными ресурсами ОС (локальные сокеты, специфичные сетевые интерфейсы), Live Restore может не помочь после изменения этих ресурсов.

Методичка для оператора — пошаговый SOP

Подготовка: убедитесь, что конфигурационные файлы и образы закоммичены в систему контроля версий.
Включение:
- Временный запуск: sudo dockerd --live-restore для проверки поведения.
- Постоянное включение: добавить "live-restore": true в /etc/docker/daemon.json.
Применение: выполнить sudo systemctl reload docker.
Тестирование: выполнить сценарий из раздела тестирования.
Мониторинг: проверьте систему логирования и размер FIFO, настройте оповещения на пропажу логов.
Документирование: зафиксируйте изменения в changelog и в runbook.

Важно: если в конфиге есть изменения, затрагивающие сеть, планируйте maintenance window.

Роли и чек‑листы

Для SRE/DevOps:

Проверить, что daemon.json хранится в VCS.
Установить оповещения о падении демона и заполнении лог‑буфера.
Провести сценарий восстановления в кластере тестирования.

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

Проверить, что включение Live Restore не нарушает политики аудита и доступа.
Убедиться, что логи реплицируются в сторонний хранилище (SIEM) на случай пропажи локальных логов.

Для владельца приложения:

Убедиться, что приложение корректно переносит временные разрывы в управлении (например, управляющие команды не зависят от docker-cli во время outage).

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

После включения Live Restore остановка демона не приводит к остановке тестового контейнера.
После рестарта демона контейнер отображается в docker ps и сохраняет состояние.
Логи для критичных сервисов не теряются в режиме допустимой задержки (принимая во внимание размер FIFO).
Обновление мажорной версии Docker тестировано и задокументировано, с шагами «rollback» в случае проблем.

Тестовые сценарии и кейсы приёма

Сценарий A: кратковременный стоп демона (до 5 минут) — сервисы остаются доступными.
Сценарий B: длительный стоп демона (несколько часов) — проверка наличия утрат логов и корректности работы соединений.
Сценарий C: изменение сетевой конфигурации демона и попытка рестарта — контейнеры корректно пересоздаются или корректно помечаются для ручного вмешательства.

Факты в одном блоке

По умолчанию FIFO буфер логов: 64K (~64 КБ).
Файл конфигурации демона: /etc/docker/daemon.json.
Параметр ядра для размера пайпа: /proc/sys/fs/pipe-max-size.

Совместимость и миграция

Live Restore работает для Linux‑контейнеров на Linux‑хостах.
Не применим для Windows‑контейнеров на Windows‑хостах.
Мажорные апгрейды Docker могут потребовать полной перезапуска демона и не будут использовать Live Restore.

Заключение

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

Важно

Live Restore — это инструмент минимизации простоя, а не универсальное решение для безостановочных обновлений. Планируйте обновления и тестируйте поведение системы в безопасной среде.

Резюме

Включите Live Restore для уменьшения кратковременных простоев.
Тестируйте и документируйте процесс.
Контролируйте логирование и сетевые изменения.

Краткое объявление

Live Restore в Docker поможет вашим контейнерам оставаться активными во время неожиданных перезапусков демона. Включите его через /etc/docker/daemon.json и протестируйте поведение перед применением в продакшн.