Watchtower: автоматические обновления Docker

Логотип инструмента Watchtower для автоматического обновления контейнеров

Watchtower автоматически отслеживает образы контейнеров на хосте и перезапускает контейнеры при появлении новых версий образов. Это сокращает ручную работу по обновлению сервисов, поддерживает конфигурации контейнеров и может отправлять уведомления, работать в режиме мониторинга и очищать старые образы. В статье — пошаговые примеры деплоя, настройки расписания, уведомлений, жизненных хуков, рекомендации по безопасности, плейбук для обновления и контрольный лист для команд.

Важно: H1 присутствует в документе один раз — заголовок выше.

О чём эта статья

Что делает Watchtower и в каких сценариях он полезен
Как развернуть Watchtower на хосте и в приватной сети
Как управлять списками включения/исключения контейнеров
Как настроить расписание, уведомления и хуки жизненного цикла
Практические рекомендации по безопасности, мониторингу и откату
Плейбук, чек‑листы и шаблоны команд для оперативной работы

Кому полезно: инженерам DevOps, SRE и админам контейнерных платформ, которые хотят безопасно автоматизировать обновления образов.

Введение: что такое Watchtower (одной строкой)

Watchtower — это демон, запущенный в контейнере, который периодически проверяет образы ваших контейнеров в реестре и перезапускает контейнеры при обнаружении новых версий образов.

Основная идея и преимущества

Автоматизация обновлений образов при выходе новых версий.
Сохранение текущих параметров контейнера (тома, порты, переменные окружения).
Поддержка уведомлений и жизненных хуков для до‑ и послеобновочных действий.
Возможность работать в «только мониторинг» режиме, чтобы не применять обновления автоматически.

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

Развёртывание Watchtower — базовый пример

Запустите Watchtower как отдельный контейнер на каждом Docker‑хосте. Это самый простой и распространённый способ:

$ docker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Пояснение: монтирование сокета Docker (-v /var/run/docker.sock:/var/run/docker.sock) необходимо, чтобы Watchtower мог перечислять контейнеры и перезапускать их через демон Docker на хосте.

Watchtower для удалённого Docker‑демона

Если Docker‑демон доступен по TCP, можно задать DOCKER_HOST:

$ docker run -d --name watchtower \
  -e DOCKER_HOST="tcp://192.168.0.1:2375" \
  containrrr/watchtower

Если требуется TLS‑аутентификация, примонтируйте сертификаты в /etc/ssl/docker и используйте флаг –tlsverify:

$ docker run -d --name watchtower \
  -e DOCKER_HOST="tcp://192.168.0.1:2375" \
  -e DOCKER_CERT_PATH=/etc/ssl/docker \
  -v ./certs:/etc/ssl/docker \
  containrrr/watchtower --tlsverify

Важно: запускать Watchtower следует один раз на каждом хосте. При старте экземпляр очищает другие экземпляры Watchtower, если они уже запущены. Можно запускать несколько экземпляров с разными scope, но в большинстве сценариев это не нужно.

Примеры для docker‑compose

Если вы используете docker‑compose, добавьте сервис watchtower и проброс сокета:

services:
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_POLL_INTERVAL=3600
    restart: unless-stopped

Использование Watchtower: поведение при обновлении

Watchtower по умолчанию опрашивает образы каждые 24 часа.
При обнаружении нового образа Watchtower скачивает его, создаёт новый контейнер с теми же параметрами, что и оригинал, и затем перезапускает сервис.
Параметры сохраняются: привязки портов, тома, переменные окружения и прочие опции остаются.
Watchtower учитывает зависимости: контейнеры, связанные между собой, будут остановлены и запущены в корректном порядке.
Для остановки контейнера Watchtower отправляет SIGTERM по умолчанию; сигнал можно переопределить при старте контейнера через label.

Пример смены сигнала на SIGHUP:

$ docker run -d --label=com.centurylinklabs.watchtower.stop-signal=SIGHUP my-image

Включение/исключение контейнеров из обновлений

Вы управляете мониторингом конкретных контейнеров через метки (labels) и флаги Watchtower.

Отключить обновления для контейнера (opt‑out):

$ docker run -d --label=com.centurylinklabs.watchtower.enable=false my-image

Включить режим whitelist: Watchtower будет обновлять только те контейнеры, где явно включено поведение. Активируется флагом –label-enable при старте Watchtower:

$ docker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --label-enable

Теперь пометьте контейнеры, которые должны обновляться:

$ docker run -d --label=com.centurylinklabs.watchtower.enable=true my-image

Полезный паттерн: используйте whitelist для продакшен‑сервисов, чтобы случайно не обновить весь хост.

Жизненные хуки (Lifecycle hooks)

Watchtower может вызывать скрипты внутри контейнера при определённых событиях. Доступны четыре хука:

pre-check — перед проверкой, доступен ли новый образ
pre-update — после обнаружения обновления, до перезапуска контейнера
post-update — после успешного обновления контейнера
post-check — после завершения проверки контейнера

Хуки задаются через метки, значение — путь к исполняемому файлу внутри контейнера. Пример:

$ docker run -d --label=com.centurylinklabs.watchtower.lifecycle.pre-update="/backup.sh --create" my-image

Хуки удобны для выполнения подготовительных действий: создание бэкапа, уведомление внешних систем, синхронизация состояния.

Важно: скрипты выполняются внутри контейнера, поэтому они должны присутствовать в образе и иметь права на исполнение.

Уведомления и мониторинг

Watchtower поддерживает отправку уведомлений через email, Slack, Microsoft Teams, Gotify и Shoutrrr. Настройка происходит через переменные окружения.

Пример базовой настройки Gmail (SMTP):

$ docker run -d --name watchtower \
  -e WATCHTOWER_NOTIFICATIONS=email \
  -e WATCHTOWER_NOTIFICATION_EMAIL_FROM=you@gmail.com \
  -e WATCHTOWER_NOTIFICATION_EMAIL_TO=you@gmail.com \
  -e WATCHTOWER_NOTIFICATION_EMAIL_SERVER=smtp.gmail.com \
  -e WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=587 \
  -e WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=you@gmail.com \
  -e WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=your_gmail_app_password \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Пример для Slack через Shoutrrr (синтаксис shoutrrr://):

$ docker run -d --name watchtower \
  -e WATCHTOWER_NOTIFICATIONS=shoutrrr \
  -e WATCHTOWER_NOTIFICATION_SHOUTRRR_URL="slack://token@channel" \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Режим мониторинга без применения обновлений

Если вы хотите получать оповещения об доступных обновлениях, но применять их вручную, используйте флаг –monitor-only:

$ docker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --monitor-only

Также можно пометить отдельный контейнер как monitor‑only:

$ docker run -d --label=com.centurylinklabs.watchtower.monitor-only=true my-image

Совет: в продакшен‑кластерах комбинируйте monitor‑only для критичных сервисов и автоматический режим для вспомогательных агентов.

Интервал опроса и расписание

По умолчанию Watchtower проверяет обновления каждые 24 часа. Интервал можно изменить через –interval или переменную WATCHTOWER_POLL_INTERVAL (значение в секундах):

# Обновлять каждый час
$ docker run -d --name watchtower \
  -e WATCHTOWER_POLL_INTERVAL=3600 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Для более гибкого управления используйте cron‑синтаксис в –schedule или WATCHTOWER_SCHEDULE:

# Обновлять каждые 5 минут
$ docker run -d --name watchtower \
  -e WATCHTOWER_SCHEDULE="*/5 * * * *" \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Практическое правило: не ставьте очень частое опрашивание (меньше 1 минуты) для большого числа контейнеров — это создаёт повышенную нагрузку на реестр и сеть.

Очистка старых образов

По умолчанию старые версии образов остаются на хосте и могут занимать место. Флаг –cleanup или WATCHTOWER_CLEANUP=true удаляет старые образы после обновления:

$ docker run -d --name watchtower \
  -e WATCHTOWER_CLEANUP=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

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

Запуск по требованию

Чтобы выполнить одну итерацию проверки/обновления и завершиться, используйте –run-once и опцию –rm:

$ docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --run-once

Это полезно для адхок‑проверок или CI‑триггеров.

Работа с приватными реестрами

Watchtower должен иметь доступ к учётным данным приватного реестра. Есть несколько вариантов доставки учётных данных:

Примонтировать ~/.docker/config.json в контейнер как /config.json:

$ docker run -d --name watchtower \
  -v $HOME/.docker/config.json:/config.json \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Недостаток: docker login может обновлять файл config.json путём замены inode, и изменения на хосте не попадут внутрь уже запущенного контейнера.

Передать логин через переменные окружения REPO_USER и REPO_PASS:

$ docker run -d --name watchtower \
  -e REPO_USER=demo-user \
  -e REPO_PASS=users-password \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Совет по безопасности: не храните пароли в виде простого текста. Используйте секреты Docker, менеджеры секретов или провайдеры CI/CD для безопасной поставки учётных данных.

Безопасность и рекомендации по защите окружения

Минимизируйте привилегии: не запускайте Watchtower с дополнительными привилегиями, если не требуется.
Ограничьте доступ к Docker‑сокету: любой процесс с доступом к /var/run/docker.sock получает полномочия управления Docker‑демоном.
Защищайте данные реестра: используйте токены с ограниченными правами и коротким сроком жизни.
TLS для удалённого демона: всегда включайте TLS/мутуальную аутентификацию, если подключение к Docker производится по сети.
Логи и аудит: направляйте логи Watchtower в централизованную систему логирования для аудита обновлений.

Важно: доступ к Docker‑сокету эквивалентен root‑доступу к хосту. Планируйте модель безопасности заранее.

Плейбук обновления: безопасная процедура

Оцените критичность сервиса и выберите режим: monitor‑only для критичных, автоматический для вспомогательных.
Настройте уведомления в Slack/Teams/GitHub Actions для прозрачности операций.
Тестируйте обновления в тестовом окружении с той же конфигурацией томов и сетевых привязок.
Для продакшена: запустите Watchtower с label‑whitelist и добавляйте контейнеры по одному.
Перед применением обновления выполните pre‑update хуки (бэкап, health‑check).
После обновления контролируйте метрики приложения и логи (SLO/SLI).
Если что‑то пошло не так — используйте roll‑back (см. ниже).

Инцидентный рукбук и откат

Краткий план действий при неудачном обновлении:

Немедленно оповестить команду через заранее настроенный канал.
Посмотреть логи Watchtower и контейнера: docker logs
Если новый контейнер не работает, вернуть предыдущую версию образа:
- Если старый образ ещё на хосте: docker run –name
- Если образ удалён: подтянуть нужную версию из реестра и запустить с теми же опциями.
Проанализировать причину: несовместимость конфигураций, миграции БД, изменения API.
Скорректировать процесс обновления (добавить pre‑check, изменить порядок рестарта).

Совет: всегда храните в реестре теги с версионированием (semver) и фиксируйте совместимые теги в документации развертывания.

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

Образы успешно подтянулись и контейнеры перезапустились.
Сервис работает и проходит health‑checks в течение контрольного окна.
Отсутствуют увеличенные ошибки 5xx в логах и метриках.
Пользовательская функциональность проверена в smoke‑тестах.

Роль‑ориентированные чек‑листы

Для инженера DevOps:
- Убедиться, что WATCHTOWER_POLL_INTERVAL и расписание настроены.
- Настроить уведомления и проверить доставку сообщений.
- Настроить whitelist/blacklist для сервисов.
Для инженера приложений:
- Проверить, что pre‑update и post‑update скрипты корректно выполняются.
- Подготовить миграции и ручной сценарий отката.
Для менеджера SRE:
- Утвердить политику автоматических обновлений для продакшена.
- Обеспечить процессы аудита и логирования событий обновления.

Полезные шаблоны команд

Шаблон запуска Watchtower с мониторингом, уведомлениями в Slack и очисткой старых образов:

$ docker run -d --name watchtower \
  -e WATCHTOWER_NOTIFICATIONS=shoutrrr \
  -e WATCHTOWER_NOTIFICATION_SHOUTRRR_URL="slack://token@channel" \
  -e WATCHTOWER_CLEANUP=true \
  -e WATCHTOWER_POLL_INTERVAL=3600 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Шаблон запуска с указанием schedule и whitelist:

$ docker run -d --name watchtower \
  -e WATCHTOWER_SCHEDULE="0 3 * * *" \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --label-enable

Когда автоматические обновления не подходят (контрпример)

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

В таких случаях лучше использовать режим мониторинга и прокатывать обновления по окнам обслуживания вручную.

Ментальные модели и правило принятия решения

Если обновление обратимо и не влияет на схему данных — автоматизируйте.
Если обновление потенциално ломает API или требует миграций — мониторьте только и обновляйте вручную.

Мини‑fact box (ключевые моменты)

Где запускается: на каждом Docker‑хосте рядом с демоном Docker.
Доступные уведомления: email, Slack, Teams, Gotify, Shoutrrr.
Настройка расписания: через –interval (секунды) или –schedule (cron).
Поддержка приватных реестров: /config.json, REPO_USER/REPO_PASS.

Краткий глоссарий (1‑строчные определения)

Docker socket — UNIX‑сокет /var/run/docker.sock для управления демоном Docker.
Watchtower scope — идентификатор экземпляра Watchtower для разделения области действия.
Hook — исполняемый скрипт, запускаемый при событии жизненного цикла контейнера.

Mermaid: быстрое дерево решений для режима работы

flowchart TD
  A{Контейнер критичен?} -->|Да| B[Использовать monitor-only]
  A -->|Нет| C[Автоматическое обновление]
  B --> D{Требуются миграции?}
  D -->|Да| E[Ручной релиз с тестами]
  D -->|Нет| F[Ручной релиз или автоматический после теста]
  C --> G{Есть уведомления?}
  G -->|Да| H[Настроить Shoutrrr/Email]
  G -->|Нет| I[Добавить уведомления для аудита]

Сценарии миграции и советы по переходу

Для перевода продакшена на автоматические обновления: начать с тестовой среды, затем перенести в staging и постепенно включать whitelist для неприоритетных сервисов в продакшене.
Документируйте rollback‑шаги для каждого сервиса и храните их рядом с конфигурацией развёртывания.

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

Watchtower работает с Docker API; при использовании других контейнерных движков или оркестраторов (Kubernetes) применяют нативные инструменты (kubectl rollout, Flux, ArgoCD).
При использовании Docker Swarm нужно проверить взаимодействие с сервисами Swarm — подходы отличаются от классического docker run.

Заключение

Watchtower упрощает управление жизненным циклом контейнеров, автоматизирует рутинные обновления и облегчает сопровождение множества сервисов. При правильной конфигурации, контрольных механизмах и плейбуке он отлично вписывается в процесс доставки ПО. Тем не менее для критичных сервисов рекомендуется консервативный подход: мониторинг и ручной релиз с проверками.

Ключевые рекомендации: начните с мониторинга, добавьте уведомления, используйте hooks для подготовки, а для продакшена применяйте whitelist и проработанный план отката.

Краткое резюме и действия на ближайшую неделю:

Настройте Watchtower в тестовой среде с monitor-only и уведомлениями.
Подготовьте pre-update скрипты для бэкапов.
Определите список сервисов, которые можно переводить в автоматический режим.

Watchtower — автоматическое обновление Docker‑контейнеров