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

javi
Engranajes metálicos entrelazados representando automatización cooperativa

Ansible y Pulumi se comparan a menudo pero resuelven problemas distintos. Ansible es configuration management: qué está instalado en un server, config files, usuarios, servicios. Pulumi es Infrastructure as Code: qué recursos cloud existen (VPC, instancias, load balancers, buckets). Usarlos juntos es pattern común y productivo — este artículo cubre cómo combinar sin duplicar effort.

La división natural

Pulumi — Infrastructure

  • Crear VPCs, subnets, security groups.
  • Provisionar instancias, databases, buckets.
  • Configurar DNS, certificados.
  • Managed services (RDS, Redshift, K8s clusters).

Ansible — Configuration

  • Instalar paquetes en servers.
  • Desplegar aplicaciones.
  • Gestionar users y SSH keys.
  • Config files (nginx.conf, postgresql.conf).
  • Orquestar operaciones (rolling restarts, patches).

Los dos tratan de automatización pero en niveles distintos.

Ejemplo concreto

Pulumi crea infrastructure:

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 stack completo.

Pulumi vs Terraform

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

Ventajas:

  • Loops, conditionals nativos.
  • Abstracciones: clases, funciones reusables.
  • Test con unit testing estándar.
  • IDE autocomplete completo.

Desventajas:

  • Más cognitive load (programar vs declarar).
  • Community más pequeña que Terraform.
  • State management similar a Terraform pero diferente.
  • Algunas features más nuevas llegan a Terraform primero.

La decisión Pulumi vs Terraform es preferencia — ambos hacen IaC cloud-agnostic.

Ansible vs Chef/Puppet/SaltStack

Ansible ganó la guerra de config management:

  • Agentless (SSH simple).
  • YAML: declarativa legible.
  • Curve baja vs Puppet DSL.
  • Módulos masivos: >5000 built-in.

Chef/Puppet siguen en enterprises tradicionales pero nuevos proyectos tienden Ansible.

Combinando: stack típico

Flujo productivo:

  1. Pulumi crea infra: VPCs, servers, databases, K8s cluster.
  2. Pulumi exports outputs: IPs, credentials, endpoints.
  3. Ansible recibe outputs: dynamic inventory con Pulumi stack outputs.
  4. Ansible configura: apps, users, servicios.
  5. Ambos en CI/CD: Pulumi preview → apply → Ansible playbook.

Dynamic inventory desde Pulumi

# pulumi_inventory.py
import pulumi
stack = pulumi.automation.select_stack(...)
outputs = stack.outputs()

print({
    "web": {
        "hosts": [o["ip"] for o in outputs["instances"]]
    }
})

Ansible consume este inventory dinámicamente.

Casos donde Ansible solo basta

  • On-premise legacy: sin cloud infra to provision.
  • VMs estáticas: infra no cambia, solo configuración.
  • Network devices: Ansible tiene modules excelentes (Cisco, Juniper).

Casos donde Pulumi solo basta

  • Serverless / containerized: todo runs en managed services.
  • Kubernetes-native: K8s manifests generados por Pulumi cubren app config.
  • Cloud-only without VMs: no hay nada que Ansible hiciera.

Antipatterns

Cosas que no mezclar:

  • Pulumi configurando things dentro de VM: user-data scripts complicados. Mejor Ansible.
  • Ansible creando AWS resources: hay amazon.aws.* modules pero para algo >10 resources, Pulumi es mejor.
  • Terraform + Ansible + Pulumi: elegir uno de IaC (Terraform o Pulumi), no ambos.

Testing

Ansible:

  • Molecule: test playbooks con Docker/Vagrant.
  • ansible-lint: linting.

Pulumi:

  • Unit tests con Pulumi mocks.
  • Integration tests creando stacks efímeros.
  • Policy-as-code con CrossGuard.

Ambos tienen maturity similar en testing.

Secrets

Ansible Vault: integrado, encripta YAML files.

Pulumi:

  • Config.setSecret(): encrypted en state.
  • Integration con AWS SSM, Azure Key Vault, HashiCorp Vault.

Para secrets production-grade, integration con secret manager externo es el path.

Alternativas modernas

  • Terragrunt: wrapper Terraform con DRY patterns.
  • CDKTF: Terraform con TypeScript/Python (como Pulumi).
  • Crossplane: K8s-native IaC.
  • OpenTofu: Terraform fork post-license change.
  • Kapitan: GitOps config management.
  • ArgoCD: GitOps K8s-specific.

Panorama es rico. La elección depende de stack y filosofía.

Cuándo aprender uno

  • DevOps junior empezando: Terraform básico + Ansible básico cubre 80% de empleos.
  • Cloud-native: Pulumi + K8s-native tools.
  • Legacy / enterprise: Ansible + Chef/Puppet sigue siendo relevante.
  • Full-stack engineer: probablemente solo Pulumi o Terraform suficiente si Ansible no necesario.

ROI típico

Equipo que adopta IaC + Config Management proper:

  • Primer mes: negativo (setup time).
  • Tres meses: break-even.
  • Un año: 40-60% time saved en operations repetitivas.
  • Años 2+: disaster recovery en minutos/horas vs días.

El valor acumula. No empezar es un coste invisible creciente.

Conclusión

Ansible y Pulumi son complementarios, no competidores. Pulumi (o Terraform/OpenTofu) para infrastructure provisioning. Ansible para configuration management. Combinarlos es stack productivo para organizaciones con mix de cloud y servers. Para greenfield cloud-native completo, a veces Pulumi solo basta. Para legacy híbrido, Ansible sigue siendo pieza fundamental. La decisión no es “elegir uno” sino “orquestar ambos eficazmente”. Equipos que entienden esta división tienen automation más limpia y mantenible.

Síguenos en jacar.es para más sobre IaC, automation y DevOps.

Entradas relacionadas