Ansible y Pulumi: dos filosofías de automatización conviviendo

Actualizado: 2026-05-03

Ansible y Pulumi se comparan a menudo pero resuelven problemas distintos. Ansible es configuration management: qué está instalado en un servidor, ficheros de configuración, usuarios, servicios. Pulumi es Infrastructure as Code: qué recursos cloud existen (VPCs, instancias, balanceadores, buckets). Usarlos juntos es un patrón maduro y productivo. Este artículo cubre cómo combinarlos sin duplicar trabajo.

Puntos clave

• Ansible controla el estado dentro de un servidor; Pulumi controla qué servidores existen.
• Los dos tratan de automatización, pero en capas distintas del stack.
• Para greenfield cloud-native puro, a veces basta con Pulumi solo; para legacy híbrido, Ansible sigue siendo pieza fundamental.
• El inventario dinámico desde outputs de Pulumi es el pegamento natural entre ambas herramientas.
• No elegir Terraform y Pulumi a la vez: son alternativas, no complementos.

La división natural

Pulumi — infraestructura

• Crear VPCs, subnets, security groups.
• Aprovisionar instancias, bases de datos, buckets.
• Configurar DNS y certificados.
• Managed services (RDS, Redshift, clusters Kubernetes).

Ansible — configuración

• Instalar paquetes en servidores.
• Desplegar aplicaciones.
• Gestionar usuarios y claves SSH.
• Ficheros de configuración (nginx.conf, postgresql.conf).
• Orquestar operaciones (rolling restarts, patches).

Aunque los dos son “automatización”, operan en capas distintas. Mezclarlos es natural; duplicarlos, un antipatrón.

Ejemplo concreto: stack completo

Pulumi crea la infraestructura en TypeScript:

import * as aws from "@pulumi/aws";

const vpc = new aws.ec2.Vpc("main", { cidrBlock: "10.0.0.0/16" });
const subnet = new aws.ec2.Subnet("private", {
  vpcId: vpc.id,
  cidrBlock: "10.0.1.0/24",
});
const instance = new aws.ec2.Instance("web", {
  ami: "ami-xxx",
  instanceType: "t3.medium",
  subnetId: subnet.id,
});

export const instanceIp = instance.publicIp;

Ansible configura lo que corre en ella:

- hosts: web
  tasks:
    - apt:
        name: [nginx, postgresql-client]
        state: present
    - template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: restart nginx
  handlers:
    - name: restart nginx
      systemd:
        name: nginx
        state: restarted

Los dos juntos cubren el stack completo sin que ninguno invada el territorio del otro.

Pulumi frente a Terraform

Pulumi es una alternativa a Terraform con código real (TypeScript, Python, Go, .NET) en lugar de HCL:

Ventajas de Pulumi:

• Bucles y condicionales nativos del lenguaje.
• Abstracciones reutilizables (clases, funciones).
• Testing con el framework de tests estándar del lenguaje.
• Autocompletado completo en el IDE.

Desventajas:

• Mayor carga cognitiva (programar vs. declarar).
• Comunidad más pequeña que Terraform.
• Algunas features nuevas llegan antes a Terraform o OpenTofu.

La decisión entre Pulumi y Terraform/OpenTofu es una preferencia de equipo. Ambos hacen IaC cloud-agnostic competentemente.

Inventario dinámico desde Pulumi

El pegamento entre las dos herramientas es el inventario dinámico: Ansible lee las IPs y endpoints de los outputs de Pulumi en lugar de mantener un fichero estático.

# pulumi_inventory.py
import pulumi.automation as auto

stack = auto.select_stack(...)
outputs = stack.outputs()

print({
    "web": {
        "hosts": [o.value for o in outputs["instance_ips"].value]
    }
})

Ansible consume este inventario dinámicamente con ansible -i pulumi_inventory.py all -m ping. El pipeline de CI/CD queda limpio: Pulumi aplica primero, Ansible recoge los outputs y configura.

Flujo productivo en CI/CD

1. Pulumi crea o actualiza la infraestructura.
2. Pulumi exporta outputs (IPs, endpoints, credenciales).
3. Ansible recibe los outputs como inventario dinámico.
4. Ansible configura apps, usuarios y servicios.
5. Ambos corren en el mismo pipeline: tofu/pulumi plan → apply → ansible-playbook.

Antipatrones a evitar

• Pulumi configurando cosas dentro de la VM: scripts user-data complicados. Mejor Ansible para eso.
• Ansible creando recursos AWS: los módulos amazon.aws.* existen pero para más de diez recursos, Pulumi es más mantenible.
• Terraform + Pulumi a la vez: elige uno de IaC. Dos herramientas para la misma capa es duplicación, no complemento.

Casos donde basta con uno solo

Solo Ansible:

• On-premise legacy sin infra cloud que aprovisionar.
• VMs estáticas donde la infra no cambia.
• Dispositivos de red (Cisco, Juniper): Ansible tiene módulos excelentes.

Solo Pulumi:

• Todo corre en managed services o contenedores.
• Entorno Kubernetes-native donde los manifests generados cubren la configuración.
• Cloud-only sin VMs que configurar.

Secretos

Ansible Vault cifra ficheros YAML de forma integrada. Para producción seria, integrar con un secret manager externo (HashiCorp Vault, AWS SSM) es el camino correcto.

Pulumi cifra secretos en el estado con Config.setSecret() e integra con AWS SSM, Azure Key Vault y HashiCorp Vault. El patrón es el mismo: nunca secretos en texto claro en el repositorio.

ROI típico de adoptar IaC + Config Management

El retorno es asimétrico en el tiempo:

• Primer mes: negativo (tiempo de setup).
• Tres meses: equilibrio.
• Un año: ahorro del 40-60 % en operaciones repetitivas.
• Dos años en adelante: disaster recovery en minutos en lugar de días.

El valor se acumula. No empezar es un coste invisible que crece cada semana que pasa.

Conclusión

Ansible y Pulumi son complementarios, no competidores: Pulumi (o Terraform/OpenTofu) para infraestructura, Ansible para configuration management. Para infraestructura cloud con servidores, combinarlos es el stack más limpio y mantenible. Equipos que entienden esta división tienen una automatización más predecible y menos incidentes operativos. Si ya tienes CrowdSec u otro componente que gestionar en tus nodos, Ansible es la herramienta natural para esa capa.