Watchtower: как я обновляю прототипы через Docker-реестр и не ломаю себе прод | IT - архитектор

Watchtower: как я обновляю прототипы через Docker-реестр и не ломаю себе прод

Watchtower: как я обновляю прототипы через Docker-реестр и не ломаю себе прод

TL;DR — Watchtower идеально заходит в режиме прототипирования, когда ты не хочешь городить полноценный CI/CD, а обновлять контейнеры нужно часто, дешево и без боли.

За последние годы я разогнал десятки своих микросервисов — от Ananas до Adatari — и в них есть одна общая проблема: прототипы живут дольше, чем ожидаешь, а поддерживать их руками — боль.
Писать CI/CD для прототипа? Да, можно, но чаще всего не окупается.
Вот тут и начинается магия Watchtower.

Что такое Watchtower и почему он вообще существует?

Если коротко — это маленький демон, который:

  1. Поднимается как обычный контейнер рядом с остальными.
  2. Следит за Docker-реестром.
  3. Как только видит новую версию образа — пересоздаёт контейнер, подтягивает свежий билд, поднимает его с теми же параметрами, томами, переменными.

То есть ты пушнул образ → через минуту-две прототип встал на новую версию.
Автоматический docker pull + docker stop + docker rm + docker run в одной коробке.

Прямо для моей философии «запустил — забыл — перешёл к следующему компоненту» подходит идеально.

Когда Watchtower — топ, а когда лучше «не трогать»

✔ Идеально, если:

  • Это прототип, MVP или черновая сборка.
  • Изменения летят каждый день.
  • У тебя уже есть реестр (локальный, GitHub, Yandex, AWS — без разницы).
  • Хочешь «пушнул → всё встало».

❌ Плохо, если:

  • Прод, где любое движение — риски.
  • Нужны нулевые простои.
  • Есть сложные миграции БД, очереди, шины, stateful-логика.
  • Контейнер должен стартовать строго по расписанию/условиям.

В проде нормально делать канареечные релизы, а не класть прод на то, что Watchtower решит «а давай обновим».

Канареечные релизы: коротко и по делу

Канарейка — это когда новая версия раскатывается на маленькую часть трафика, а остальная система сидит на старой.
Если всё ок → масштабируем новую.
Если ошибка → «задушили канарейку», откатили.

В Docker-мире это обычно выглядит так:

  • старый контейнер: myimage:stable
  • новый контейнер: myimage:canary

Ты поднимаешь оба, направляешь часть трафика через ингресс/прокси на canary.
Если он жив → меняешь теги, обновляешь stable.

Watchtower тут ни при чём, это уже история про продакшн-инфру и грамотную маршрутизацию (NGINX, Traefik, Envoy).

Как я использую Watchtower в реальности

Для прототипов — это просто масло на колёса.

Сценарий рабочий:

  1. Пишу сервис.
  2. Билжу docker build -t registry/project/service:latest .
  3. docker push.
  4. Жду минуту.
  5. Прототип обновился.

С точки зрения R&D — это буквально «Dev → Push → Magic».

Я не заморачиваюсь с deploy-скриптами, ansible и прочим — до тех пор, пока проект не превращается в продукт.

Минимальный docker-compose с Watchtower

version: "3.8"

services:
  myservice:
    image: registry.example.com/myproj/service:latest
    restart: unless-stopped

  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command:
      - --interval=30              # проверять каждые 30 секунд
      - --cleanup                  # удалять старые образы
      - --enable-lifecycle-hooks   # корректные сигналы на перезапуск

Секунда в секунду не надо — в прототипах эти 30–60 секунд роли не играют.

Про теги: не ломай себе всё одним latest

Это важная часть.

Если пушить только latest, ты не сможешь нормально откатиться. Поэтому я делаю так:

service:latest — то, что едет на прототипы через Watchtower.

service:dev-{gitSHA} — конкретные версии для отката.

service:stable — ручная сборка, которую я признаю «нормальной».

Watchtower следит только за latest. Если что-то пошло не так — просто ставлю тег назад на старую версию и пушу:

docker tag service:dev-a1b2c3 service:latest docker push service:latest

И Watchtower сам откатит прототипы.

Политика откатов: мой упрощённый взгляд

Я придерживаюсь правила:

«Не пишем миграции в прототипах, не делаем сложный стейт, не держим очереди — и всё будет нормально».

Если сервис stateless → Watchtower идеален. Если нет → это уже не прототип, а мини-прод, и нужен CI/CD + миграции + канарейки.

Прод vs прототип: чёткая грань

Я строг в своей дисциплине:

Прототипы — обновляются Watchtower, могут упасть, могут перезапуститься, это нормально.

Предпрод / прод — только ручное управление версиями + canary deployment.

Эта граница спасает нервы, деньги и помогает держать проект под контролем.

sЗаключение

Watchtower — это инструмент, который:

экономит тонну времени,

делает прототипирование приятным,

снимает рутину «а как бы мне обновить этот контейнер на сервере»,

но не должен быть частью продакшн-практик.

Как только сервис начинает давать деньги → он уходит на нормальный CI/CD. Но до этого момента Watchtower — это тот самый костыль-самурай, который работает, заходит и делает жизнь проще.

Related Content