Как установить и настроить автообновление Watchtower на VPS

MAATRIX

Держать контейнеры на свежих версиях вручную — рутина, о которой легко забыть, а забытое обновление образа с уязвимостью превращается в дыру. Настроить автообновление Watchtower на VPS — значит переложить эту заботу на сервис, который сам следит за новыми версиями образов, скачивает их и перезапускает контейнеры. Разберём установку по шагам и честно обсудим, где автообновление уместно, а где опасно.

Что делает Watchtower и когда он полезен

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

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

Но честно о рисках, потому что автообновление — палка о двух концах. Если контейнер следит за подвижным тегом вроде latest, однажды ночью может приехать версия с несовместимыми изменениями и уронить сервис без вашего ведома. Поэтому автообновление уместно не везде: для критичных приложений с базой данных его либо не включают, либо используют с уведомлениями и без автоматического применения. Ниже мы покажем, как настроить Watchtower осмысленно, а не «обновляй всё подряд».

Подготовка VPS и установка Docker

Watchtower сам занимает считаные мегабайты, отдельных ресурсов под него закладывать не нужно — они уходят вашим контейнерам. Поставьте Docker, если его ещё нет:

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker
docker --version

Watchtower работает через сокет Docker, как и Portainer: ему нужен доступ к движку, чтобы видеть контейнеры и управлять ими. Это значит, что доступ к Watchtower фактически равен контролю над контейнерами, поэтому запускать его стоит только на своём сервере и не выставлять наружу — у него и нет веб-интерфейса, он работает фоново.

Локация сервера роли не играет для самого Watchtower, но влияет на скорость скачивания образов: если образы тянутся из зарубежных реестров, сервер с чистым IP в подходящей локации качает их стабильнее. У MAATRIX доступны площадки RU, US и UK с оплатой из России картой, СБП или криптой, что удобно, когда внешние реестры капризничают из России.

Запуск Watchtower в контейнере

Базовый запуск Watchtower — одна команда. Она поднимает контейнер, даёт ему доступ к сокету Docker и задаёт интервал проверки обновлений. Начнём с безопасного варианта, который проверяет раз в сутки:

docker run -d \
  --name watchtower \
  --restart=unless-stopped \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower \
  --interval 86400

Параметр --interval 86400 задаёт проверку раз в 24 часа (значение в секундах). Слишком частые проверки ни к чему — новые версии выходят не ежеминутно, а лишняя активность только нагружает реестр. Проверьте, что контейнер поднялся, и посмотрите его логи, где Watchtower отчитывается о проверках:

docker ps | grep watchtower
docker logs watchtower

В логах будет видно, сколько контейнеров он отслеживает и нашлись ли обновления. Это ваш основной способ понимать, что делает сервис.

Расписание и выборочное обновление

Проверять по фиксированному интервалу удобно не всегда — иногда обновления хочется применять в предсказуемое окно, например ночью, когда нагрузка минимальна. Watchtower умеет работать по расписанию cron. Замените интервал на расписание:

docker run -d --name watchtower \
  --restart=unless-stopped \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower \
  --schedule "0 0 4 * * *"

Это расписание запускает проверку каждый день в 4 часа утра. Теперь о главном для безопасности — выборочность. По умолчанию Watchtower обновляет все контейнеры, но правильнее обновлять только те, что вы явно разрешили. Для этого запускают его в режиме контроля по меткам, добавляя флаг --label-enable, и помечают нужные контейнеры:

docker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --label-enable --schedule "0 0 4 * * *"

А в compose-описании контейнера, который можно автообновлять, ставят метку:

labels:
  - "com.centurylinklabs.watchtower.enable=true"

Так под автообновление попадают только помеченные сервисы, а критичные остаются нетронутыми. Это тот самый осмысленный подход вместо «обновляй всё».

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

Даже удачное обновление стоит замечать, а неудачное — тем более. Watchtower умеет присылать уведомления о том, что и когда он обновил, — на почту, в мессенджер или через вебхук. Уведомления настраиваются переменными окружения контейнера и превращают Watchtower из «чёрного ящика» в понятный инструмент: вы всегда знаете, какие версии приехали.

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

docker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --monitor-only --schedule "0 0 4 * * *"

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

Проверка, обслуживание и здравый смысл

Убедитесь, что Watchtower действительно отслеживает нужные контейнеры и обновления применяются. Самый прямой способ — заглянуть в логи после запланированного времени и увидеть отчёт о проверке. Для проверки на живом примере можно запустить разовую проверку прямо сейчас, добавив флаг --run-once во временный запуск.

Обслуживание Watchtower минимально: он сам обновляет и себя, и отслеживаемые контейнеры. Но общий принцип важнее команд. Фиксируйте версии образов там, где важна стабильность, и не отдавайте критичные сервисы на полное автообновление — используйте метки и режим мониторинга. Держите бэкапы данных: автообновление, как и любое изменение, теоретически может что-то сломать, и откат должен быть возможен. Для этого удобно, чтобы данные лежали в томах и регулярно копировались.

Watchtower отлично снимает рутину с обновлением вспомогательных сервисов, но не заменяет продуманную стратегию развёртывания критичных приложений. Разумная комбинация — автообновлять безопасное, мониторить остальное — держит инфраструктуру и свежей, и стабильной. А когда сервисов и контейнеров становится много, им нужен сервер с запасом ресурсов: у MAATRIX подходящий VPS можно взять в нужной локации с оплатой из России картой или криптой.

Частые вопросы