Оновлення контейнерів без простою

Оновлення контейнера — це не «завантажити новий образ», а «замінити запущену версію на нову й мати змогу відкотитися». Різниця проявляється рівно один раз: коли нова версія не запускається.

Процедура, яка працює

cd /opt/myapp
docker compose pull
docker compose up -d
docker compose ps
docker compose logs -f --tail 100

Compose перестворює лише ті сервіси, чий образ змінився, а решту не чіпає. Простій — це лише секунди, потрібні на перезапуск контейнера.

Але перш ніж це робити, виконайте дві умови.

Перше: версії закріплені. У файлі має бути вказано postgres:17.2, а не postgres:latest. Інакше pull одного дня принесе мажорну версію, яка перепише формат даних, і відкат стане неможливим.

Друге: резервна копія свіжа. Оновлення, яке ламає базу даних, ламає її незворотно. Перед зміною мажорної версії зробіть дамп — дивіться що потрібно бекапити.

Заміна без простою

Для вебсервісу за зворотним проксі простій падає майже до нуля, якщо в контейнера є перевірка стану: проксі почне надсилати запити лише до готового екземпляра.

services:
  app:
    image: ghcr.io/example/app:1.5.0
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://localhost:8080/health"]
      interval: 5s
      timeout: 3s
      retries: 6
      start_period: 20s

docker inspect -f '{{.State.Health.Status}}' <container>

Без перевірки стану Compose вважає контейнер готовим щойно запустився процес — поки застосунок ще читає свої налаштування й застосовує міграції.

Не видаляйте старий образ, доки нова версія не пропрацює щонайменше годину. Відкат означає відновити image: ...:1.4.2 і виконати docker compose up -d, але лише поки старий образ ще на диску. docker image prune -a одразу після оновлення забирає цю можливість.

Відкат

sed -i 's|app:1.5.0|app:1.4.2|' compose.yaml
docker compose up -d app
docker compose logs -f --tail 50 app

Якщо нова версія вже змінила схему бази даних, відкотити сам лише образ недостатньо — знадобиться відновлення з резервної копії. Саме тому мажорні оновлення роблять у тихий час і з перевіреною резервною копією: дивіться навчання з відновлення.

Автоматизація: будьте обережні

Watchtower може оновлювати контейнери самостійно. Для домашніх сервісів це зручно; для продакшену це ризик: оновлення приходить уночі, ламає базу даних, і ніхто цього не помічає. Розумний компроміс — лише сповіщення:

services:
  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --monitor-only --schedule "0 0 6 * * *"

Ви дізнаєтеся, що вийшла нова версія, і оновлюєте вручну в зручний час.

Перезавантаження машини

Системні пакети оновлюються окремо від контейнерів. Після оновлення ядра потрібне перезавантаження, і контейнери з restart: unless-stopped піднімаються самі. Перевірте це заздалегідь — командою sudo reboot у тихий час, а не під час інциденту. М'яке перезавантаження з панелі працює, якщо в системі встановлено qemu-guest-agent.

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

• pull без up -d. Новий образ завантажено, але старий контейнер усе ще працює.
• Диск забитий старими образами. Виконуйте docker image prune раз на місяць — але не одразу після оновлення. Дивіться місце на диску.
• Ви оновили все одразу. Щось ламається — і ви не можете зрозуміти, що саме. Оновлюйте по одному сервісу за раз.
• Ви не прочитали примітки до випуску. Несумісний файл конфігурації — найпоширеніша причина збою після зміни мажорної версії; дивіться розбір у типові проблеми Docker.