Production-эксплуатация Docker Engine

После модуля вы сможете подготовить Engine к production, выполнить контролируемое обновление, проверить restart behavior и диагностировать daemon, disk и container failures по evidence.

• конфигурация версионируется и валидируется
• capacity и logs ограничиваются заранее
• обновление имеет preflight и rollback
• restart policy не заменяет orchestrator
• cleanup выполняется после inventory

На Linux основной файл — /etc/docker/daemon.json. Одну и ту же опцию нельзя одновременно задать флагом dockerd и в JSON: daemon откажется запускаться. Конфигурацию сначала проверяют dockerd --validate, затем применяют в maintenance window.

Критичные настройки: data-root, storage driver, logging, DNS/proxy, authorization, metrics и live-restore. Изменение network или storage параметров может быть несовместимо с работающим состоянием.

Restart policy реагирует на завершение главного процесса. on-failure учитывает ненулевой exit code и лимит попыток; unless-stopped и always имеют другую семантику ручной остановки и daemon restart.

live-restore позволяет standalone containers работать при недоступном daemon, но не даёт управлять ими. Он рассчитан прежде всего на patch upgrades; изменение daemon options или большой version jump может помешать reconnect. При долгой остановке daemon заполненный log FIFO способен заблокировать приложение.

Неограниченный json-file может заполнить диск. Для него max-size и max-file включают ротацию; значения log-opts в daemon.json задаются строками. Новый default применяется только к вновь созданным контейнерам.

Файлами logging driver управляет Docker: их нельзя редактировать внешними утилитами. В production выбирают local driver либо централизованный backend, контролируют buffering и проверяют поведение при его недоступности.

Контролируйте bytes и inodes для data-root, рост writable layers, volumes, BuildKit cache и logs. docker system df показывает Docker objects, но не заменяет df, filesystem alerts и inventory владельцев.

docker system prune не является плановым способом управления capacity: он удаляет общие unused resources. Сначала определяют owner, retention и возможность восстановления; volumes не удаляют массово без отдельного решения.

Перед обновлением изучают release notes и deprecations, проверяют OS/kernel/runtime compatibility, свободное место, backup конфигурации и данных, workload drain и rollback package.

Canary host обновляют первым. После upgrade проверяют daemon logs, version/API, networks, mounts, healthchecks, restart и application SLO. Backup /var/lib/docker как работающего дерева не гарантирует согласованное восстановление: данные приложений резервируют их штатным способом.

• Храните daemon.json как code без secrets
• Валидируйте до reload/restart
• Экспортируйте daemon и container metrics
• Alert на disk bytes и inodes
• Задавайте log limits всем новым workloads
• Проверяйте restore, не только backup
• Не публикуйте Docker API без mTLS/authorization
• Не лечите incident немедленным prune
• Записывайте change window и rollback criteria

Соберите baseline и проверьте кандидат daemon.json без изменения реального daemon.

date -Is
docker version
docker info
docker context show
docker system df -v
systemctl is-active docker
systemctl show docker --property=ActiveEnterTimestamp,ExecMainStartTimestamp
sudo journalctl -u docker.service --since '-15 minutes' --no-pager | tail -50

rm -rf /tmp/docker-m17 && mkdir -p /tmp/docker-m17
cat > /tmp/docker-m17/daemon.json <<'EOF'
{
  "live-restore": true,
  "log-driver": "json-file",
  "log-opts": {"max-size": "10m", "max-file": "3"}
}
EOF
sudo dockerd --validate --config-file /tmp/docker-m17/daemon.json
jq . /tmp/docker-m17/daemon.json

Запустите workload с healthcheck, ограниченными logs и restart policy. После 10 секунд успешной работы инициируйте контролируемый exit 42 из PID 1 и докажите restart.

docker volume create docker-m17-state
docker run --detach --name docker-m17-app \
  --restart on-failure:3 \
  --health-cmd 'test -f /state/ready' --health-interval 1s \
  --health-timeout 1s --health-retries 5 \
  --log-driver json-file --log-opt max-size=1m --log-opt max-file=2 \
  --volume docker-m17-state:/state alpine:3.21 sh -c   'touch /state/ready; trap "exit 0" TERM; n=0
   while :; do
     if [ -e /state/crash ]; then rm -f /state/crash; echo simulated_crash >&2; exit 42; fi
     n=$((n+1)); printf "tick=%s\n" "$n"; sleep 1
   done'
sleep 11
docker inspect docker-m17-app --format 'status={{.State.Status}} health={{.State.Health.Status}} restart={{.RestartCount}} log={{.HostConfig.LogConfig.Type}} opts={{json .HostConfig.LogConfig.Config}}'

before=$(docker inspect --format '{{.RestartCount}}' docker-m17-app)
docker exec docker-m17-app touch /state/crash
for attempt in 1 2 3 4 5 6 7 8 9 10; do
  status=$(docker inspect --format '{{.State.Status}}' docker-m17-app)
  after=$(docker inspect --format '{{.RestartCount}}' docker-m17-app)
  [ "$status" = running ] && [ "$after" -gt "$before" ] && break
  sleep 1
done
printf 'before=%s after=%s status=%s\n' "$before" "$after" "$status"
test "$after" -gt "$before"
docker logs --timestamps --tail 10 docker-m17-app

Критерий: configuration OK; container healthy до сбоя; RestartCount вырос; после crash контейнер снова running; log options видны в inspect.

Разделяйте host, daemon, runtime, container и application. Если CLI не отвечает, сначала проверьте context/socket, systemd state, journal, disk и inodes; не удаляйте state до сбора evidence.

docker info 2>&1 | sed -n '1,120p'
docker ps -a --no-trunc
docker events --since 15m --until 0s --filter container=docker-m17-app
docker inspect docker-m17-app --format '{{json .State}}' | jq
sudo journalctl -u docker.service --since '-30 minutes' --no-pager | tail -100
docker system df -v
df -hT /var/lib/docker
df -ih /var/lib/docker

• daemon inactive — unit status и journal
• cannot connect — context/socket/permissions
• no space left — bytes или inodes
• container restart loop — exit code, OOM, health и logs
• daemon healthy, app недоступен — process, network, publish и dependency
• manual docker stop/kill может подавлять ожидаемый auto-restart

• Почему validate предшествует restart?
• Чем restart policy отличается от healthcheck?
• Что гарантирует и не гарантирует live-restore?
• Когда новые log defaults начинают действовать?
• Почему нельзя редактировать log files вручную?
• Чем docker system df отличается от df?
• Почему prune опасен во время incident?
• Что проверить после upgrade?

docker rm --force docker-m17-app
docker volume rm docker-m17-state
rm -rf /tmp/docker-m17
docker system df

Модуль освоен, если изменение Engine имеет preflight, наблюдаемые критерии успеха и проверяемый rollback.