Отдельный от db+vaultwarden compose-файл (разный жизненный цикл, свой
deploy-workflow) — единственное место сбора для backend, лендинга и
каждой прокси-ноды, которые физически живут на других серверах.
Prometheus скрейпит наружу (сам ходит в /metrics на тех хостах — там
нужно только открыть порт метрик для IP этого VPS). Loki, наоборот,
принимает пуши логов ИЗВНЕ — порт 3100 публикуется наружу и обязательно
фильтруется firewall'ом по IP тех хостов.
Grafana не торчит в интернет напрямую (127.0.0.1-only) — единственный
вход через Caddy с forward_auth, гейтящим по cookie-сессии
netrunner-backend (GET /api/v1/admin/observability/check,
Owner/Moderator). 3 provisioned дашборда (backend/landing/прокси-ноды).
Список scrape-таргетов для прокси-нод (observability/targets/nodes.json)
генерится и заливается автоматически из netrunner-proxy при каждом
деплое нод — вручную ничего не поддерживается.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Синкает postgres/pg_hba.conf, postgres/init-backend-db.sh и scripts/backup.sh
на VPS (раньше копировался только docker-compose.yml). Самоподписанный
сертификат создаётся один раз, если ещё не существует — повторные деплои
его не трогают, чтобы не рвать открытые TLS-сессии рестартом контейнера.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Раньше предполагалось, что backend и БД живут на одном хосте и делят
Docker-сеть — на деле backend будет на отдельном, ещё не арендованном
VPS, а Postgres стоит здесь же, рядом с Vaultwarden. Возвращает свой
контейнер `db` (общий для обеих баз — vaultwarden создаётся через
POSTGRES_USER/POSTGRES_DB, вторая, для backend, через новый
postgres/init-backend-db.sh), публикует 5432 наружу с hostssl+TLS
(postgres/pg_hba.conf, самоподписанный сертификат генерируется один раз
прямо в deploy.yml). Backup-джоба (pg_dump обеих баз) тоже переехала
сюда из netrunner-backend — дампить логичнее там, где физически лежат
данные.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
DATA_VPS_IP, имя/юзер БД, домен/лог-левел/SIGNUPS_ALLOWED/SMTP-хост-порт-
security-username Vaultwarden — в vars (не секреты сами по себе). Пароли
(VW_DB_PASSWORD, SMTP_PASSWORD), ADMIN_TOKEN и SSH-ключ остаются в secrets.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Убирает собственный контейнер db — вместо своего Postgres подключается
внешней сетью (netrunner_grid, external: true) к netrunner-db из
netrunner-backend/docker-compose.prod.yml, в отдельной базе/юзере
(VW_DB_*, был DB_*). Экономит ресурсы на VPS, где раньше крутились бы
два отдельных Postgres-процесса. Добавляет пошаговый ранбук переноса
существующих данных со старого SQLite-инстанса (scripts/migrate-vaultwarden.md,
через checkpoint WAL + pgloader data-only на уже созданную diesel-схему).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Копия .github/workflows/deploy.yml — без изменений содержимого: тут нет
логина на ghcr.io (postgres/vaultwarden — публичные образы с Docker Hub),
менять было нечего. Секреты (DATA_VPS_IP, DATA_SSH_PRIVATE_KEY,
DATA_DB_*, VAULTWARDEN_*) нужно завести отдельно в Gitea — своё хранилище,
не шарится с GitHub Actions.
Раньше Vaultwarden жил на проде голым файлом (~/vaultwarden-data/docker-compose.yml)
без git/CI, на SQLite, с секретами прямо в файле. Здесь: Postgres вместо
SQLite, все секреты — только через .env, который на каждом деплое
пересобирается заново из GitHub Actions secrets (см. .env.example для
полного списка нужных переменных и .github/workflows/deploy.yml).
Важно: переключение DATABASE_URL на Postgres поверх уже существующего
./data/db.sqlite3 с реальными данными пользователей само по себе данные не
мигрирует — см. комментарий в docker-compose.yml.
nineap