Infrastructure as Code con Terraform

Es la práctica de describir la infraestructura —servidores, redes, bases de datos, balanceadores de carga y demás recursos— en archivos de texto versionados, en lugar de crearla y configurarla manualmente haciendo clic en la consola de un proveedor. El enfoque manual tiene tres problemas serios: es lento, es irrepetible porque nadie recuerda con exactitud qué se tocó, y es propenso a errores porque una diferencia mínima entre dos configuraciones hechas a mano lleva a que entornos que deberían ser idénticos dejen de serlo. La infraestructura como código resuelve todo esto al convertir la infraestructura en archivos que se guardan en un control de versiones, se revisan como cualquier cambio de código y se aplican de forma automática y reproducible. El mismo archivo puede levantar un entorno de pruebas y uno de producción idénticos, y sirve además como documentación siempre actualizada de qué recursos existen y con qué configuración, algo que con la creación manual se pierde inevitablemente.

Terraform es la herramienta más usada para hacer infraestructura como código. Funciona de manera declarativa: en sus archivos uno describe qué recursos quiere que existan y con qué características, y Terraform se encarga de calcular los pasos necesarios para llevar la infraestructura a ese estado, comunicándose con la interfaz de programación del proveedor correspondiente, por ejemplo una nube. Una de sus grandes ventajas es que trabaja con muchos proveedores distintos usando el mismo lenguaje, en lugar de obligar a aprender la herramienta específica de cada uno. Su flujo de trabajo gira en torno a dos operaciones: una que previsualiza exactamente qué cambios se harían sin tocar nada, y otra que aplica esos cambios y crea o modifica los recursos reales. Además, mantiene un registro llamado estado que le permite saber qué recursos gestiona y relacionarlos con el código, de modo que en cada ejecución solo cambie lo que hace falta en lugar de recrear todo.

El estado es un archivo que Terraform mantiene y en el que registra qué recursos ha creado y cómo se corresponden con cada bloque del código que los declara. Es fundamental porque es lo que le permite a Terraform, en cada ejecución, saber qué existe ya en la realidad y compararlo con lo que dice el código para determinar qué debe crear, modificar o destruir; sin el estado, Terraform no tendría forma de relacionar la configuración con la infraestructura real. Es también el elemento más delicado por dos motivos. Primero, suele contener datos sensibles como direcciones, identificadores y a veces secretos, por lo que nunca debe subirse a un repositorio y debe guardarse de forma remota, cifrada y con control de acceso. Segundo, si el estado se pierde, se corrompe o dos personas lo modifican simultáneamente sin coordinación, Terraform pierde la noción de qué gestiona y puede llegar a duplicar o destruir recursos; por eso el estado remoto incorpora un bloqueo que impide dos ejecuciones a la vez.

Son los dos pasos centrales del flujo de trabajo de Terraform y juntos son lo que hace seguro el proceso. El comando de plan compara lo que dice el código, lo que registra el estado y lo que existe realmente en el proveedor, y produce una previsualización detallada de qué recursos se crearían, cuáles se modificarían y cuáles se destruirían, sin aplicar ningún cambio todavía. El comando de apply toma esos cambios previstos y los ejecuta, creando o modificando los recursos reales y actualizando el estado para reflejar la nueva situación. La importancia de tener un paso de previsualización separado es enorme: permite verificar antes de confirmar que un cambio aparentemente inofensivo en el código no va a destruir por descuido, por ejemplo, una base de datos de producción. Leer con atención el resultado del plan, prestando especial cuidado a todo lo que aparezca marcado para destruirse, es la costumbre que distingue un uso responsable de Terraform de un accidente costoso.

Nunca en los archivos de configuración de Terraform, porque esos archivos se versionan en un repositorio y se comparten, de modo que cualquier contraseña, clave o token escrito ahí quedaría expuesto. Los secretos se guardan en un gestor de secretos dedicado y se inyectan en el momento de la ejecución, por ejemplo a través de variables de entorno o de la integración de Terraform con ese gestor. Hay además una consideración específica y muy importante: el propio archivo de estado de Terraform puede llegar a contener secretos en texto, porque registra los valores de los recursos creados, por lo que ese estado debe guardarse de forma remota, cifrada y con acceso restringido, y jamás subirse al repositorio. En síntesis, se aplica la misma regla universal que rige para el código fuente, las imágenes de contenedor y los pipelines —los secretos viven en un mecanismo aparte pensado para protegerlos— más el cuidado adicional de proteger el estado precisamente porque puede contenerlos.

No, resuelven problemas distintos y complementarios, y de hecho es común usarlos juntos. Terraform se ocupa de aprovisionar la infraestructura, es decir de crear y gestionar los recursos: levantar servidores, definir redes, crear bases de datos y balanceadores. Ansible, en cambio, se ocupa de la gestión de configuración, es decir de preparar lo que corre dentro de esos servidores una vez que existen: instalar paquetes, configurar servicios, desplegar aplicaciones y dejar el sistema en el estado deseado. Una forma clara de recordarlo es que Terraform construye la casa y Ansible la amuebla y la deja lista para vivir. En muchos flujos de trabajo, Terraform crea primero la infraestructura y luego Ansible configura las máquinas resultantes. Aunque hay cierto solapamiento y cada herramienta puede hacer algo del terreno de la otra, usar cada una para lo que hace mejor da resultados más limpios y mantenibles que forzar una sola a cubrir ambos roles.