mirror of
https://origin.cursor.com/mrdevmx/panels.git
synced 2026-10-09 14:33:17 +00:00
1ac04996b6
Scripts create-accesses / verify-connectivity para un Postgres+Redis+bucket por ambiente. /v1/health y el arranque de la API incluyen sonda de storage. Co-authored-by: alberto.martinez <alberto.martinez@mrdev.mx>
110 lines
4.3 KiB
Markdown
110 lines
4.3 KiB
Markdown
# Aprovisionamiento de infraestructura (Fase 0)
|
|
|
|
Scripts para dejar Postgres y Redis listos, en cualquier ambiente (dev local,
|
|
staging o producción en Coolify), antes de correr Liquibase o levantar la API.
|
|
Ver el plan de migración para el diseño completo: dos bases de datos
|
|
(`panels_platform`, `panels_product`) y, dentro de `panels_product`, dos
|
|
esquemas (`iam`, `core`).
|
|
|
|
## Orden de ejecución (Postgres)
|
|
|
|
Contra el servidor Postgres del ambiente (uno por dev/staging/producción),
|
|
como usuario superusuario/admin:
|
|
|
|
```bash
|
|
SUPERUSER_URL="postgresql://postgres:adminpass@HOST:5432/postgres"
|
|
|
|
# 1. Roles cluster-wide (genera una clave distinta por rol y por ambiente:
|
|
# openssl rand -hex 24). Pasar los valores SIN comillas propias -- el
|
|
# script usa :'var' internamente para escaparlos como literal SQL.
|
|
psql "$SUPERUSER_URL" \
|
|
-v platform_owner_pw="..." -v platform_app_pw="..." \
|
|
-v iam_owner_pw="..." -v iam_app_pw="..." \
|
|
-v core_owner_pw="..." -v core_app_pw="..." \
|
|
-f 01-roles.sql
|
|
|
|
# 2. Bases de datos (panels_platform, panels_product)
|
|
psql "$SUPERUSER_URL" -f 02-databases.sql
|
|
|
|
# 3. Privilegios dentro de panels_platform
|
|
psql "${SUPERUSER_URL%/postgres}/panels_platform" -f 03-platform-database.sql
|
|
|
|
# 4. Esquemas + privilegios dentro de panels_product
|
|
psql "${SUPERUSER_URL%/postgres}/panels_product" -f 04-product-database.sql
|
|
```
|
|
|
|
Las conexiones que usará la API (secrets por ambiente):
|
|
|
|
| Secret | Apunta a | Usuario |
|
|
|---|---|---|
|
|
| `DATABASE_URL_PLATFORM` | `panels_platform` | `panels_platform_app` |
|
|
| `DATABASE_URL_IAM` | `panels_product` (search_path=iam) | `panels_iam_app` |
|
|
| `DATABASE_URL_CORE` | `panels_product` (search_path=core) | `panels_core_app` |
|
|
|
|
Liquibase (paso de deploy, no en runtime) usa los roles `_owner`:
|
|
`DATABASE_URL_PLATFORM_OWNER`, `DATABASE_URL_IAM_OWNER`, `DATABASE_URL_CORE_OWNER`.
|
|
|
|
## Redis
|
|
|
|
```bash
|
|
REDIS_ADMIN_URL="redis://:adminpass@HOST:6379" \
|
|
IAM_REDIS_PASSWORD="$(openssl rand -base64 32)" \
|
|
CORE_REDIS_PASSWORD="$(openssl rand -base64 32)" \
|
|
./05-redis-acl.sh
|
|
```
|
|
|
|
Secrets resultantes: `REDIS_URL_IAM` (`redis://panels_iam_redis:<pw>@HOST:6379`),
|
|
`REDIS_URL_CORE` (`redis://panels_core_redis:<pw>@HOST:6379`).
|
|
|
|
El script verifica automáticamente que cruzar de módulo devuelva `NOPERM`
|
|
(ver "Riesgos y mitigaciones" del plan: un prefijo de llave sin ACL detrás
|
|
no aísla nada).
|
|
|
|
## Accesos de un ambiente (Coolify + Contabo)
|
|
|
|
**1 Postgres + 1 Redis + 1 bucket por ambiente.** El servidor lo crea
|
|
Coolify/Contabo; este repo solo genera roles y valida que contesten.
|
|
|
|
1. En Coolify: recurso Postgres y recurso Redis de **ese** ambiente.
|
|
En Contabo: bucket (ej. `panels-prod` / `panels-staging`) + access key.
|
|
2. Generar secretos y crear roles/ACLs contra esos hosts:
|
|
|
|
```bash
|
|
export PGHOST=... PGUSER=postgres PGPASSWORD=... # admin que da Coolify
|
|
export REDIS_ADMIN_URL="redis://:...@host:6379"
|
|
export S3_ENDPOINT=https://usc1.contabostorage.com
|
|
export S3_BUCKET=panels-prod
|
|
export S3_ACCESS_KEY_ID=... S3_SECRET_ACCESS_KEY=...
|
|
./db/provision/create-accesses.sh --apply --verify --out .env.prod.local
|
|
```
|
|
|
|
3. Pegar el contenido de `.env.prod.local` (gitignored) en las env del `api`.
|
|
4. Sin `--apply`, el script solo imprime el bloque; no toca servidores.
|
|
|
|
Comprobar conectividad después, sin reprovisionar:
|
|
|
|
```bash
|
|
set -a && source .env.prod.local && set +a
|
|
REQUIRE_S3=1 ./db/provision/verify-connectivity.sh # staging/prod
|
|
./db/provision/verify-isolation.sh
|
|
```
|
|
|
|
## Qué falta hacer manualmente en Coolify (staging/producción)
|
|
|
|
Estos scripts asumen que ya existe un servidor Postgres y un servidor Redis
|
|
accesibles (el recurso gestionado de Coolify por ambiente). El agente no
|
|
tiene acceso a la cuenta de Coolify del usuario, así que:
|
|
|
|
1. Crear el recurso Postgres gestionado en Coolify para el ambiente.
|
|
2. Crear el recurso Redis gestionado en Coolify para el ambiente.
|
|
3. Crear el bucket Contabo de ese ambiente.
|
|
4. Correr `create-accesses.sh --apply --verify` (o los SQL 01-04 + `05-redis-acl.sh`).
|
|
5. Cargar los secrets resultantes (`DATABASE_URL_*`, `REDIS_URL_*`, `S3_*`)
|
|
en la configuración del servicio `api` de ese ambiente.
|
|
|
|
## Desarrollo local
|
|
|
|
`db/provision/dev-local.sh` reproduce estos mismos pasos contra un Postgres
|
|
y Redis instalados en la máquina de desarrollo (sin Coolify), generando
|
|
`.env.dev-local` con las URLs resultantes — útil para correr la API y los
|
|
tests sin depender de infraestructura externa.
|