Lección 44 — Infraestructura como código (Terraform)

La infra de TicketFlow en ficheros. Sin solutions.md hasta entregar.

Ejercicio 1 — El inventario del clickops

1. Haz el inventario de TU infra actual (el compose del 40 cuenta como "infra manual"): lista cada recurso (BD, Redis, buckets, dominios, secretos) y marca: ¿está en código? ¿quién lo creó y cuándo? ¿se puede reconstruir desde cero?
2. El test del disaster recovery: en un entorno de lab, borra TODO (contenedores, volúmenes, ficheros de config sueltos) y reconstruye SOLO con lo que está en el repo. Cronometra. ¿Qué tuviste que recordar a mano? (eso es el clickops pendiente).
3. Escribe la regla del proyecto en CONTRIBUTING: todo recurso de la nube lleva su.tf; el clickops se reconcilia (import o destroy) en la semana.

Ejercicio 2 — El módulo de TicketFlow

1. Escribe el infra/main.tf del §2 completo para TU proveedor (o para GCP siguiendo el ejemplo): la red privada, el Postgres gestionado (con deletion_protection), el Redis, y el service del app con var.image_digest.
2. El multi-entorno: con var.env (dev/staging/prod), verifica que el mismo módulo produce 3 planes distintos: pega el diff del plan entre staging y prod (¿qué cambia? ¿tier, HA, maxScale?).
3. El plan leído: introduce a propósito un forces replacement (cambia el nombre de la instancia Redis) y lee el plan: ¿qué destruye? ¿Qué harías para cambiar el nombre SIN perder datos (¿recurso nuevo + migración de datos, 11 aplicado a la infra)?

Ejercicio 3 — El state y el lock

1. Configura el backend remoto (GCS/S3) con lock nativo y el state por entorno (env/dev, env/staging, env/prod). Verifica el lock: dos terraform apply simultáneos (dos terminales) → ¿el segundo espera o falla con el mensaje del lock?
2. El drift: cambia a mano un recurso en la consola (o simula: edita el recurso fuera de Terraform) y corre terraform plan: ¿el plan lo detecta? ¿Qué opciones hay (import al código, revert del clickops, ignore)? Documenta el runbook del drift en 4 pasos.
3. El state y los secretos: inspecciona el state (terraform state pull | jq): ¿qué secretos están en claro? ¿Qué protección tiene el bucket del state (IAM, cifrado, versionado del bucket)? Documenta la decisión.

Ejercicio 4 — Secretos y destrucción

1. Mueve los secretos fuera del.tf: el secret existe como recurso (Secret Manager) pero el VALOR lo sube el pipeline del 41 (o un gcloud secrets versions add manual con la rotación dual del 27). Verifica: grep -r "secret_value" infra/ vacío.
2. La ceremonia del destroy: añade prevent_destroy al módulo de la BD y prueba terraform destroy en dev: ¿qué mensaje recibe? Después: el destroy LEGÍTIMO del entorno efímero (¿cómo se distingue? ¿una variable ephemeral = true que relaja el guard en dev?).
3. El staging nocturno: escribe el job del 31 (o el cron del proveedor) que destruye el staging a las 21:00 y lo re-crea a las 8:00 con terraform apply. ¿Cuánto cuesta el ahorro mensual con los números del 42? ¿Qué rompe este patrón (¿los datos de staging? ¿la BD del restore drill)?

Ejercicio 5 — El ADR y el drill final

1. El ADR de cierre: "La infra de TicketFlow es código" — decisiones (backend del state, lock, state por entorno, secretos en el gestor, digest como input) en 12 líneas con el umbral de revisión.
2. El drill: entono limpio → terraform apply desde cero → el smoke del 35 en verde. Cronometra el tiempo total (el objetivo del §5: <30 min). ¿Qué parte es la más lenta (¿el provision del SQL? ¿el DNS?) y cómo se mitiga?
3. El diagrama final del módulo: el flujo commit→CI (41)→digest→plan→apply→smoke en ASCII con los candados (state lock, deletion_protection, prevent_destroy). Este diagrama ES el README del directorio infra/.

Entrega

Pega el inventario del clickops, el diff del plan multi-entorno, la evidencia del lock del state y el drill cronometrado. Después: Lección 45 — Logs estructurados (módulo 10).