Fase 2.3

OpenTofu vs Ansible

IaC vs Config Management · Dos Tools, Dos Roles

OpenTofu y Ansible no compiten, se complementan. Saber qué herramienta usar para cada tarea es una de las decisiones de arquitectura más importantes en infraestructura. Esta página explica la diferencia conceptual, muestra ejemplos prácticos y advierte sobre los anti-patrones más comunes.

La Diferencia Central

La diferencia no es técnica, es filosófica. OpenTofu es declarativo: describe el qué. Ansible es procedural: describe el cómo. Un mismo resultado (namespace creado) se logra por caminos completamente distintos.

OpenTofu

Declarativo — EL QUÉ

"Quiero un namespace llamado aiops con estas labels. Reconciliá el estado real para que coincida."

Ansible

Procedural — EL CÓMO

"Paso 1: conectar al cluster. Paso 2: verificar si el namespace existe. Paso 3: si no existe, crearlo con estas propiedades."

Seis Dimensiones de Comparación

Las diferencias entre OpenTofu y Ansible se manifiestan en cada aspecto del ciclo de vida de la infraestructura. Estas seis dimensiones cubren lo esencial.

Filosofía

OpenTofu Declarativa: se define el estado deseado. El tool reconcilia la realidad contra esa definición. Qué quiero que exista.

Ansible Procedural: se definen pasos para alcanzar un estado. El tool ejecuta tasks en orden. Cómo llegar a lo que quiero.

Idempotencia

OpenTofu Nativa. Si el recurso ya existe con las mismas propiedades, el plan muestra 0 cambios. Si se eliminó manualmente, se recrea. Garantizada por diseño.

Ansible Depende del módulo. Módulos como lineinfile, systemd o seboolean son idempotentes. Módulos como command o shell no lo son sin changed_when. Depende de la disciplina del autor.

Estado

OpenTofu State file persistente (terraform.tfstate). OpenTofu sabe qué recursos creó, sus IDs y metadata. El state es la fuente de verdad. State file = memoria del sistema.

Ansible Sin estado persistente. Ansible consulta el estado real del sistema en cada ejecución via módulos que inspeccionan (stat, find, shell). Cada run = fresh discovery del estado.

Orden de ejecución

OpenTofu OpenTofu construye un DAG (grafo dirigido acíclico) a partir de referencias entre recursos. Ejecuta en paralelo lo que puede y serializa lo que tiene dependencias. Automático: Tofu resuelve el orden.

Ansible Orden explícito definido por el autor. Plays, roles y tasks se ejecutan secuencialmente en el orden declarado. Handlers al final. Manual: el autor define el orden.

Drift Detection

OpenTofu tofu plan compara el state contra el estado real. Detecta cambios manuales, recursos eliminados fuera de Tofu, y divergencias en propiedades. Detecta y reporta divergencias.

Ansible No tiene concepto de drift. Cada ejecución vuelve a aplicar las tasks. Si algo se cambió manualmente, Ansible lo corrige (o no, según la task). Corrige sin preguntar (si la task lo permite).

Destrucción

OpenTofu tofu destroy elimina todo lo gestionado por este stack. Limpio, determinista, sin dejar huérfanos. Un comando = revertir todo.

Ansible No hay un equivalente directo. Para deshacer cambios de Ansible, se escribe otro playbook o se usan tasks con state: absent. Requiere planificación manual del rollback.

Ejemplos Prácticos

Tres escenarios concretos del proyecto donde se ve la diferencia entre usar OpenTofu y usar Ansible. En cada caso, uno es la herramienta correcta y el otro no.

OpenTofu

resource "kubernetes_namespace" "aiops" {
  metadata {
    name = "aiops"
  }
}

Cuándo usar: Cuando el namespace es parte de la infraestructura: otros recursos dependen de él. Tofu garantiza el orden de creación.

Ansible

- name: Crear namespace aiops
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Namespace
      metadata:
        name: aiops

Cuándo usar: Cuando el namespace se necesita como prerequisito para desplegar workloads, pero no es un recurso que Tofu deba gestionar.

OpenTofu

OpenTofu no tiene un provider nativo para gestionar SELinux. Se podría usar un provider community, pero no es la herramienta correcta: OpenTofu no configura sistemas operativos. Esa es la frontera entre IaC y Config Management.

Cuándo usar: No aplica. OpenTofu no configura sistemas operativos.

Ansible

- name: SELinux enforcing
  ansible.builtin.selinux:
    policy: targeted
    state: enforcing

Cuándo usar: Ansible es la herramienta natural para configurar SELinux. Es una tarea de configuración del SO, no de creación de infraestructura.

OpenTofu

OpenTofu no gestiona firewalls de sistema operativo. Para la capa de red cloud (OCI NSGs, AWS Security Groups), OpenTofu sí es la herramienta correcta. Pero firewalld es configuración del SO, dominio de Ansible.

Cuándo usar: En OCI, los NSGs se gestionan con OpenTofu. En el SO, firewalld se gestiona con Ansible. Dos tools, dos capas distintas.

Ansible

- name: Abrir puerto para k3s API
  ansible.posix.firewalld:
    port: "6443/tcp"
    zone: public
    permanent: true
    state: enabled

Cuándo usar: Ansible aplica reglas de firewalld en cada VM. Si se agrega un puerto nuevo, se agrega a la lista y se vuelve a correr el playbook.

División de Responsabilidades

En este proyecto, la frontera entre OpenTofu y Ansible es clara: OpenTofu crea infraestructura, Ansible configura sistemas operativos. No hay solapamiento: cada recurso tiene un solo owner.

OpenTofu gestiona:

Namespaces de Kubernetes
ConfigMaps (Prometheus, Grafana)
OCI VCN, subnets, NSGs
OCI Compute Instances (VMs)
OCI Vault y Object Storage
OCI Internet Gateway

Ansible gestiona:

Paquetes del SO (dnf)
SELinux (modo enforcing, booleanos)
Firewalld (zonas, puertos)
SSH (puerto, root login, password auth)
fail2ban (jail SSH)
dnf-automatic (actualizaciones de seguridad)

La regla de oro: si el recurso tiene un ID en un provider cloud o en Kubernetes, va con OpenTofu. Si es un archivo de configuración, un paquete o un servicio del sistema operativo, va con Ansible. Esta frontera evita el acoplamiento más común en proyectos de infraestructura.

Anti-patrones Comunes

Errores frecuentes al combinar IaC y Configuration Management. El proyecto los evita deliberadamente. Está diseñado con la frontera clara desde el día 1.

Usar Ansible para crear VMs en OCI (con modules de cloud)

Por qué no: Ansible crea, pero no trackea estado. Si la VM se borra, Ansible no sabe que existía. OpenTofu con state file es la herramienta correcta para crear infraestructura.

Usar OpenTofu con provisioners para instalar paquetes

Por qué no: Los provisioners de Tofu (local-exec, remote-exec, file) son de último recurso. No son idempotentes, no manejan errores como Ansible y crean acoplamiento entre infraestructura y configuración.

Duplicar recursos entre Ansible y OpenTofu

Por qué no: Si un recurso se crea con Tofu y también se declara en Ansible, los dos tools van a competir por gestionarlo. Cada recurso debe tener un solo owner.

Fase 2 Completada

Con IaC dominado, la Fase 3 introduce HashiCorp Vault: secrets management self-hosted en k3s, Vault Agent Injector y el flujo de inyección de secrets en pods.

Fase 3 · HashiCorp Vault