Автообновление Watchtower на сервере: частые ошибки и решения

MAATRIX

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

Как понять, что делает Watchtower

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

docker logs watchtower
docker logs --tail=50 -f watchtower

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

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

Она пройдётся по контейнерам прямо сейчас и подробно отчитается, что нашла и что сделала. Это лучший способ отладки: вы сразу видите поведение, а не гадаете. Держа логи и --run-once под рукой, вы быстро отнесёте проблему к нужной категории. Дальше — разбор частых симптомов.

Watchtower не обновляет контейнеры

Частый симптом: новая версия образа давно вышла, а контейнер как стоял, так и стоит. Причин несколько. Первая и очень частая — включён режим контроля по меткам (--label-enable), но на контейнере не стоит разрешающая метка. В этом режиме Watchtower трогает только помеченные контейнеры, а остальные игнорирует. Проверьте метки и логи:

docker inspect app | grep -i watchtower

Если метки нет, добавьте её в описание контейнера и пересоздайте его:

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

Вторая причина — контейнер следит за фиксированной версией тега, например myapp:1.4.0. Watchtower обновляет контейнер только когда меняется образ под тем же тегом, а конкретная версия по определению не меняется. Для автообновления сервис должен использовать подвижный тег вроде stable или latest — но помните, что это же и создаёт риск, о котором ниже. Третья причина — Watchtower просто ещё не дошёл до времени проверки: посмотрите расписание и дождитесь окна или запустите --run-once.

Обновление сломало рабочий сервис

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

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

docker compose pull app
docker compose up -d app

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

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

Так вы узнаёте о выходе версии, тестируете её и накатываете сами в удобное окно. Автообновление оставляют только вспомогательным сервисам, где обновление в пределах тега безопасно. И всегда держите бэкапы данных — тогда даже неудачное обновление не станет катастрофой.

Не тянет образы из приватного реестра

Симптом: публичные образы Watchtower обновляет, а контейнеры из вашего приватного реестра — нет, в логах ошибки авторизации или отказа доступа. Причина в том, что Watchtower не знает учётных данных вашего реестра. Для доступа он использует конфигурацию Docker, где хранятся логины после docker login.

Смонтируйте файл конфигурации Docker с учётными данными в контейнер Watchtower:

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

Файл config.json появляется после успешного docker login registry.example.com на хосте и содержит токен доступа. Без него Watchtower обращается к приватному реестру анонимно и получает отказ. Убедитесь, что логин на хосте действительно выполнен и токен в файле не протух. Если реестр требует периодического обновления токена, продумайте, чтобы учётные данные оставались валидными, иначе автообновление приватных образов будет тихо падать.

Задвоение, старые контейнеры и мусор

Иногда после обновлений на сервере накапливается мусор: старые образы занимают диск, а в редких случаях кажется, что контейнер «задвоился». Со старыми образами всё просто — по умолчанию Watchtower не удаляет их после обновления, и они копятся. Включите очистку флагом --cleanup:

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

Флаг --cleanup удаляет старый образ сразу после успешного обновления, экономя диск. Проверить, сколько занято образами, можно так:

docker system df
docker image prune -f

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

Профилактика и разумная стратегия

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

Технически закрепите это несколькими настройками: включите --label-enable и помечайте только безопасные сервисы, добавьте --cleanup против мусора, смонтируйте config.json для приватного реестра и настройте уведомления, чтобы знать о каждом обновлении. Обязательно держите бэкапы данных в томах — это ваша страховка на случай неудачного обновления. И следите за ресурсами сервера: чем больше контейнеров, тем больше нагрузка при одновременных обновлениях и тем важнее запас по памяти и диску. Когда сервер перестаёт справляться, надёжнее перейти на VPS помощнее — у MAATRIX это доступно в локациях RU, US и UK с оплатой из России картой или криптой.

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