Production-експлуатація Docker Engine

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

• config версіонується та валідується
• capacity і logs обмежуються
• upgrade має preflight і rollback
• restart policy не замінює orchestrator
• cleanup після inventory

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

Критичні settings: data-root, storage driver, logging, DNS/proxy, authorization, metrics і live-restore. Зміна network або storage параметрів може бути несумісною з running state.

Restart policy реагує на завершення PID 1. on-failure враховує ненульовий exit code і limit; unless-stopped та always мають іншу семантику manual stop і daemon restart.

live-restore залишає standalone containers працювати без daemon, але ними не можна керувати. Він орієнтований на patch upgrades; зміна daemon options або великий version jump може зламати reconnect. Заповнений log FIFO здатен заблокувати app.

Необмежений json-file заповнює disk. max-size і max-file вмикають rotation; log-opts у daemon.json мають бути strings. Новий default діє лише для нових containers.

Logging files належать Docker — зовнішнє редагування небезпечне. Для production обирають local driver або central backend та тестують failure/backpressure.

Контролюйте bytes та inodes data-root, writable layers, volumes, BuildKit cache і logs. docker system df показує Docker objects, але не замінює df та ownership inventory.

system prune не є capacity strategy. Спочатку визначають owner, retention і restore; volumes не видаляють масово без окремого рішення.

До upgrade перевіряють release notes, OS/kernel/runtime compatibility, вільне місце, backup config/data, workload drain і rollback package.

Спочатку canary host. Після upgrade перевіряють journal, API/version, networks, mounts, health, restart та SLO. Копія running /var/lib/docker не гарантує consistent restore; app data backup роблять штатно.

• daemon.json як code без secrets
• Validate до reload/restart
• Daemon/container metrics
• Alerts на bytes та inodes
• Log limits для нових workloads
• Тест restore
• Не відкривати API без mTLS/authorization
• Не починати incident із prune
• Change window і rollback criteria

Зберіть baseline і перевірте candidate 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, log limits та 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 до failure; RestartCount зріс; container знову running; log options видно в inspect.

Розділяйте host, daemon, runtime, container та application. Якщо CLI не відповідає, перевірте context/socket, systemd, 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/journal
• cannot connect — context/socket/permissions
• no space left — bytes/inodes
• restart loop — exit, OOM, health, logs
• daemon healthy, app down — process/network/dependency
• manual stop/kill може пригнічувати auto-restart

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

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

Модуль засвоєно, якщо зміна Engine має preflight, observable success criteria та перевірений rollback.