Infraestructura como código con Pulumi: automatización cloud con lenguajes reales

Terraform (HCL) tiene un ecosistema de providers más amplio y más módulos de la comunidad. Pulumi encaja mejor cuando su equipo ya escribe TypeScript, Python o Go y quiere usar funciones reales de un lenguaje —bucles, funciones, clases, pruebas unitarias— sin aprender HCL. Pulumi ofrece además la Automation API para integrar la IaC en el código de aplicación, algo que Terraform no puede igualar. Ambas herramientas son maduras; la elección depende sobre todo de las habilidades de lenguaje que ya tenga su equipo y de la necesidad de una automatización programable.

Pulumi admite varios backends de estado: Pulumi Cloud (gestionado, con RBAC, historial y aplicación de políticas), S3 con cifrado en el servidor y bloqueo con DynamoDB, Azure Blob Storage y GCS. Separamos el estado por entorno (dev / staging / prod) y por subsistema principal para limitar el radio de impacto. Los archivos de estado se cifran en reposo; las salidas sensibles se marcan con `Output.secret` para que se cifren en el estado y nunca se registren en los logs.

Pulumi ofrece dos capas de gestión de secretos. Los secretos a nivel de stack usan la clave de cifrado del stack (Pulumi Cloud o una clave gestionada por el cliente) para cifrar valores de salida individuales en el estado. Pulumi ESC (Environments, Secrets, Config) es el enfoque más reciente y recomendado: los secretos se almacenan de forma centralizada, con control de versiones, se cifran en el servidor y se inyectan en los stacks y en los entornos de CI en tiempo de ejecución, lo que elimina por completo las credenciales en texto plano de los archivos de estado y de los logs del CI.

CrossGuard es el framework de políticas como código de Pulumi. Se escriben políticas en TypeScript o Python que verifican propiedades de los recursos: cifrado activado, acceso público bloqueado, etiquetas obligatorias presentes. Las políticas se agrupan en policy packs y se ejecutan en el servidor de Pulumi Cloud (bloqueando la actualización) o en local en el CI. CrossGuard admite políticas consultivas (solo advierten) y obligatorias (bloquean el despliegue). Los clientes regulados usan packs obligatorios para asegurar que ningún recurso no conforme llegue a producción.

Sí. Pulumi ofrece dos capas de pruebas. Las pruebas unitarias simulan el SDK de Pulumi y verifican las configuraciones de los recursos sin hacer llamadas a la API de la nube: son rápidas y se ejecutan en el CI sin credenciales. Las pruebas basadas en propiedades usan el motor real de Pulumi sobre un stack de prueba y validan que los recursos desplegados cumplen ciertos invariantes. Escribimos ambas capas para cada componente no trivial, de modo que los equipos tengan la misma confianza en las pruebas de la infraestructura que en las del código de aplicación.

Pulumi incluye `pulumi convert --from terraform`, que traduce módulos HCL a TypeScript, Python o Go. En bases de código grandes convertimos de forma incremental: envolvemos el estado de Terraform existente con el data source de remote state de Terraform de Pulumi y migramos los subsistemas uno a uno. El estado de los recursos ya aprovisionados se importa con `pulumi import`, de modo que Pulumi asume su gestión sin volver a aprovisionarlos. Ejecutamos Terraform y Pulumi en paralelo durante la ventana de transición para evitar tiempos de inactividad.

Cada nube es un provider de Pulumi independiente que se instala como dependencia de paquete. Organizamos los stacks por entorno y región de la nube, usamos stack references para compartir salidas entre stacks (por ejemplo, un stack de red compartido que consumen los stacks de aplicación) y mantenemos una biblioteca de componentes reutilizables para los patrones habituales de cada nube. Las versiones de los providers se fijan en el código y se actualizan con una cadencia programada y ejecuciones automáticas de preview para detectar cambios incompatibles antes de que se propaguen.