Перейти к основному контенту

Глава 3.4: Автоматическое обновление — Watchtower.

Разработчики селф-хост приложений постоянно выпускают обновления: закрывают уязвимости, исправляют баги и добавляют новые фишки. Проверять вручную апдейты для десятка разных контейнеров через консоль — это рутина, которая быстро надоедает.

Чтобы автоматизировать этот процесс, мы добавим в нашу экосистему Watchtower (Сторожевую башню). Это умный служебный контейнер, который работает в фоне, с заданной периодичностью проверяет Docker Hub на наличие новых версий ваших образов, сам скачивает их и бесшовно перезапускает контейнеры со всеми вашими старыми настройками и томами данных.


1. Подготовка папки и манифеста

Создаем отдельную папку для Watchtower внутри каталога стеков и переходим в нее:

mkdir -p /stacks/watchtower
cd /stacks/watchtower

Теперь создаем файл docker-compose.yml:

nano docker-compose.yml

Вставьте туда следующую конфигурацию (мы настроим проверку обновлений раз в сутки и автоматическую очистку старых образов):

services:
  watchtower:
    image: containrrr/watchtower:latest
    container_name: watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_POLL_INTERVAL=86400
      - TZ=Europe/Moscow

2. Разбор переменных настройки (Environment)

Чтобы Watchtower работал именно так, как нам нужно, мы передали ему несколько важных параметров окружения:

  • /var/run/docker.sock — мы снова пробрасываем главный сокет управления Docker. Watchtower должен иметь полные права, чтобы отдавать команды движку на остановку, удаление и запуск любых контейнеров на сервере.
  • WATCHTOWER_CLEANUP=true — критически важная переменная гигиены. После того как Watchtower скачает новый образ и перезапустит контейнер, он автоматически удалит из системы старый образ. Благодаря этому ваш диск не будет незаметно забиваться цифровым мусором (вам реже придется выполнять команду docker system prune).
  • WATCHTOWER_POLL_INTERVAL=86400 — интервал проверки обновлений в секундах. Значение 86400 равняется ровно 24 часам. То есть Watchtower будет проверять апдейты строго раз в сутки с момента своего запуска.

3. Продвинутый лайфхак: Как запретить обновлять конкретный контейнер?

Иногда автоматические обновления могут быть опасны. Например, крупные мажорные обновления сложных систем (того же Nextcloud или баз данных) могут требовать ручного вмешательства или изменения структуры таблиц. Если обновить их вслепую, стек может "упасть".

Вы можете жестко запретить Сторожевой башне трогать определенные контейнеры. Для этого достаточно добавить специальную метку (label) в файл конфигурации того сервиса, который вы хотите защитить.

Например, если мы хотим запретить обновлять базу данных нашей Wiki, мы открываем /stacks/bookstack/docker-compose.yml и в блок сервиса bookstack-db дописываем директиву labels:

services:
  bookstack-db:
    image: lscr.io/linuxserver/mariadb:latest
    container_name: bookstack_db
    # ... ваши старые настройки окружения и волюмов ...
    labels:
      - "com.centurylinklabs.watchtower.enable=false" # ЗАПРЕТ НА ОБНОВЛЕНИЕ

Теперь, когда Watchtower будет обходить контейнеры на сервере, он наткнется на эту метку, уважительно пропустит базу данных и пойдет обновлять другие приложения.


Запуск и проверка

Поднимем нашу Сторожевую башню стандартной командой в фоне:

docker compose up -d

Сразу после запуска вы можете заглянуть в логи этого контейнера через терминал или установленный ранее Dozzle. Вы увидите приветственное сообщение и отчет о первой проверке:

Watchtower 1.X.X
Using local time zone: Europe/Moscow
Checking all containers (except those with un-enable labels)
...

💡 Итог автоматизации:
Теперь ваш домашний сервер стал по-настоящему автономным. Watchtower сам заботится об актуальности софта и безопасности версий, пока вы спите.

Но автоматизация обновлений повышает риски случайных сбоев. Что, если даже защищенный контейнер сломается из-за сбоя файловой системы или отказа жесткого диска? Правильно — нужен надежный бэкап. Переходим к финальной Главе 3.5: Стратегия бэкапов.