# 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.