Terraform en equipo: organización del estado, radio de impacto y planes revisados

El archivo de estado es la frontera real

Cada terraform apply puede cambiar cualquier cosa del estado sobre el que trabaja. Eso convierte al estado, y no al módulo, en la unidad de riesgo. Con un único estado para todo un entorno, una errata en un registro DNS y un cambio en la base de datos de producción pasan por el mismo plan — y ese plan tarda minutos en calcularse.

Divida por ciclo de vida y radio de impacto

Agrupe los recursos que cambian juntos y fallan juntos. Una organización habitual separa, en cada entorno:

• Base: cuentas, redes, zonas DNS — cambian rara vez.
• Datos: bases de datos, buckets, colas — cambian con cuidado y están protegidos contra borrado.
• Cómputo y servicios: clústeres, funciones, balanceadores — cambian a menudo.

Cada capa lee las salidas de la capa inferior y nunca gestiona sus recursos. Los entornos comparten los mismos módulos, pero con estado y credenciales separados, para que un apply en staging no pueda tocar producción.

Estado remoto, bloqueo y versiones

• Guarde el estado en un backend remoto con bloqueo y versionado activados — nunca en Git y nunca en un portátil.
• Haga commit del lock file de dependencias (.terraform.lock.hcl) y fije las versiones de los módulos, para que un plan hoy y otro el mes que viene ejecuten el mismo código.
• Proteja los recursos con estado con prevent_destroy y con la protección contra borrado del propio proveedor.

Plan en cada pull request, apply de lo revisado

Ejecute terraform plan en CI para cada cambio y publique el resultado en el pull request. Tras la aprobación, aplique el plan guardado en lugar de planificar de nuevo, para que producción reciba exactamente lo que leyeron los revisores; si el estado cambió entretanto, Terraform rechaza el plan obsoleto. El pipeline debe autenticarse con credenciales de corta duración mediante federación OIDC, no con claves de larga duración guardadas como secretos.

terraform init -input=false
terraform plan -input=false -lock-timeout=5m -out=tfplan
terraform show -no-color tfplan > plan.txt   # attach to the pull request

# after approval, applying the same saved plan:
terraform apply -input=false tfplan

Detecte el drift periódicamente

Los cambios desde la consola siguen ocurriendo, normalmente durante incidentes. Un job programado que ejecute terraform plan -detailed-exitcode los encuentra: el código de salida 0 significa sin cambios, 2 significa que la infraestructura real difiere del código y 1 significa un error. Convierta un 2 en ticket y luego incorpore el cambio al código o reviértalo.

Políticas antes del apply

Reglas como «ningún bucket público» o «todo recurso tiene una etiqueta de responsable» las comprueba mejor una máquina que un revisor al final de un día largo. Herramientas de políticas como código, como Open Policy Agent mediante Conftest, pueden evaluar la forma JSON del plan (terraform show -json) en CI y bloquear el merge.