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

## Образы и registry

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

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

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

```bash
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` сервисов):

```bash
# прод
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`).