nuria.blog
Blog: Infraestructura

Automatizando la infraestructura como código

2026.10, 4 min lectura, Terraform, FastAPI, CI/CD

De la petición al apply, sin tocar Terraform a mano. Un FastAPI de 30+ endpoints genera el código, abre los PRs y deja que la CI calcule el plan; una persona revisa y aplica. Así gestionamos hoy gran parte de nuestra infraestructura.

01. La premisa

A falta de kumoss, nos lo construimos

A falta de que me dejen construir un kumoss Gestión de infra con agentes que generan IaC a partir de lenguaje natural, hace unos meses quemé todos los tokens del plan de Copilot con Opus 4.8 y Haiku 4.5 para construir en una sola semana este workflow, que hoy automatiza una gran parte de nuestra infraestructura.

1
equipo
15+
cuentas
10+
módulos
8
repositorios

Llevar tantas cuentas desde un equipo responsable de tecnologías muy distintas es todo un reto, y mantener todo el código, aún más. Por eso creamos este automatismo: un FastAPI con más de 30 endpoints desde el que gestionamos todo el código de creación y modificación de infraestructura como código con Terraform.

En cada endpoint indicamos los parámetros necesarios (cuenta, zona, entorno, aplicación, etc.), lo que nos permite ser mucho más eficientes y evitar errores de código. Desde montar cuentas desde cero hasta añadir recursos en cuentas ya inicializadas.

02. El mapa

El flujo, en una imagen

Diagrama del workflow IaC: petición en FastAPI, repos de Terraform por módulos, plan en el PR, revisión humana, merge y apply
fig. 01, FastAPI + repos de Terraform por módulos y plan antes de la revisión
03. Paso a paso

De la petición al apply

  1. Petición.

    Desde Swagger UI, el equipo indica qué desplegar: cuenta, módulo y parámetros. Un permiso concreto o una cuenta entera.

  2. La API resuelve el módulo.

    Valida los parámetros y los mapea al repositorio correspondiente (tf-iam, tf-security, tf-redes…).

  3. Generación y PR automático.

    La API clona el repo, crea una rama, genera el Terraform y abre un Pull Request.

  4. Plan en el PR.

    La CI ejecuta terraform plan desde la rama, contra el state de esa cuenta, y deja el resultado como comentario en el PR.

  5. Revisión humana.

    Una persona revisa diff e impacto real (no solo el código). Si pide cambios, el ciclo se repite con un plan nuevo en cada push.

  6. Merge, replan y apply.

    Tras la aprobación llega el merge a main, un plan rápido de comprobación por si algo cambió en el ínterin, y el apply.

Un permiso concreto es un PR en tf-iam; una cuenta entera son N PRs, uno por módulo.
La regla que lo ordena todo
04. Los resultados

Lo que nos ha dado

  • De horas a minutos en cada despliegue.
  • Menos incidentes: parámetros validados y nada aplicado a ciegas.
  • Auditoría completa: cada cambio es un PR con su plan, su revisor y su apply trazados.

Lo que empezó como un experimento de una semana acabó siendo la puerta de entrada para tocar cualquier cuenta: el plan, la revisión y el apply siguen siendo nuestros, solo el camino hasta ellos es automático.

#iac #terraform #fastapi #ci-cd #aws #devops
← más posts lo que hice con la IA: IA con conciencia →