DispelEvilBot/deploy/README.md

88 lines
4.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Деплой (Блок 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`).