Ansible vs Terraform en 2026: Infrastructure as Code y Preguntas de Entrevista DevOps

Ansible vs Terraform representa una de las preguntas de comparación más comunes en entrevistas DevOps, pero la formulación en sí revela una incomprensión: estas herramientas resuelven problemas diferentes. Ansible 2.20 maneja la gestión de configuración y despliegue de aplicaciones, mientras que Terraform 1.15 aprovisiona recursos de infraestructura. Entender cuándo cada herramienta sobresale, dónde se superponen y cómo se complementan diferencia a los ingenieros DevOps senior de aquellos que aún están aprendiendo los fundamentos.

Declarativo vs Procedural: La Diferencia Fundamental

Terraform utiliza un enfoque declarativo. Un archivo de configuración describe el estado final deseado, y Terraform calcula los cambios necesarios para alcanzarlo. Este enfoque funciona bien para infraestructura que necesita ser creada, modificada o destruida como una unidad.

# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow HTTP and HTTPS"
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Ejecutar terraform apply crea ambos recursos si no existen, o los actualiza para que coincidan con la configuración. Ejecutarlo nuevamente sin cambios no produce ninguna operación: Terraform compara la configuración con su archivo de estado y no encuentra nada que hacer.

Ansible utiliza un enfoque procedural con tareas ejecutadas en orden. Aunque los módulos de Ansible son frecuentemente idempotentes (ejecutarlos dos veces produce el mismo resultado), el playbook en sí describe una secuencia de acciones en lugar de un estado final.

# webserver.yml
- name: Configure web server
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    
    - name: Copy nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
    
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
  
  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

Cada tarea se ejecuta en secuencia. El patrón notify/handler proporciona cierto comportamiento declarativo: el handler se ejecuta solo una vez al final, independientemente de cuántas tareas lo activen.

Gestión de Estado: Un Tema Crítico en Entrevistas

Terraform mantiene un archivo de estado que mapea la configuración a recursos reales. Este estado rastrea IDs de recursos, dependencias y metadatos. Sin él, Terraform no puede determinar qué existe o qué necesita cambiar.

Ansible no tiene un archivo de estado equivalente. Se conecta a los sistemas objetivo y ejecuta tareas, dependiendo del estado actual del sistema y la idempotencia de los módulos. Esto hace que Ansible sea más simple para comenzar pero más difícil de rastrear cambios a lo largo del tiempo.

Una pregunta de entrevista común aborda la seguridad del archivo de estado. El estado de Terraform puede contener datos sensibles: contraseñas de bases de datos, claves API, identificadores de recursos. Los despliegues en producción almacenan el estado remotamente (S3, Azure Blob, Terraform Cloud) con cifrado y controles de acceso.

# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/infrastructure.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

La tabla DynamoDB proporciona bloqueo, evitando que dos ingenieros modifiquen el estado simultáneamente.

Cuándo Usar Cada Herramienta

Terraform sobresale en el aprovisionamiento de infraestructura en la nube: máquinas virtuales, bases de datos gestionadas, balanceadores de carga, roles IAM, VPCs. Maneja las dependencias entre recursos automáticamente y soporta todos los principales proveedores de nube a través de una sintaxis HCL consistente.

Ansible sobresale en la configuración de sistemas existentes: instalación de paquetes, gestión de usuarios, despliegue de código de aplicación, orquestación de despliegues multi-paso. Se conecta vía SSH (o WinRM para Windows) sin requerir agentes en las máquinas objetivo.

La zona de superposición causa confusión. Ambos pueden instalar software en una VM. Terraform puede usar provisioners para ejecutar scripts después de la creación de recursos. Ansible puede crear recursos en la nube a través de módulos como amazon.aws.ec2_instance. Pero usar cada herramienta fuera de su fortaleza conduce a problemas de mantenibilidad.

El Flujo de Trabajo Combinado en Producción

La mayoría de las organizaciones usan ambas herramientas juntas. Terraform aprovisiona la infraestructura y expone los detalles de conexión. Ansible consume esos outputs para configurar los sistemas.

# outputs.tf
output "web_server_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

output "db_endpoint" {
  value       = aws_rds_instance.main.endpoint
  description = "RDS endpoint for application config"
}

Un pipeline CI/CD ejecuta Terraform primero, captura los outputs, genera un inventario de Ansible dinámicamente, luego ejecuta playbooks contra la nueva infraestructura.

# ansible/inventory/aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
  instance-state-name: running
hostnames:
  - private-ip-address
groups:
  webservers: "'web' in tags.Role"
  databases: "'db' in tags.Role"

Este inventario dinámico consulta AWS directamente, agrupando instancias por sus tags. No se requiere gestión manual de IPs.

OpenTofu: El Fork Que Cambió el Panorama

HashiCorp relicenció Terraform bajo la Business Source License (BSL) en agosto de 2023. La comunidad respondió bifurcando Terraform 1.5 en OpenTofu, ahora alojado bajo la Linux Foundation.

A agosto de 2026, OpenTofu 1.11.6 sigue siendo un reemplazo directo para la mayoría de los flujos de trabajo de Terraform. La misma sintaxis HCL, el mismo ecosistema de providers, el mismo formato de estado. OpenTofu ha añadido funcionalidades no presentes en el binario open-source de Terraform: cifrado de estado, for_each para providers, y evaluación temprana de variables.

Para la preparación de entrevistas, entender la distinción de licencias es importante. BSL permite uso interno pero restringe la construcción de productos competidores. Las organizaciones preocupadas por el vendor lock-in o con requisitos de cumplimiento específicos pueden preferir la licencia MPL 2.0 de OpenTofu. La adquisición de HashiCorp por IBM en diciembre de 2024 añadió otra variable a las discusiones sobre relaciones con proveedores.

Preguntas de Entrevista DevOps Comunes

P: ¿Puede Ansible reemplazar a Terraform?

No efectivamente. Ansible puede crear recursos en la nube, pero carece de gestión de estado. Ejecutar el mismo playbook dos veces podría crear recursos duplicados. El archivo de estado de Terraform rastrea lo que existe y calcula cambios mínimos. Usar Ansible para lo que hace mejor: gestión de configuración.

P: ¿Cómo se manejan los secretos en Terraform?

Nunca commitear secretos al control de versiones. Usar variables de entorno, integración con Vault, o gestores de secretos de proveedores de nube. Marcar variables como sensibles para evitar que aparezcan en logs:

# variables.tf
variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password from Vault or environment"
}

P: ¿Qué es la idempotencia de Ansible?

Una operación idempotente produce el mismo resultado ya sea que se ejecute una o múltiples veces. El módulo apt con state: present instala un paquete si falta y no hace nada si ya está instalado. Escribir playbooks idempotentes previene cambios no intencionados en ejecuciones subsiguientes.

P: ¿Cómo se prueba el código de infraestructura?

Terraform: terraform validate verifica la sintaxis, terraform plan previsualiza cambios, y herramientas como Terratest ejecutan pruebas de integración. Ansible: ansible-lint detecta problemas, el modo --check realiza dry runs, y Molecule prueba roles contra contenedores.

Para una preparación más profunda de entrevistas sobre Terraform, consultar Terraform Interview Questions: Infrastructure as Code Complete Guide. Practicar de forma práctica con los módulos Terraform Basics y Ansible Configuration Management.

Compatibilidad de Versiones y Ecosistema

Versiones estables actuales a agosto de 2026:

La arquitectura de colecciones de Ansible separa la funcionalidad core de los módulos específicos de proveedores. La colección amazon.aws recibe actualizaciones independientemente del core de Ansible. Esto importa para el pinning de versiones en pipelines CI/CD.

El versionado de providers de Terraform sigue principios similares. Los archivos de lock (terraform.lock.hcl) aseguran versiones consistentes de providers entre miembros del equipo y sistemas CI.

# versions.tf
terraform {
  required_version = ">= 1.15.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}

Elegir Entre Ellos: Un Marco de Decisión

La pregunta raramente es Ansible o Terraform. La pregunta es qué herramienta maneja qué responsabilidad.

Para una visión completa de cómo estas herramientas encajan en los flujos de trabajo de despliegue modernos, consultar CI/CD Pipeline Interview Questions.

Lo Que Los Ingenieros Senior Deben Saber Sobre Ansible y Terraform

• Terraform gestiona el estado de infraestructura declarativamente; Ansible configura sistemas proceduralmente. Usar ambos juntos produce infraestructura mantenible.
• La seguridad del archivo de estado importa. Almacenar el estado de Terraform remotamente con cifrado y bloqueo habilitados.
• OpenTofu proporciona una alternativa con licencia MPL a Terraform con funcionalidades adicionales. La migración es directa para la mayoría de los flujos de trabajo.
• La idempotencia no es automática. Escribir playbooks que produzcan resultados consistentes en ejecuciones repetidas.
• El inventario dinámico elimina la gestión manual de hosts. Consultar proveedores de nube directamente para infraestructura actual.
• El pinning de versiones previene sorpresas. Bloquear versiones de providers en Terraform; fijar versiones de colecciones en Ansible.
• Probar código de infraestructura requiere enfoques diferentes: terraform plan para previsualizar cambios, modo --check para dry runs de Ansible, frameworks de pruebas de integración para ambos.