Terraform vs. Ansible: ¿Cuál realmente necesitas?

Las personas nuevas en Infrastructure as Code usualmente hacen esta pregunta de una de dos formas: "qué herramienta debo aprender primero" o "por qué los equipos usan ambas". La respuesta corta es que Terraform y Ansible resuelven problemas diferentes, y la mayoría de los setups de producción las usan juntas en lugar de elegir una.

Para qué sirve realmente Terraform

Terraform es una herramienta de provisioning. Declara qué infraestructura debería existir: una VPC, tres instancias EC2, una base de datos RDS, un bucket S3 con una política específica. Escribes HCL describiendo el estado final, ejecutas terraform plan para ver qué cambiará, luego terraform apply para que suceda. Terraform mantiene un archivo de estado (localmente o en un backend como un bucket S3 con DynamoDB locking) que mapea tu configuración a IDs de recursos reales en el proveedor de nube.

La fortaleza aquí es la resolución de dependencias entre proveedores. Si le dices a Terraform que cree un security group y luego lo adjunte a una instancia EC2, determina el orden automáticamente. También funciona en AWS, Azure, GCP, Cloudflare, Datadog y docenas de otros proveedores a través del mismo flujo de trabajo, lo que importa una vez que tu infraestructura abarca más de un proveedor.

Terraform es malo en cualquier cosa que suceda dentro de la máquina una vez que existe. No instala paquetes, edita archivos de configuración, o reinicia servicios de ninguna forma significativa y continua. Existen provisioners como remote-exec pero el mismo HashiCorp recomienda evitarlos para cualquier cosa más allá del bootstrapping.

Para qué sirve realmente Ansible

Ansible es una herramienta de configuration management. Se conecta por SSH (o WinRM para Windows) y ejecuta tareas contra máquinas que ya existen: instalar nginx, templating de un archivo de configuración, crear un usuario, reiniciar un servicio, asegurar que un cron job esté presente. Los playbooks son YAML, y los módulos son idempotentes por diseño, así que ejecutar el mismo playbook dos veces no debería cambiar nada la segunda vez si el sistema ya coincide con el estado deseado.

Ansible no necesita agentes instalados en los hosts de destino, solo Python y acceso SSH, lo que facilita acoplarlo a infraestructura existente. También es bueno en tareas de orquestación que no son estrictamente "provisioning" — reinicios rodantes en una flota, pasos de blue-green deploy, ejecutar una migración de base de datos en un host y luego actualizar un load balancer.

Dónde se superponen y dónde la gente se confunde

Ambas herramientas pueden técnicamente hacer un poco del trabajo de la otra. Ansible tiene módulos de nube (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) que pueden generar infraestructura. Terraform tiene provisioners que pueden ejecutar comandos shell en una instancia nueva. Pero usar Ansible para provisioning significa renunciar al rastreo de estado y al flujo de trabajo plan/diff de Terraform, y usar Terraform provisioners para configuración significa renunciar a la configuration management idempotente y repetible.

La división práctica en la que la mayoría de los equipos desembarcan:

• Terraform construye la infraestructura: redes, instancias de computación, load balancers, bases de datos gestionadas, roles IAM.
• Ansible configura lo que hay encima: instalaciones de software, usuarios, archivos de configuración, estado de servicios, pasos de despliegue de aplicaciones.

Un ejemplo concreto del handoff

Di que estás levantando tres servidores web detrás de un load balancer en AWS.

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Terraform crea las instancias y produce sus IPs. Puedes alimentar esa salida a un inventario dinámico de Ansible (el plugin de inventario amazon.aws.aws_ec2 lee etiquetas de EC2 directamente, sin necesidad de copiar-pegar manual) y luego ejecutar:

ansible-playbook -i aws_ec2.yml site.yml

donde site.yml instala nginx, coloca la configuración de la app, e inicia el servicio. Terraform nunca toca nginx. Ansible nunca toca la VPC. Cada herramienta se mantiene en su carril, y cada una tiene su propio modelo de estado/idempotencia que no entra en conflicto con el del otro.

Errores comunes que vale la pena evitar

Almacenar estado de Terraform en git es el error más común al principio — los archivos de estado pueden contener secretos en texto plano y causar conflictos de merge que corrompan tu modelo de infraestructura. Usa un backend remoto desde el primer día.

Con Ansible, el error es escribir playbooks que no sean realmente idempotentes — usar módulos shell o command para cosas que tienen un módulo adecuado (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) que ya maneja la lógica check-then-act correctamente.

Si estás decidiendo qué aprender primero: aprende Terraform si haces provisioning en la nube y setups multiambiente, aprende Ansible si estás gestionando config drift en servidores que ya tienes. La mayoría de los roles DevOps esperan familiaridad con ambas en el primer año.

Para más sobre state management, inventarios dinámicos, y construir un pipeline CI/CD completo alrededor de estas herramientas, revisa los segmentos relacionados de DevOps y Cloud en Korra Studio.