panels-origin/db/provision/README.md

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:

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

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:

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:

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.