DispelEvilBot/deploy

Деплой (Блок 2)

Образы и registry

Целевой registry — Gitea/Forgejo Container Registry (домашний сервер). Имя образа:

<registry>/mpakobecx/dispelevilbot-bot:<tag>

Сборка и публикация вручную:

docker login git.mpakosrv.ru -u mpakobecx        # пароль — access token
docker build -t git.mpakosrv.ru/mpakobecx/dispelevilbot-bot:0.1 .
docker push git.mpakosrv.ru/mpakobecx/dispelevilbot-bot:0.1

В CI (.gitea/workflows/ci.yml) это делается автоматически по пушу в master (и по тегам v*). Нужно завести секреты репозитория REGISTRY_USER, REGISTRY_TOKEN.

При доступе из локальной сети registry может быть на 192.168.31.158:3000 (тогда добавьте его в insecure-registries Docker-демона либо поставьте TLS-proxy). С сервера, где крутится runner, удобнее доменное имя.

Контуры test и prod

Один compose-файл, разные проекты и env-файлы (файл задаётся и для интерполяции, и как env_file сервисов):

# прод
REGISTRY=git.mpakosrv.ru IMAGE_TAG=0.1 \
  docker compose -p prod --env-file env/prod.env -f docker-compose.prod.yml up -d

# тест
REGISTRY=git.mpakosrv.ru IMAGE_TAG=0.1 \
  docker compose -p test --env-file env/test.env -f docker-compose.prod.yml up -d

Имя проекта (-p) даёт отдельные volume'ы (свои БД у prod и test). Перед первым запуском: cp env/prod.env.example env/prod.env и заполнить.

Порядок выкатки: сначала -p test, проверить, затем -p prod.

Откат на предыдущую версию: поднять предыдущий IMAGE_TAG (например, commit-sha).

Миграции БД

Накатываются сервисом migrate (Flyway) перед ботом, автоматически.

• Чистая БД — применяются все V__*/R__*.
• Существующая (непустая) БД — включён FLYWAY_BASELINE_ON_MIGRATE=true, Flyway сделает baseline и применит только новые миграции. Проверьте версию baseline.

Перенос данных со старого Postgres (короткое окно простоя)

1. Остановить старого бота.
2. pg_dump -Fc -f dump.pgc old_db
3. Развернуть новый контур, применить миграции (получится чистая целевая схема).
4. Загрузить данные:
   • либо pg_restore --data-only --disable-triggers -d new_db dump.pgc;
   • либо pg_dump --data-only и загрузка по таблицам.
5. Если в исходных данных есть дубли (tg_users/de_users/unsubscribe) — V12 убирает их перед созданием PK; при загрузке после миграций дедуп нужно сделать вручную до вставки.
6. Сверить: число пользователей, SUM(money.amount), число сообщений.
7. Переключить бота на новый Postgres, проверить команды, удалить старый контур.

Бэкап старой БД — обязательно. Проверить восстановление (dry-run) до окна.

Автобэкапы нового Postgres: pg_dump по cron + ротация, с выгрузкой на домашний сервер/в облако.

Reverse proxy и TLS (Блок 2.4)

Пока нечего проксировать (админка/Mini App — Блоки 4–5). Когда появятся:

• положить deploy/Caddyfile и раскомментировать сервис caddy в docker-compose.prod.yml;
• направить DNS admin.*/app.* на сервер, открыть 80/443;
• Caddy сам выпустит сертификаты.

Порт, не забыть закрыть наружу всё, кроме 80/443 (Postgres и ClickHouse — только внутри).

Firewall (заметка по SSH-доступу)

• SSH git у Forgejo — контейнерный порт 22 → на хосте 2222.
• Из локальной сети: ssh://git@192.168.31.158:2222/....
• Снаружи нужен проброс/открытие 2222 (и в Forgejo [server] SSH_DOMAIN/SSH_PORT).