Infraestructura como código con Terraform: guía práctica para empezar

Si tu infraestructura solo existe en una consola web y en la memoria de un par de personas, cada cambio es un riesgo y cada auditoría es una búsqueda del tesoro. La infraestructura como código lo resuelve: lo que existe está escrito, revisado y versionado.

Qué ganas

• Revisión. Cada cambio llega como pull request con un plan que dice exactamente qué se crea, cambia o destruye.
• Reconstrucción. Un entorno se puede volver a levantar desde el repositorio, no desde la memoria.
• Auditoría. La pregunta “¿quién cambió este firewall y cuándo?” se responde con el historial de Git.
• Entornos iguales. Staging y producción salen del mismo código, con distintas variables.

Quién hace qué

Herramienta	Para qué
Terraform / OpenTofu	Crear y cambiar recursos: servidores, redes, balanceadores, DNS, bases de datos gestionadas, permisos cloud
Terragrunt	Organizar muchos entornos y cuentas sin copiar código
Ansible	Configurar lo que corre dentro de los servidores: paquetes, servicios, usuarios, ficheros
Packer	Construir imágenes base de servidor ya preparadas
ArgoCD / GitOps	Desplegar en Kubernetes desde Git

Terraform u OpenTofu

En agosto de 2023 HashiCorp cambió la licencia de Terraform de MPL 2.0 a la Business Source License (BSL). La comunidad creó un fork, OpenTofu, que mantiene la licencia MPL 2.0 y está bajo la Linux Foundation. En febrero de 2025 IBM completó la compra de HashiCorp.

Para la mayoría de equipos que usan Terraform para su propia infraestructura no cambia nada práctico: el código, los providers y los módulos sirven en los dos. OpenTofu añade algunas funciones propias, como el cifrado del estado. Lo importante es elegir uno, fijar la versión y no mezclarlos en el mismo estado.

Paso a paso con una infraestructura que ya existe

1. Estado remoto con bloqueo

Terraform guarda en un fichero de estado qué recursos gestiona. Ese fichero va en un backend remoto (por ejemplo, almacenamiento de objetos) con bloqueo, para que dos personas no apliquen cambios a la vez, y cifrado, porque puede contener contraseñas. Nunca en Git.

2. Importar lo que ya existe

No recrees lo que funciona. Desde Terraform 1.5 puedes declarar bloques import y generar el código inicial con terraform plan -generate-config-out=generated.tf. Después limpias ese código, lo pasas a módulos y compruebas que terraform plan no propone ningún cambio. Ese “plan vacío” es la señal de que el código describe la realidad.

3. Módulos pequeños y versiones fijadas

Separa por entornos y por piezas (red, cómputo, DNS, base de datos), no un único fichero gigante. Fija las versiones de Terraform y de los providers y sube a Git el fichero .terraform.lock.hcl, para que todos usen exactamente lo mismo.

4. Plan en cada pull request, apply solo desde CI

Cada pull request ejecuta terraform plan y publica el resultado para que alguien lo revise. El apply lo hace el pipeline tras la aprobación, con credenciales que nadie tiene en su portátil. Así nadie cambia producción desde la consola “solo esta vez”.

5. Secretos fuera del código

Las contraseñas y claves no van en los ficheros .tf ni en las variables del repositorio. Se leen de un gestor de secretos o del almacén de secretos del CI, y se marcan como sensitive.

6. Control de drift

Alguien acabará tocando algo a mano. Un trabajo nocturno que ejecute terraform plan -detailed-exitcode (código de salida 2 significa que hay diferencias) y abra una incidencia lo detecta al día siguiente, no en la próxima caída.

7. Políticas y escaneo

Herramientas como Checkov o Trivy revisan el código antes del merge: buckets públicos, puertos abiertos a todo internet, cifrado desactivado. Son baratas de añadir y paran errores típicos.

Errores habituales

• Guardar el estado en Git o en el portátil de alguien.
• Intentar escribir toda la infraestructura de golpe en lugar de importar pieza a pieza.
• Un único estado para todo: cualquier cambio pequeño bloquea y arriesga todo lo demás.
• Ejecutar apply desde portátiles con credenciales de administrador.
• No fijar versiones de providers y descubrir cambios inesperados en el siguiente init.

Cómo lo hacemos nosotros

Pasamos infraestructuras de AWS, EKS y Hetzner a Terraform, Terragrunt y Ansible, con GitOps en Kubernetes. Puedes ver un ejemplo en el caso de DevOps para una fintech de pagos, y el alcance y precio en infraestructura como código. Si además quieres salir parcialmente de AWS o Azure, el código es el primer paso de una migración a nube europea.