Infraestructura como código con Terraform y herramientas nativas
Describir la infraestructura en archivos versionados cambia menos de lo que parece en el primer despliegue y mucho de lo que parece en el décimo. La pieza que hay que entender antes de escribir la primera línea no es el lenguaje: es el estado.
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
Crear la infraestructura a mano en la consola funciona perfecto una vez. El problema aparece después: reproducirla en otro entorno, saber quién cambió qué, y contestar por qué producción no se parece a desarrollo.
La infraestructura como código resuelve las tres cosas con la misma idea: el archivo es la descripción deseada y la herramienta se encarga de que la realidad coincida. Lo que cuesta entender no es la sintaxis, es que para comparar deseo con realidad hace falta guardar un estado.
Declarativo, no una lista de pasos
| Script imperativo | Descripción declarativa | |
|---|---|---|
| Qué escribís | Los pasos: creá, después modificá | El resultado: quiero esto |
| Correrlo dos veces | Puede duplicar o fallar | No cambia nada: ya está como se pidió |
| Cambiar algo | Escribir el paso de la modificación | Editar la descripción; la herramienta calcula la diferencia |
| Saber qué va a pasar | Leyendo el script | Un plan previo que lista altas, cambios y bajas |
El plan previo es el hábito que más vale la pena adoptar: antes de aplicar nada, la herramienta muestra exactamente qué va a crear, qué va a modificar y qué va a destruir. Leer esa última columna antes de confirmar es lo que separa un cambio de rutina de un incidente.
El estado: la pieza que hay que cuidar
Para calcular la diferencia, la herramienta necesita saber qué creó antes y con qué atributos. Eso es el archivo de estado, y es el componente más delicado del esquema.
Reglas del estado que no se negocian
- Remoto y compartido, no en la máquina de quien aplica: en un bucket o en el servicio gestionado de la herramienta.
- Con bloqueo, para que dos personas o dos pipelines no apliquen a la vez y lo corrompan.
- Con versionado, porque es lo único que permite volver atrás si queda inconsistente.
- Tratado como secreto: guarda valores en claro —contraseñas generadas, cadenas de conexión— aunque la definición los tenga marcados como sensibles. Cifrado y con acceso restringido.
- Uno por entorno: producción y desarrollo con estados separados, y a ser posible con credenciales separadas.
Antes de seguir, predecí
Terraform o la herramienta del proveedor
| Terraform / OpenTofu | Nativa del proveedor | SDK en un lenguaje general | |
|---|---|---|---|
| Ejemplos | Terraform, OpenTofu | CloudFormation, Deployment Manager, Bicep | CDK, Pulumi, CDK for Terraform |
| Alcance | Multi-nube y servicios de terceros | Un proveedor, con integración total | Según el motor que use por debajo |
| Estado | Propio, hay que administrarlo | Del proveedor, no se administra | El del motor |
| Curva | Un lenguaje declarativo propio | Formato del proveedor | El lenguaje que ya se conoce |
| Cuándo elegirlo | Lo más común; también cubre DNS, monitoreo y bases | Una sola nube y preferencia por lo nativo | Lógica de composición compleja |
La elección importa menos que dos decisiones que se toman igual en las tres: módulos para no copiar y pegar la misma red en cada entorno, y entornos como variables en vez de carpetas duplicadas que se van desincronizando.
Aplicar desde un pipeline, no desde una máquina
El flujo que usa casi todo el mundo
- Un cambio en la descripción se propone como cambio de código y alguien lo revisa.
- El pipeline corre el plan automáticamente y lo deja visible: la revisión discute el plan, no la intención.
- Se aplica sólo desde el pipeline, con una identidad federada y sin claves guardadas.
- Producción exige una aprobación explícita antes de aplicar.
- Un chequeo de deriva periódico avisa si la realidad se apartó de la descripción.
Más a fondo · nivel seniorAdoptarlo sobre una infraestructura que ya existe
Casi nadie empieza de cero, y el modo de adopción define si la práctica prende o se abandona:
- Importar en vez de recrear. Todas las herramientas permiten adoptar recursos existentes, y varias generan la definición a partir de la realidad. Recrear producción “para hacerlo bien” no es una opción.
- Por capas, de abajo hacia arriba. Primero lo que cambia poco y lo sostiene todo —redes, identidades, claves—, después las bases, al final el cómputo. Así cada capa es un estado chico y un radio de impacto acotado.
- Estados chicos. Un estado gigante hace que cada plan tarde y que cualquier cambio tenga potencial de romper todo. Se parten por capa y por entorno, y se enlazan leyendo las salidas de uno desde el otro.
- Lo que queda afuera, escrito. Siempre hay algo creado a mano: dominios comprados, cuentas, alguna integración. Documentar qué no está en el código es parte de que el código sea confiable.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica