Pulumi: Infrastructure as Code

Hola, soy Alex de DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 1 de 10. ¿Qué pasaría si pudieras escribir tu infraestructura en la nube usando el mismo lenguaje de programación que utilizas para tu aplicación? Se acabó el context-switching entre la lógica de tu aplicación y miles de líneas de custom markup. El episodio La infraestructura del desarrollador: ¿Por qué Pulumi? aborda precisamente este cambio. Históricamente, Infrastructure as Code implicaba escribir domain-specific languages o interminables bloques de YAML. Si querías hacer deploy de una base de datos y un servidor, tenías que aprender una sintaxis exclusiva de esa herramienta de aprovisionamiento específica. Perdías el rico ecosistema de la ingeniería de software estándar. No podías escribir fácilmente un loop, integrar testing frameworks estándar ni compartir lógica usando package registries estándar. Pulumi cambia esta base. Es una plataforma de Infrastructure as Code que te permite crear, hacer deploy y gestionar recursos en la nube usando lenguajes de programación de propósito general. En lugar de aprender un lenguaje de configuración a medida, usas TypeScript, Python, Go, C# o Java. Imagina a un desarrollador definiendo recursos en la nube usando TypeScript. Con las herramientas tradicionales, haces context-switching constantemente para consultar schemas de YAML en un navegador web. Con Pulumi, te quedas en tu editor. Instancias una resource class, escribes un punto y el auto-completion estándar del IDE te muestra exactamente qué properties están disponibles. Tienes type-checking inline antes de ejecutar cualquier deployment. Si necesitas tres storage buckets idénticos, escribes un for-loop estándar. Si tu empresa aplica reglas de seguridad específicas en cada servidor, abstraes esa lógica en una función estándar, la publicas en un package registry estándar y permites que otros equipos la importen como cualquier code library normal. Aquí está la clave. Como escribes esta infraestructura en lenguajes imperativos, podrías pensar que Pulumi es solo un script de automatización que llama a las APIs de la nube secuencialmente. No es un script de ejecución imperativo. Pulumi sigue utilizando un declarative state model muy robusto en segundo plano. Cuando ejecutas tu programa Pulumi, no aprovisiona recursos inmediatamente línea por línea. En su lugar, tu código se ejecuta para construir el end state deseado de tu infraestructura. El engine de Pulumi captura estas resource definitions y crea un dependency graph estricto. Luego, compara este desired state con el actual state de tu entorno en la nube. Pulumi calcula la diferencia exacta y realiza únicamente las operaciones específicas de create, update o delete necesarias para que la realidad coincida con tu código. Escribes con la fluidez expresiva de un lenguaje imperativo, pero obtienes la seguridad y la previsibilidad de un deployment engine declarativo. Al adoptar lenguajes de propósito general, tienes acceso a linters existentes, unit testing frameworks y pipelines de continuous integration. Pulumi simplemente deja de tratar la infraestructura como un dominio de configuración independiente y la convierte en software estándar, regido por el mismo rigor y tooling que tu aplicación principal. Si quieres apoyar el programa, puedes encontrarnos buscando DevStoriesEU en Patreon. Me gustaría tomarme un momento para darte las gracias por escuchar; nos ayuda muchísimo. ¡Que tengas un buen día!

Hola, soy Alex de DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 2 de 10. Instancias una clase estándar de Python en tu editor, le das a deploy y, segundos después, existe un storage bucket en la nube. ¿Cómo se traduce exactamente un objeto local en memoria en un recurso físico remoto? Hoy, responderemos a esta pregunta viendo qué hay bajo el capó: la arquitectura de Pulumi. Hay un malentendido muy común sobre cómo funciona esta herramienta. Cuando escribes un script de deployment, tu código no se comunica con las cloud APIs. El entorno que ejecuta tu código Python, Node o Go no tiene ni idea de cómo hablar con Amazon Web Services. En su lugar, Pulumi divide el proceso de deployment en tres componentes distintos: el Language Host, el Deployment Engine y los Resource Providers. Todo empieza con el Language Host. Este componente evalúa tu programa y extrae tu intención. Imagina un script de Python donde declaras un bucket de AWS S3 inicializando un objeto bucket. El Language Host de Python ejecuta tu script línea por línea. Cuando llega a esa declaración del bucket, no hace una network request a AWS. Simplemente envía una registration request al Deployment Engine. Le dice al engine que quieres que exista un bucket con unas propiedades específicas. El Language Host comunica este desired state a través de una conexión local y luego se pausa, esperando una respuesta antes de evaluar la siguiente línea de código. El Deployment Engine recibe esta registration request. Este componente es el orquestador. El engine no sabe nada sobre la sintaxis de Python, y no sabe nada sobre la API de AWS. Su único trabajo es el state management. Examina el desired state enviado por el Language Host y lo compara con el último actual state conocido de tu infraestructura. Si el engine ve que este bucket S3 exacto no existe en el current state, calcula un diff y determina que hace falta una create operation. Para construir realmente el bucket, el engine le pasa la tarea al tercer componente, el Resource Provider. Los providers son plugins independientes que te descargas para plataformas específicas, como AWS, Azure o Kubernetes. El Deployment Engine envía una instrucción al Resource Provider de AWS, diciéndole que cree el bucket con las propiedades solicitadas. Aquí está la clave. El Resource Provider es el único componente en toda esta chain que sabe cómo hablar con la nube. Coge el comando de creación genérico del engine, lo traduce a las REST API calls específicas que requiere AWS y las ejecuta a través de la red. Una vez que AWS aprovisiona el bucket de S3, devuelve un physical resource ID. El Resource Provider coge este physical ID y se lo devuelve al Deployment Engine. El engine actualiza su internal state para registrar que el bucket ya existe en el mundo real. Finalmente, el engine le avisa al Language Host de que el recurso está listo, pasándole las output properties, como el nombre o la URL del bucket. El Language Host reanuda la ejecución y tu script de Python continúa con la siguiente instrucción. Esta estricta separación entre la evaluación del lenguaje, la orquestación del state y la ejecución en la nube es lo que le da a la arquitectura su flexibilidad. Puedes añadir un nuevo lenguaje de programación sin tocar los cloud providers, y añadir un nuevo cloud provider sin modificar los Language Hosts. Eso es todo por este episodio. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Pulumi: Infraestructura como Código, episodio 3 de 10. Configurar un proyecto de infraestructura en la nube solía implicar horas peleando con archivos boilerplate y estructuras de carpetas antes de poder escribir una sola línea de lógica. Hoy, puedes hacer el scaffold de un entorno completo en segundos. Nos vamos a centrar en Hola Azure: Creando tu primer proyecto, para ver exactamente cómo sucede. Un error común es pensar que ejecutar el comando de creación del proyecto construye inmediatamente la infraestructura en la nube. No es así. El comando del que hablamos solo genera archivos locales y prepara el seguimiento del state. No se crea ningún recurso real de Azure hasta que ejecutas explícitamente un comando de deploy más adelante. Para hacer el bootstrap de un nuevo proyecto, usas la interfaz de línea de comandos. Primero, creas un directorio vacío y entras en él. Luego, ejecutas el comando pulumi new seguido del nombre de una plantilla. Para Azure, esta plantilla suele ser azure dash y tu lenguaje de programación preferido, como azure dash typescript o azure dash python. Cuando ejecutas esto, la interfaz se vuelve interactiva. Te guía a través de una serie de prompts para configurar tu entorno. Primero, te pide un nombre de proyecto, que por defecto es el nombre de tu directorio. A continuación, te pide una descripción del proyecto. Después, te pide un nombre de stack. Un stack es una instancia aislada de tu proyecto, que normalmente representa un entorno como desarrollo o producción. El stack por defecto se llama dev. Por último, las plantillas de Azure te lanzan un prompt pidiendo una ubicación de Azure, como WestUS, que se guardará como tu región de deploy por defecto. Una vez que respondes a los prompts, la herramienta descarga la plantilla, instala las dependencias del lenguaje necesarias y crea un puñado de archivos en tu directorio. Aquí está la clave. El archivo más importante que se genera es Pulumi punto yaml. Este es el archivo principal de tu proyecto. Define el nombre del proyecto, el runtime que utiliza y la descripción. Básicamente, le dice al sistema cómo ejecutar tu código. También verás un archivo llamado Pulumi punto dev punto yaml si aceptaste el nombre de stack por defecto. Este archivo secundario almacena los valores de configuración específicos de ese stack, incluida la región de Azure que acabas de seleccionar. Junto a estos, tienes tus archivos de dependencias estándar, que varían según el lenguaje que hayas elegido, y tu archivo entrypoint. Dentro del archivo entrypoint, la plantilla por defecto de Azure proporciona un ejemplo funcional de una cuenta de almacenamiento de Azure. La lógica del código fluye en tres pasos claros. Primero, importa el paquete Azure Native. Segundo, declara un nuevo grupo de recursos de Azure, dándole un nombre lógico para que el archivo de state lo rastree. Tercero, declara una cuenta de almacenamiento de Azure. Aquí es donde se pone interesante. En lugar de hacer hardcode del nombre del grupo de recursos, la cuenta de almacenamiento toma la propiedad name directamente del objeto del grupo de recursos creado en el paso anterior. Esto crea una dependencia implícita. El sistema ahora sabe que debe terminar de crear el grupo de recursos antes de intentar crear la cuenta de almacenamiento. La plantilla también rellena automáticamente los argumentos requeridos para la cuenta de almacenamiento, como el tipo de replicación y el nivel de la cuenta. Justo al final del archivo, el código exporta un valor. En este ejemplo de scaffold, exporta la clave de almacenamiento principal de la cuenta de almacenamiento recién definida. Cuando finalmente hagas el deploy, este valor exportado se imprimirá directamente en tu consola, haciendo que sea fácil recuperar connection strings o endpoints sin tener que iniciar sesión en el portal de Azure. Pasas de una carpeta vacía a un programa de infraestructura totalmente conectado simplemente respondiendo a unos pocos prompts, dándote una base sólida y con la sintaxis correcta para empezar a construir tu propia arquitectura. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 4 de 10. Tu script de deploy funciona perfectamente en tu portátil. Haces push de tu código, tu pipeline automatizado se dispara y la build falla inmediatamente porque no encuentra un archivo fuente. No ha cambiado nada en el código, pero el directorio donde se ejecutó el comando se ha movido ligeramente. Esta es una trampa clásica de rutas, y para evitarla necesitas entender Projects and Paths: Structuring Your Code. En esencia, un proyecto de Pulumi es simplemente una carpeta que contiene un archivo llamado Pulumi.yaml. Este archivo es el ancla. Le dice a la interfaz de línea de comandos que este directorio en concreto contiene la lógica de tu infraestructura. Dentro del archivo Pulumi.yaml, declaras metadatos como el nombre del proyecto, una descripción y el lenguaje del runtime. La propiedad runtime es la que decide cómo se ejecuta realmente tu código. Si especificas Python, el runtime busca un archivo principal de Python en ese directorio. Si especificas Node, busca el entrypoint definido en tu archivo package, que normalmente es un archivo index. Si prefieres mantener tu código fuente en una subcarpeta en lugar del directorio principal del proyecto, puedes sobrescribir explícitamente este comportamiento configurando la propiedad main en tu archivo Pulumi.yaml para que apunte a esa subcarpeta en concreto. Ahora, veamos la confusión habitual con las rutas de los archivos. Supongamos que estás construyendo una imagen de contenedor de Docker como parte de tu infraestructura, y tu Dockerfile está en un subdirectorio llamado app, justo al lado de tu código de Pulumi. Los ingenieros suelen pasar una ruta absoluta de su máquina local para decirle a Pulumi dónde está el Dockerfile. Pero una ruta absoluta incluye tu directorio de usuario personal. Cuando un compañero de equipo hace pull del código y ejecuta un update, el motor ve una ruta absoluta diferente en su máquina. Registra esto como un cambio estructural en el recurso, creando un drift innecesario en el estado de tu infraestructura. Para solucionar esto, podrías cambiar a una ruta relativa estándar, como punto barra app. Las rutas relativas estándar dependen por completo del directorio de trabajo actual de la terminal que ejecuta el código. Si tu sistema de integración continua ejecuta el comando desde un directorio más arriba en el repositorio, la ruta relativa se resuelve incorrectamente y el deploy falla. Aquí está la clave. Necesitas rutas que sean totalmente independientes de la máquina en la que se ejecutan, e independientes de dónde escribió el usuario el comando de ejecución. Necesitas rutas relativas al proyecto. Pulumi incluye una función integrada para obtener la ubicación exacta del archivo Pulumi.yaml durante la ejecución. Dependiendo de tu lenguaje de programación, esta función suele llamarse get root directory o algo similar. Cuando llamas a esta función, el runtime devuelve la ruta absoluta a la carpeta que contiene tu archivo Pulumi.yaml. En lugar de hardcodear una ruta a tu Dockerfile, construyes la ruta dinámicamente. Coges el resultado de la función root directory y le añades tu subdirectorio app. Como esta función se evalúa dinámicamente en cada ejecución, la ruta resultante siempre se adapta a la perfección al entorno que ejecuta el código. Tu máquina local, el portátil de tu compañero y el servidor de build remoto generarán la ruta absoluta correcta para sus sistemas de archivos específicos. La ruta del archivo se resuelve de forma consistente cada vez, y el motor detecta cero cambios en la definición del recurso. A tu código de infraestructura nunca debería importarle dónde vive en un disco duro. Ancla siempre tus assets de archivos a la función root directory de Pulumi, asegurando que tu proyecto siga siendo completamente portable en cualquier entorno. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 5 de 10. Copiar y pegar el código de tu infraestructura para crear un entorno de staging es una receta para el drift y el desastre. Terminas manteniendo múltiples carpetas con archivos casi idénticos y, tarde o temprano, alguien se olvida de actualizar producción. La solución es tratar tus entornos como instancias aisladas de un único codebase usando Stacks. Antes de seguir, aclaremos un punto común de confusión. Un Project en Pulumi es simplemente un directorio que contiene tu source code. Son solo las instrucciones. Un Stack es una instancia de deploy activa de ese código. Escribes el Project una vez y le haces deploy varias veces como diferentes Stacks. Los Stacks te permiten gestionar diferentes entornos, como development, staging y producción, sin duplicar nada de código. Cuando ejecutas un update de Pulumi, aplica el código de tu Project al Stack que esté activo en ese momento. Cada Stack mantiene su propio state file aislado, registrando solo los recursos creados para ese entorno específico. La gestión de estos entornos se hace directamente en tu terminal. Creas un nuevo entorno ejecutando el comando stack initialize, dándole un nombre como dev o prod. Pulumi registra esta nueva instancia y crea un state nuevo para ella. Para cambiar de contexto, usas el comando stack select. La CLI de Pulumi recuerda qué stack está activo. Si seleccionas el stack dev y ejecutas un update, Pulumi solo mira el state de development. Provisiona o modifica la infraestructura de development, dejando tus entornos de staging y producción completamente intactos. Eso cubre cómo hacer deploy de entornos aislados. Pero, ¿qué pasa cuando estos entornos necesitan comunicarse? A veces, un stack depende de información generada por otro. Puedes tener un project gestionando la infraestructura core y un project totalmente separado gestionando el application code. Supongamos que tienes un project de infraestructura que provisiona un cluster de Kubernetes. Haces deploy de esto como un stack llamado base-infra-prod. Durante el deploy, el cluster genera una connection string dinámica. Ahora, tienes un segundo project para un microservicio que necesita hacer deploy en ese mismo cluster. No quieres hacer hardcode de la connection string, y no quieres fusionar ambos projects en un único state file masivo y lento. Aquí es donde se pone interesante. Puedes conectar estos deploys de forma segura usando una Stack Reference. Una Stack Reference permite que un stack lea los outputs exportados de otro stack. Para configurar esto, el programa de tu cluster de Kubernetes debe exportar explícitamente la connection string al final de su ejecución. Un export es simplemente una variable que Pulumi guarda en el stack state específicamente para que pueda leerse desde fuera. Luego, en el programa de tu microservicio, creas un objeto Stack Reference. Le pasas el nombre del stack de infraestructura del que quieres leer. Después, llamas a un método get output en esa referencia, pidiendo la connection string por su nombre exportado. Tu microservicio ahora puede usar ese valor para configurar su deploy. El stack del microservicio no puede modificar el stack del cluster. Solo puede leer los valores específicos que el stack del cluster decidió exportar. Esto establece un límite limpio. Puedes actualizar y escalar tu infraestructura de red core de forma totalmente independiente de los workloads de tus aplicaciones, pasando de forma segura los detalles de conexión necesarios de un lado a otro. Al desacoplar tu código de la instancia del entorno, garantizas que cada tier de tu sistema pase por exactamente la misma lógica, eliminando los riesgos ocultos de la duplicación manual. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 6 de 10. Haces deploy de tu código de infraestructura, la sintaxis es impecable, y falla inmediatamente porque el nombre de un storage bucket ya está en uso. O peor aún, actualizas una instancia de base de datos, y tu herramienta elimina la antigua antes de crear la nueva, provocando un outage grave. Puedes solucionar ambos problemas entendiendo cómo tu herramienta de infraestructura gestiona la identidad. Eso es exactamente lo que vamos a ver hoy: Los componentes básicos: Pulumi Resources. En Pulumi, un resource es un objeto que representa una pieza de infraestructura. Hay dos tipos principales con los que trabajarás. El primero es un Custom Resource. Este se mapea directamente a un objeto físico gestionado por un cloud provider. Cuando declaras un Custom Resource, Pulumi hace una API call a Amazon, Azure o Google Cloud para crear ese objeto exacto, como una máquina virtual o un load balancer. El segundo tipo es un Component Resource. Un Component Resource no se mapea a una única pieza de infraestructura cloud. En su lugar, es un contenedor lógico para otros resources. Usas Component Resources para construir abstracciones de más alto nivel. Por ejemplo, puedes crear un único Component Resource llamado Secure Web Server que internamente provisione una máquina virtual, un security group y una dirección IP. El propio Component Resource simplemente los agrupa en tu state file, haciendo que tu código sea más limpio y fácil de gestionar. Tanto si defines un Custom Resource como un Component Resource, todos y cada uno de ellos requieren un nombre. Esto nos lleva a una fuente común de frustración. La gente escribe un nombre en su código, hace deploy, y luego revisa su cloud console solo para encontrarse con que su resource tiene un string aleatorio de caracteres añadido al final de su nombre. Esto no es un bug. Es una feature fundamental de cómo funciona Pulumi, y necesitas entender la diferencia entre un nombre lógico y un nombre físico. El nombre lógico es el nombre que escribes en tu código como argumento. Pulumi usa este nombre lógico para trackear el resource dentro de su state file. Así es como Pulumi sabe que la base de datos en tu código de hoy es exactamente la misma base de datos de la que hiciste deploy ayer. El nombre físico es como el cloud provider llama realmente al resource en su propio sistema. Por defecto, Pulumi coge tu nombre lógico, le añade un sufijo aleatorio, y usa ese string combinado como el nombre físico. Esto se llama auto-naming. Aquí está la clave. El auto-naming evita colisiones de nombres globales y permite reemplazos con zero-downtime. Piensa en provisionar múltiples storage buckets idénticos en un loop usando Azure. Azure requiere que los nombres de las storage accounts sean globalmente únicos entre todos los clientes. Si intentas forzar un nombre físico estricto, el segundo bucket en tu loop fallará porque el nombre ya está cogido, o peor, alguien más en el mundo podría ser ya el dueño. Con el auto-naming, puedes simplemente usar un nombre lógico como archive-bucket dentro de tu loop. Pulumi trackeará cada iteración lógicamente mientras asegura que cada bucket obtenga un nombre físico matemáticamente único en Azure. El auto-naming también protege el uptime de tu sistema. Si haces un cambio que fuerza a que un resource sea reemplazado, Pulumi crea el nuevo resource primero, verifica que funciona, y solo entonces elimina el antiguo. Si haces override del auto-naming y fuerzas un nombre físico estricto, el cloud provider no dejará que dos resources compartan el mismo nombre al mismo tiempo. Pulumi se vería forzado a borrar tu antiguo resource primero, causando downtime mientras el nuevo se provisiona. Si quieres ayudar a que el programa siga adelante, puedes buscar DevStoriesEU en Patreon. Mantén tus nombres físicos flexibles. Deja que la herramienta gestione los sufijos aleatorios, porque aunque tu state file requiere un nombre lógico para mantener el orden, tu entorno de producción depende de la flexibilidad física para mantenerse online. Gracias por escuchar. Cuidaos todos.

Hola, soy Alex de DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 7 de 10. Hardcodear la contraseña de la base de datos en tu código de infraestructura es un fallo de seguridad garantizado. Pero inyectar manualmente variables de entorno en cada pipeline de deploy es frágil y difícil de seguir. Necesitas una forma de vincular automáticamente valores específicos encriptados a entornos específicos. Esto es Keeping Secrets: Configuration Management. La idea principal aquí es separar tu código de tu configuración. Quieres escribir la lógica de tu infraestructura exactamente una vez. Luego, cuando haces deploy en tu stack de desarrollo, el código provisiona instancias pequeñas. Cuando haces deploy a producción, provisiona instancias grandes y usa las credenciales de la base de datos de producción. Pulumi gestiona esto a través de un sistema de configuración integrado. Un punto común de confusión es cómo se almacenan realmente estos valores. Configurar un valor de configuración de Pulumi no establece variables de entorno en el sistema operativo local. En su lugar, almacena los valores directamente en un archivo llamado Pulumi punto stack-name punto yaml. Como cada stack tiene su propio archivo de configuración distinto, tu configuración de dev y tu configuración de prod conviven lado a lado en tu repositorio, limpiamente separadas por el nombre del archivo. Añades datos a este archivo usando la interfaz de línea de comandos de Pulumi. Si ejecutas el comando pulumi config set frontendPort 8080, Pulumi escribe ese par key-value directamente en el archivo yaml de tu stack activo actualmente. Para usar ese valor en tu código de infraestructura, instancias un objeto Config. Luego, llamas a un método como get o require en ese objeto, pasándole el nombre de la key. La diferencia es muy simple. Llamar a get devuelve el valor si existe, o nada si no existe. Llamar a require lanzará un error y detendrá tu deploy si falta la key de configuración. Esta es una gran manera de asegurar que un deploy nunca continúe sin una configuración obligatoria. No estás limitado a strings simples. Puedes almacenar y recuperar datos estructurados, como un bloque JSON que define parámetros de escalado, y parsearlo directamente a un objeto en tu código. Ahora, ¿qué pasa cuando ese valor de configuración es muy sensible? Supón que tu aplicación necesita conectarse a una base de datos externa, y debes pasarle la contraseña de la base de datos a tu infraestructura. Absolutamente no puedes almacenar esto en plaintext en tu archivo yaml, porque a ese archivo se le hace commit en el control de versiones. Aquí es donde entran los secrets de Pulumi. Usas exactamente la misma interfaz de línea de comandos, pero añades un flag secret. Ejecutas pulumi config set dbPassword your-password guion guion secret. Pulumi encripta el valor antes de guardarlo en el archivo yaml. Si alguien mira el archivo en tu repositorio, solo verá un string en ciphertext encriptado de forma segura por el proveedor de encriptación de tu stack. En tu código, recuperas esto de forma segura llamando a un método secret específico en tu objeto Config, como requireSecret. Aquí está el punto clave. Cuando recuperas un secret de esta manera, Pulumi lo envuelve en un tipo secret especial. A medida que este valor fluye por tu código de infraestructura y se pasa a los recursos, el motor de Pulumi lo trackea. Asegura que el valor en plaintext quede enmascarado en la salida de tu consola durante un deploy, y garantiza que el valor permanezca encriptado dentro de tu archivo de state de Pulumi. La configuración te permite escribir el código de infraestructura una vez y promoverlo de forma segura entre entornos. La encriptación nativa de secrets asegura que tus credenciales sensibles impulsen esos deploys sin filtrarse nunca en tu control de versiones o en tus archivos de state. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 8 de 10. Copias y pegas un bloque de código de storage y networking por quinta vez esta semana. Tu código de infraestructura crece, pero no se vuelve más inteligente. En lugar de repetir configuraciones idénticas en la nube cada vez que necesitas un setup estándar, puedes generarlas con una sola unidad lógica. Ese es el tema de este episodio: Scaling Up: Component Resources en Azure. Cuando empiezas a usar Pulumi, declaras raw resources. Un Resource Group aquí, un Storage Account allá. Pero a medida que tu sistema crece, hacer el deploy de una pieza estándar de arquitectura requiere aprovisionar exactamente el mismo conjunto de primitivas una y otra vez. Esto rompe la regla de Don't Repeat Yourself. Los Component Resources solucionan esto permitiéndote encapsular múltiples recursos físicos cloud en una abstracción reutilizable. Piensa en un Component Resource como una clase custom que defines en tu lenguaje de programación preferido. Una vez definida, la instancias igual que un recurso built-in de Pulumi. Imagina un escenario en el que haces deploy frecuentemente de sitios web estáticos en Azure. Un setup mínimo requiere un Resource Group de Azure, un Storage Account configurado para hosting de sitios web estáticos, y un objeto Blob que sirva como documento index. En lugar de escribir esas tres definiciones en tu programa main cada vez, creas un componente de sitio web estático de Azure. Para construir esto, defines una nueva clase que hereda de la clase base ComponentResource de Pulumi. El constructor de tu clase recibe un nombre, un conjunto de argumentos para customización y resource options estándar. Lo primero que hace tu constructor es llamar al constructor de la clase base. Le pasas un type token único, como custom dos puntos infrastructure dos puntos static website, junto con el nombre. Este type token le dice al engine cómo trackear tu nueva abstracción en el state file. A continuación, defines las primitivas de Azure dentro de tu constructor. Declaras el Resource Group. Declaras el Storage Account dentro de ese grupo. Subes el blob del index a esa cuenta. Aquí está la clave. Cuando creas estos recursos internos, debes decirle explícitamente al engine que pertenecen a tu nuevo componente. Esto lo haces pasando la propia instancia del componente a las resource options bajo la propiedad parent. Muchos ingenieros olvidan este paso. Si omites la opción parent, los recursos hijos se aprovisionarán correctamente, pero serán tratados como recursos top-level. El output de tu línea de comandos será una lista plana y confusa. Al configurar la propiedad parent con la instancia de tu componente, el engine organiza el state tree. Cuando ejecutas un update, la interfaz anida visualmente el Resource Group, el Storage Account y el blob directamente bajo tu componente custom de sitio web. Esto mantiene tu state manejable y tu output legible. Finalmente, tu programa main probablemente necesite conocer la dirección web del sitio recién creado. Dentro de tu componente, después de definir el Storage Account, mapeas su web endpoint primario a una propiedad pública en tu clase. Luego, llamas a un método llamado register outputs. Esto finaliza la inicialización y asegura que la dirección final quede expuesta al resto de tu programa y se imprima en la consola cuando termine el deploy. En tu archivo main, ya no ves el boilerplate. Simplemente instancias tu componente de sitio web, le pasas un archivo index y haces el deploy. Los recursos subyacentes se gestionan de forma segura detrás de la abstracción. El verdadero poder de Infrastructure as Code es tratar la arquitectura cloud como software, y los Component Resources son la forma en que construyes una librería estándar y fiable para tu equipo. Eso es todo por este episodio. Gracias por escuchar, ¡y a seguir construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodio 9 de 10. No tienes que tirar a la basura años de código existente para empezar a usar una nueva herramienta de infraestructura hoy mismo. La temida reescritura masiva del sistema es un riesgo enorme y, afortunadamente, es totalmente opcional. La estrategia que hace esto posible se llama Coexistencia Pacífica: leyendo el state de Terraform. Un error muy común es pensar que pasarse a Pulumi significa que tienes que migrar toda tu infraestructura existente a la vez. Eso no es así. Pulumi puede leer y depender de forma nativa de recursos que están siendo gestionados activamente por Terraform. Puedes adoptar nuevas herramientas de forma incremental, en paralelo con tus pipelines de deploy existentes. Imagina un entorno empresarial típico. Tu empresa tiene una Virtual Private Cloud core de AWS, gestionada por un equipo central de redes usando Terraform. Tú eres un desarrollador creando una nueva aplicación, y quieres usar Pulumi para hacer el deploy de tareas de Elastic Container Service. Tus contenedores tienen que ejecutarse exactamente dentro de esa VPC. No quieres reescribir el código de la VPC en Pulumi, y desde luego no quieres encargarte de gestionar la red subyacente. Para gestionar esto, usas el provider de Terraform de Pulumi. Este provider incluye un componente específico diseñado para leer archivos de state, llamado remote state reference. El proceso se basa en cómo Terraform almacena sus datos de ejecución. Primero, el código de Terraform que gestiona la red tiene que exponer explícitamente los datos que necesita tu nueva aplicación. Esto lo hace usando bloques output estándar de Terraform. El equipo de redes configura su código para devolver como output el identificador de la VPC y una lista de identificadores de subredes privadas. Cuando Terraform aplica su configuración, esos outputs se escriben en el archivo de state de Terraform, que normalmente se almacena de forma remota en un backend como un bucket de AWS S3 o Terraform Cloud. A continuación, pasas a tu programa de Pulumi. Escribes código para instanciar el remote state reference. Le pasas a este objeto exactamente los mismos detalles de configuración del backend que usa Terraform para encontrar su archivo de state. Esto incluye el tipo de backend, la ubicación del almacenamiento, la región y la key específica del archivo de state. Cuando ejecutas tu deploy de Pulumi, el motor se conecta a ese backend remoto, abre el archivo de state de Terraform y procesa los outputs disponibles. Aquí está la clave del asunto. Pulumi trata el state de Terraform como estrictamente de solo lectura. Nunca modifica el archivo de state de Terraform, y no asume el ownership de los recursos de red. Simplemente consulta los valores actuales y conocidos de la infraestructura. Una vez que Pulumi recupera los identificadores de la VPC y de las subredes desde el state, tú tratas esos valores como cualquier otra variable en tu código. Los pasas directamente a la lógica de deploy de tu nuevo clúster de contenedores. Pulumi aprovisiona tus nuevos contenedores sin problemas dentro de la red existente. Esta arquitectura mantiene las responsabilidades completamente separadas. El equipo central sigue gestionando el ciclo de vida de la red usando Terraform. Si actualizan una tabla de rutas o añaden un tag, usan su workflow estándar. Si modifican un output, como al crear una nueva subred, Pulumi leerá automáticamente el archivo de state actualizado durante su siguiente update y ajustará tu deploy de contenedores en consecuencia. Usar remote state references crea un límite de dependencia limpio y unidireccional, permitiéndote construir con confianza nuevos sistemas con capacidades modernas mientras te apoyas en una base estable gestionada por código legacy. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Pulumi: Infraestructura como Código, episodio 10 de 10. Probar la lógica compleja de infraestructura es notoriamente difícil. Escribes miles de líneas de configuración, pero verificar si una combinación específica de reglas de firewall realmente se comporta como esperas antes del deploy suele parecer jugar a las adivinanzas. La Gran Migración: Convertir HCL a Pulumi es como solucionas esto. Pasar de Terraform a Pulumi no es un simple buscar y reemplazar sintáctico. No se trata de cambiar llaves por paréntesis. Se trata de coger la configuración estática y transformarla en un programa ejecutable, dándote acceso inmediato a bucles nativos, funciones y testing frameworks estándar. Piensa en una configuración de security group de Terraform muy compleja y repetitiva. Probablemente tengas docenas de rangos de puertos superpuestos, allowlists de IPs específicas y block definitions pesadas. En HCL, gestionar esto requiere estructuras rígidas, y validar la lógica requiere ejecutar un plan contra un live cloud state. La transición empieza con el comando pulumi convert. Navegas a un directorio que contiene tus archivos de Terraform existentes y ejecutas este comando, especificando tu lenguaje de destino, como TypeScript o Python. La herramienta parsea tu código fuente HCL, lee tus variables, recursos principales y outputs, y genera un programa de Pulumi equivalente. Traduce la intención declarativa del HCL a la estructura imperativa del lenguaje de programación elegido. Una vez generado ese código, las ventajas estratégicas de la migración se hacen evidentes. Ahora puedes refactorizar esa enorme lista de reglas de security group en un array limpio de objetos de datos, o sacarlas de un archivo de configuración externo. Puedes iterar sobre ese array para generar reglas de firewall dinámicamente usando loops estándar de TypeScript o Python. Aquí está la clave. Como tu infraestructura ahora está escrita en un lenguaje de propósito general, puedes testearla exactamente igual que el código de aplicación. Puedes escribir un unit test usando frameworks estándar como Jest o PyTest. Creas un test case que mockea el runtime de Pulumi y hace un assert de que tu función builder de security group nunca expone accidentalmente el puerto veintidós a todo internet. Ejecutas estos tests en milisegundos, completamente offline, detectando errores lógicos antes incluso de que empiece la fase de plan de la infraestructura. Este cambio desbloquea una profunda integración del lenguaje. El código de tu infraestructura puede compartir librerías estándar, lógica de validación y definiciones de tipado directamente con el código de tu aplicación. Ganas acceso a los ecosistemas maduros de package managers como NPM o pip, permitiéndote empaquetar y distribuir patrones de infraestructura tan fácilmente como cualquier otra librería de software. El comando de conversión hace el trabajo pesado de traducir tu state actual, pero la verdadera migración ocurre cuando cambias tu mentalidad de escribir archivos estáticos a diseñar sistemas testeables. La mayor ventaja de convertir tu código es pasar de simplemente configurar la infraestructura a programarla de verdad. Te animo mucho a que leas la documentación oficial de Pulumi, cojas un pequeño módulo de Terraform e intentes ejecutar la conversión tú mismo para ver el output. Si tienes ideas sobre qué temas técnicos deberíamos tratar en nuestra próxima serie, visita devstories dot eu y cuéntanos. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!