Terraform Fundamentals

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 1 de 13. Antes, aprovisionar servidores implicaba abrir un ticket de soporte y esperar dos semanas a que alguien hiciera clics en una consola cloud. Hoy en día, exactamente el mismo proceso es una simple pull request que hace deploy de forma segura en minutos. Este cambio se debe por completo al paradigma de Infrastructure as Code, y HashiCorp Terraform es el motor principal que lo impulsa. Infrastructure as Code es exactamente lo que suena. Gestionas tus bases de datos, redes virtuales e instancias de compute usando archivos de texto plano en lugar de clics manuales. Estos archivos pueden estar bajo control de versiones, ser revisados por tus compañeros y testearse automáticamente. Para entender por qué esto es tan potente, imagina a un administrador de sistemas que necesita una nueva máquina virtual en Azure. Usando un flujo de trabajo imperativo, podría escribir un script complejo de PowerShell. Ese script tiene que definir explícitamente cada acción en orden. Le dice al sistema que haga login, compruebe si existe una red, la cree si no existe, asigne una IP pública y, finalmente, arranque el servidor. Si el script falla en el paso cuatro, te quedas con una infraestructura construida a medias. Ejecutar el script una segunda vez suele causar errores porque algunos recursos ya existen. Terraform, en cambio, utiliza un enfoque declarativo. No escribes la secuencia de pasos. Simplemente defines el estado final deseado. Escribes un archivo de configuración indicando que quieres una máquina virtual de Azure conectada a una red específica. Terraform compara tu estado solicitado con lo que existe actualmente en la nube. Luego calcula la secuencia exacta de llamadas a la API necesarias para cubrir esa diferencia. Si la red ya existe, Terraform la deja tal cual y solo construye el servidor. Aquí está la clave. Muchos ingenieros confunden las herramientas de aprovisionamiento de infraestructura como Terraform con las herramientas de configuration management como Chef, Puppet o Ansible. No son lo mismo. Terraform construye la casa. Las herramientas de configuration management colocan los muebles. Terraform aprovisiona los recursos en bruto de la nube, como los load balancers y las máquinas virtuales. Luego, Ansible o Chef hacen login en esas máquinas para instalar paquetes de software y arrancar servicios en segundo plano. Las herramientas de configuration management se diseñaron fundamentalmente para infraestructura mutable. Esperan que un servidor viva mucho tiempo y pase por constantes parcheos y ajustes. Terraform te empuja hacia una infraestructura inmutable. Si un entorno necesita una versión diferente del sistema operativo, Terraform no hace login ni ejecuta un script de actualización. Destruye el servidor antiguo y aprovisiona uno completamente nuevo con la imagen correcta. Este enfoque estricto garantiza que tu código siempre coincida con la realidad, eliminando por completo el configuration drift. Este flujo de trabajo es especialmente valioso porque es agnóstico a la plataforma. Una empresa rara vez usa un solo proveedor. Puedes ejecutar tus workloads principales en Azure, gestionar tus DNS a través de Cloudflare y administrar el enrutamiento de incidentes en PagerDuty. Terraform gestiona todo esto mediante un modelo de providers. Un provider es simplemente un plugin que entiende la API de un proveedor específico. Al usar múltiples providers, puedes crear una única configuración que levante una base de datos en Azure, configure los registros DNS necesarios y establezca las alertas de monitorización simultáneamente. Las llamadas a la API subyacentes cambian, pero tu flujo de trabajo se mantiene exactamente igual. Si quieres ayudar a que sigan saliendo estos episodios, puedes buscar DevStoriesEU en Patreon para apoyar el programa. Una herramienta que simplemente automatiza tareas te hace más rápido, pero una herramienta que impone un estado declarativo hace que todo tu sistema sea predecible. Me gustaría tomarme un momento para darte las gracias por escucharnos, nos ayuda muchísimo. ¡Que tengas un buen día!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 2 de 13. Pulsas deploy, miras la consola y cruzas los dedos, esperando no haberte cargado el entorno de producción. Ese salto de fe a ciegas es un riesgo enorme, y es exactamente lo que elimina el workflow principal de Terraform. El workflow consta de tres pasos estrictos: write, plan y apply. Cada paso opera de forma independiente para traducir tus requisitos en recursos en funcionamiento. Empiezas con la fase de write. Creas archivos de configuración que declaran la infraestructura exacta que quieres. No estás escribiendo un script procedural que dice cómo construir un servidor paso a paso. Estás describiendo el estado final deseado de tu entorno. Guardas estos archivos y tu código se convierte en la single source of truth sobre lo que debería existir. Los usuarios nuevos a veces piensan que el siguiente paso es simplemente ejecutar esos archivos secuencialmente de arriba a abajo. Así no es como funciona esta herramienta. No ejecuta comandos a ciegas. En su lugar, pasa a la fase de plan. La fase de plan es el superpoder absoluto de este workflow. Al ejecutar el comando plan, la herramienta evalúa tu nueva configuración frente al estado actual y real de tu infraestructura. Calcula un diff preciso entre la realidad y tu código deseado. Aquí está la clave. La herramienta lee este diff y genera un dry run muy detallado de cada una de las acciones que pretende realizar. Imagina a un ingeniero que necesita añadir un Load Balancer de Azure a un entorno de producción. Actualiza sus archivos de configuración y ejecuta el comando plan. El sistema se conecta al cloud provider, comprueba el estado activo e imprime un resumen estricto. El ingeniero lee el output y ve un recurso para añadir, cero para modificar y cero para destruir. El output detalla las propiedades exactas del nuevo Load Balancer. El ingeniero valida este dry run. Sabe que el cambio es seguro antes de que una sola API call modifique la infraestructura real. No hay que adivinar nada. Tras validar el output, pasas a la fase de apply. Este es el momento de la ejecución. La herramienta coge el diff exacto calculado durante la fase de plan y construye un execution graph estricto. Mapea todas las dependencias. Si tu nuevo Load Balancer requiere una dirección IP pública dedicada, el execution graph asegura que la IP se aprovisione primero. El sistema espera a que la IP esté disponible, coge su nueva dirección y solo entonces crea el Load Balancer. Gestiona los tiempos y el orden automáticamente. Como la fase de apply sigue estrictamente el execution plan aprobado, nunca tendrás recursos levantándose en el orden equivocado o borrando accidentalmente bases de datos existentes por un typo. El workflow te obliga a separar la intención de la ejecución. El aspecto más potente de este proceso no es el aprovisionamiento automatizado en sí. Es la eliminación total de la ansiedad operativa mediante dry runs predecibles y revisables. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 3 de 13. Por defecto, la aplicación core de Terraform no sabe realmente cómo crear una máquina virtual de Azure o una base de datos. Es estrictamente un motor que evalúa código, determina dependencias y gestiona el state. Para hacer cualquier trabajo real, depende de miles de plugins de traducción descargables. Esto nos lleva a los providers y a cómo conectas tu código con Azure. Un punto de confusión común es pensar que la propia aplicación de Terraform contiene la lógica para cada plataforma cloud. No es así. El binario que instalas en tu máquina es completamente agnóstico a la infraestructura. Entiende el lenguaje de configuración y el workflow de deploy, pero tiene cero conocimiento hardcodeado de ninguna API cloud específica. En su lugar, Terraform utiliza plugins llamados providers. Un provider es una pieza de software standalone que entiende los endpoints, los métodos de autenticación y los comportamientos de los recursos para una plataforma específica. Hay un provider para Microsoft Azure, uno para Amazon Web Services y otros para plataformas de software as a service como GitHub o Datadog. Estos plugins se publican y alojan en un directorio central llamado Terraform Registry. Cuando empiezas un nuevo proyecto de infraestructura, debes declarar explícitamente qué providers usará tu código. También especificas la versión exacta del provider que quieres. Fijar una versión es una práctica crítica. Esto asegura que si la API cloud cambia o el plugin del provider recibe una actualización mayor mañana, tu deploy no se romperá inesperadamente. Tú controlas exactamente cuándo hacer el upgrade. Simplemente declarar el provider en tu archivo de texto no lo instala. Debes ejecutar un comando de inicialización en tu terminal. Este paso de inicialización se conecta activamente al Terraform Registry, descarga los plugins de los providers necesarios y los guarda en caché en un directorio local oculto. Hasta que ejecutas este paso, tu proyecto de Terraform no puede interactuar con ningún sistema externo. Veamos cómo configurar esto para un nuevo proyecto que se conecta a una suscripción enterprise de Azure. Usarás el provider oficial de Azure Resource Manager, conocido como azurerm. Después de declarar la versión que necesitas, debes configurar el comportamiento específico del provider. Cada provider tiene sus propios requisitos de configuración basados en la API subyacente. Para Azure, el plugin requiere que declares explícitamente cómo debe gestionar ciertos comportamientos de los recursos. Por ejemplo, debes decirle al provider si debe eliminar permanentemente los discos de almacenamiento adjuntos cuando se destruye una máquina virtual. El provider exige esta configuración por adelantado para que las acciones destructivas sean siempre intencionadas. Una vez inicializado y configurado, el provider actúa como una capa de traducción plug-and-play. Cuando ejecutas tu código, el motor core de Terraform calcula la diferencia entre tu infraestructura actual y tu state deseado. Luego, pasa esas instrucciones genéricas al plugin del provider de Azure. El plugin toma el control, traduciendo tu intención en peticiones HTTP autenticadas que se envían directamente a la API de Azure Resource Manager. El plugin espera a que Azure termine de crear o modificar los recursos, traduce la respuesta de la API de vuelta a un formato que Terraform entiende, y devuelve los datos finales al motor core. El propio Terraform nunca se comunica directamente con tu entorno cloud; delega cada llamada a la API al plugin del provider, convirtiendo al provider en el verdadero puente entre tu código y tu infraestructura en producción. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 4 de 13. Miras tu código y ves una base de datos etiquetada como primary, pero al iniciar sesión en tu cloud console, esa misma base de datos tiene un nombre completamente diferente, como db-cluster-node-one. Si quieres que algo exista físicamente en tu entorno cloud, debes solicitarlo usando el constructo más importante de Terraform, pero también debes comprender cómo Terraform nombra las cosas. Hoy hablamos sobre declarar infraestructura con resources. Los resources son los componentes fundamentales de tu infraestructura. Cada vez que quieres crear, actualizar o destruir un objeto, escribes un resource block. Este objeto puede ser un componente físico, como una compute instance o una unidad de storage, o un constructo lógico, como un registro DNS o una asignación de roles. El resource block es la forma de traducir la idea de un componente de infraestructura en una API request que tu cloud provider realmente entienda. Al declarar un resource block, defines su identidad usando dos etiquetas distintas. Primero, declaras el resource type. Esto le dice a Terraform exactamente qué tipo de objeto quieres construir y qué provider lo va a construir. El tipo siempre empieza con el namespace del provider, como Azure o AWS, seguido del servicio específico. Básicamente, le estás diciendo a Terraform que necesitas un resource group de Azure o un storage bucket de AWS. Inmediatamente después del resource type, defines el identificador local. Esto es simplemente un alias. Solo existe dentro de tu configuración de Terraform. Usas este alias para referenciar el objeto desde otras partes de tu código. No tiene absolutamente ningún efecto en lo que ve tu cloud provider. Esto nos lleva al configuration block en sí. Una vez que declaras el tipo y el alias local, defines los argumentos para ese resource. Los argumentos son los ajustes y valores específicos que configuran el objeto. Aquí es donde pasas los parámetros reales que requiere la API del cloud provider. Para ver cómo encaja todo esto, imagina que estás haciendo un deploy de un resource group de Azure. Declaras el resource type para un resource group de Azure, y le das un alias local como main. Dentro del configuration block, proporcionas los argumentos reales. Defines un argumento name y lo estableces como rg-enterprise-prod, y defines un argumento location asignándole una región específica. Cuando ejecutas tu deploy, Terraform usa el resource type para saber a qué API del provider llamar. Usa tus argumentos para decirle a la API exactamente cómo configurar el resource. En el portal de Azure, tu resource group aparecerá como rg-enterprise-prod. Azure no sabe nada del alias main. Pero de vuelta en tu código, cada vez que necesites recuperar el ID o la location de ese resource group para pasarlo a una máquina virtual o a una base de datos, simplemente le pides a Terraform los datos que contiene el resource local llamado main. Cada resource type tiene su propio conjunto único de argumentos. Algunos son obligatorios, como la location para un resource group o el instance size para un servidor virtual. Otros son opcionales, como el tagging o reglas de enrutamiento específicas. La documentación del provider dicta exactamente qué argumentos puedes usar. Simplemente mapeas los valores que necesitas en el resource block, y Terraform se encarga de la traducción a las API calls que realmente aprovisionan tu infraestructura. Tu identificador local pertenece a Terraform para mantener tu código legible, pero tus argumentos pertenecen al cloud para definir la realidad. Gracias por escucharnos. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 5 de 13. Si una base de datos debe existir antes de que un servidor web pueda conectarse a ella, ¿cómo sabe una herramienta de infraestructura cuál construir primero sin scripts secuenciales? Si vienes de un entorno de scripting imperativo como Bash o Python, podrías buscar formas de forzar la ejecución línea por línea. Pero en Terraform, el orden de las líneas en tu archivo no importa en absoluto. Lo único que importa son las relaciones y dependencias de los recursos. Terraform es un motor de ejecución altamente inteligente. Antes de crear nada, analiza tu configuración y construye un grafo dirigido acíclico. Este grafo mapea con precisión cómo se conecta cada pieza de la infraestructura con las demás. Utiliza este mapa para determinar el orden de creación más eficiente, construyendo recursos no relacionados en paralelo y secuenciando los que dependen unos de otros. Nunca escribes scripts manuales de wait o sleep. La mayoría de las veces, Terraform determina esta secuencia automáticamente a través de dependencias implícitas. Una dependencia implícita ocurre cuando un recurso hace referencia a un attribute de otro recurso. Imagina un escenario en el que estás creando una Virtual Network de Azure y una Subnet. Una subnet no puede existir sin una virtual network. En tu configuración, defines el block de la virtual network y, a continuación, defines el block de la subnet. Dentro del block de la subnet, configuras el argument del nombre de la virtual network para que apunte directamente al attribute name del recurso de virtual network que acabas de definir. Cuando Terraform parsea esto, ve la conexión. Sabe de forma inherente que debe terminar de crear la virtual network y obtener su nombre generado antes de poder siquiera empezar a crear la subnet. No tienes que decirle qué hacer. Simplemente le pasas los datos y Terraform gestiona los tiempos. Esta es la parte que importa. Usa siempre dependencias implícitas si puedes. Al hacer referencia a los attributes directamente, le das a Terraform la información exacta que necesita para optimizar tus deploys de forma segura. A veces, la relación entre dos recursos no es visible en el código. Puedes encontrarte en una situación en la que un recurso necesite que otro esté completamente activo, pero en realidad no necesita extraer ningún dato de él. Imagina hacer el deploy de una máquina virtual que ejecuta una aplicación, mientras también aprovisionas una base de datos gestionada. La aplicación necesita que la base de datos termine de arrancar antes de poder iniciarse. Sin embargo, la configuración de la máquina virtual no hace referencia a ningún attribute del recurso de la base de datos. Como no hay un enlace de datos, Terraform asume que estos dos recursos son completamente independientes e intentará construirlos al mismo tiempo. La aplicación arrancará, buscará una base de datos que aún no existe y fallará. Para solucionar esto, usas dependencias explícitas. Terraform proporciona un meta-argument llamado depends on. Añades este argument al block de la máquina virtual y le pasas una lista que contiene el recurso de la base de datos. Esto le dice explícitamente a Terraform que pause la creación de la máquina virtual hasta que la base de datos haya terminado completamente su provisioning. Deberías tratar las dependencias explícitas como un último recurso. Obligan a Terraform a ser más conservador en su ejecución, lo que ralentiza tus deploys. También pueden hacer que tu configuración sea más difícil de mantener con el tiempo, ya que la razón real de la dependencia no siempre es obvia para el siguiente ingeniero que lea el archivo. Dejar que el grafo de ejecución haga el trabajo pesado es lo que separa la infraestructura declarativa de los scripts procedurales, así que deja de intentar microgestionar el orden de ejecución y deja que el flujo de datos dicte la secuencia. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 6 de 13. Escribes el código de tu infraestructura, ejecutas apply y tus servidores arrancan perfectamente. Pero si vuelves a ejecutar apply cinco minutos después, no pasa nada. Terraform sabe que el trabajo ya está hecho. A diferencia de los simples scripts de automatización que ejecutan comandos sin más, Terraform tiene memoria. Sin ella, estaría totalmente ciego ante la infraestructura que acaba de crear. Esa memoria se llama Terraform State. Cuando ejecutas Terraform, crea un archivo local llamado terraform punto tfstate. Al principio, muchos ingenieros ven este archivo como una molestia. Parece un artefacto extra que hay que gestionar y asegurar. Pero este archivo es el núcleo de cómo funciona Terraform. Terraform necesita un mecanismo para mapear los recursos lógicos definidos en tus archivos de configuración a los objetos físicos remotos que residen en tu entorno cloud. Un error común es pensar que Terraform solo mira los tags del cloud provider para saber qué gestiona. Podrías pensar que le pone un tag a un servidor durante la creación, y luego busca ese tag específico en el cloud para saber qué actualizar. Este enfoque se viene abajo rápidamente. No todos los recursos cloud soportan tags. Además, alguien podría editar o borrar un tag a mano, rompiendo la conexión. Por último, buscar tags específicos en una cuenta cloud enterprise gigante cada vez que ejecutas un plan sería increíblemente lento. Como los tags no son fiables, Terraform usa un state file dedicado y muy estructurado. El state file actúa como una base de datos de mapeo privada. Cuando declaras un recurso en tu código, Terraform lo crea a través de la API del provider. El provider devuelve un identificador físico único para ese objeto recién creado. Terraform coge el nombre de tu recurso lógico del código, lo empareja con ese ID único del cloud, y escribe el par en el state file. Imagina un escenario práctico. Decides cambiar el tamaño de una máquina virtual de Azure en tu código. Cuando ejecutas apply, Terraform no adivina qué máquina modificar. Consulta el state file, busca el nombre de tu recurso lógico y recupera el instance ID exacto de Azure. Luego, envía una request de actualización dirigida a ese ID específico. Sin el state file, Terraform no sabría si debe actualizar una máquina existente o simplemente crear una duplicada. Más allá del mapeo, el state gestiona el tracking de metadatos. Terraform necesita saber el orden exacto en el que se crearon los recursos para poder actualizarlos o destruirlos de forma segura. Si un servidor web necesita una base de datos, esa dependencia está escrita en tu código. Sin embargo, si borras todo ese bloque de código para destruir el entorno, Terraform ya no puede leer el código para encontrar la dependencia. El state file guarda una copia de estos metadatos históricos, asegurando que Terraform destruya el servidor web antes que la base de datos. El state también proporciona una caché crucial para el rendimiento. Consultar la API de un cloud provider para obtener el estado actual de miles de reglas de red, storage buckets y compute nodes lleva muchísimo tiempo. Los cloud providers también imponen API rate limits muy estrictos. El state file actúa como una caché de los atributos de tu infraestructura. Al consultar esta caché, Terraform minimiza el número de API calls lentas y costosas necesarias para calcular un plan. Esta es la clave. Tu configuración describe lo que quieres, el cloud provider tiene lo que existe realmente, y el state file es el único puente definitivo que conecta los dos. Eso es todo por este episodio. ¡Nos vemos en el próximo!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 7 de 13. Hacer hardcoding de valores está bien para una prueba rápida, pero ¿qué sucede cuando necesitas hacer un deploy de esa misma configuración exacta tanto en un entorno de desarrollo como en producción? No puedes duplicar y reescribir tu código para cada nuevo deployment. El mecanismo que resuelve esto es la parametrización con input variables. Las input variables sirven como parámetros para un módulo de Terraform. Te permiten personalizar aspectos de tu infraestructura sin alterar el código fuente subyacente. Este es el paso exacto en el que tu código pasa de ser una prueba de concepto a un template listo para producción. Al usar variables, escribes la configuración una sola vez y la reutilizas en todas partes. Antes de entrar en la mecánica, debemos aclarar una confusión común. Existe una diferencia estricta entre declarar una variable y asignarle un valor. Declarar una variable simplemente le indica a Terraform que existe un parámetro y define sus reglas. Asignar un valor es el acto de proporcionarle datos reales durante un deployment. Declaras una variable usando un bloque variable seguido de un nombre único. Dentro de este bloque, defines el tipo de datos esperado. Terraform admite varios tipos. Un string es simplemente texto normal. Un list es una secuencia ordenada de valores, como múltiples zonas de disponibilidad. Un map es una colección de pares clave-valor, lo cual es perfecto para aplicar tags de recursos estándar. Dentro del bloque variable, también puedes establecer un valor default. Si proporcionas un default, la variable se vuelve opcional. Si el usuario no proporciona un valor durante el deployment, Terraform simplemente utiliza el default. Si no estableces un default, Terraform obligará al usuario a proporcionar un valor antes de continuar. Anclemos esto a un escenario práctico. Supongamos que tienes un deployment en Azure. Ahora mismo, tu configuración solicita explícitamente un tamaño de máquina virtual pequeño llamado Standard B2s, y hace hardcoding de un tag de entorno como dev. Para que esto sea reutilizable, reemplazas ese texto hardcodeado con una referencia. En Terraform, haces referencia a una input variable escribiendo var punto seguido del nombre de la variable. Así, en lugar de escribir Standard B2s, escribes var punto vm size. En lugar de dev, escribes var punto environment. Ahora tu código es flexible, pero Terraform aún necesita saber qué valores usar cuando realmente se ejecuta. Aquí es donde entran en juego los archivos de definición de variables. Estos son archivos que terminan en punto tfvars. Un archivo tfvars es simplemente una lista de nombres de variables y sus valores correspondientes. Para tu deployment de producción, creas un archivo llamado prod punto tfvars. Dentro de él, configuras la variable environment a prod, y la variable vm size a una instancia mayor, como Standard D4s. Cuando ejecutas Terraform, le indicas que apunte a este archivo. Terraform lee el archivo tfvars, inyecta esos valores en tus referencias var punto, y aprovisiona el entorno de producción. Mañana, puedes apuntar el mismo código exacto de Terraform a un archivo dev punto tfvars para levantar un pequeño entorno de pruebas. Esta es la clave. Mantener tu lógica completamente separada de tus datos específicos del entorno es lo que hace que la infraestructura sea verdaderamente repetible. Si estos episodios te resultan útiles y quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 8 de 13. Tu infraestructura cloud termina su deploy perfectamente, pero aún tienes un problema importante: necesitas conocer su dirección IP pública para poder conectarte. Revisar los dashboards del proveedor cloud anula el propósito de la automatización. Necesitas una forma de extraer ese dato específico directamente de Terraform. Aquí es donde entra en juego exponer datos mediante output values. Los output values son, esencialmente, los valores de retorno de una configuración de Terraform. Al definir y crear un recurso, el proveedor cloud genera ciertos atributos dinámicamente. Son cosas que no puedes saber antes del deploy, como una dirección IP asignada, una contraseña de base de datos generada o un nombre de dominio específico. Utilizas bloques output para capturar esos atributos generados dinámicamente y exponerlos al exterior. Para definir uno, escribes un bloque output seguido de una etiqueta. Esta etiqueta es simplemente el nombre que quieres asignar al output. Dentro del bloque, defines un único argumento obligatorio llamado value. Este argumento apunta al dato específico que quieres extraer. Por ejemplo, si creas una máquina virtual, puedes configurar el argumento value para que apunte directamente al atributo de IP pública de ese recurso de máquina específico. Imagina un escenario concreto. Tienes una pipeline automatizada que hace el deploy de un nuevo cluster de Azure Kubernetes Service. Cuando finaliza el deploy, tus desarrolladores necesitan el endpoint de Kubernetes raw generado automáticamente para configurar sus herramientas de conexión locales. Sin un output, alguien tendría que hacer login en el portal cloud, buscar el cluster y copiar la URL manualmente. En su lugar, escribes un bloque output llamado cluster endpoint. Configuras su value para que haga referencia al atributo de fully qualified domain name del cluster de Kubernetes recién creado. Cuando Terraform termina de aplicar tu configuración, recopila todos los output values definidos y los imprime directamente en la interfaz de línea de comandos. Tu pipeline de automatización puede entonces leer ese texto y pasar el endpoint directamente a los desarrolladores. También puedes recuperar estos valores más tarde sin ejecutar un nuevo deploy. Simplemente ejecutas el comando terraform output en tu terminal. Para los scripts de automatización, incluso puedes indicarle a ese comando que devuelva los datos como texto raw o en formato JSON, lo que facilita su parseo por otras herramientas de software. A veces, los datos que necesitas sacar por el output son confidenciales, como una contraseña de base de datos o una clave privada. No quieres que esas strings pasen por una pantalla de terminal compartida ni que se queden permanentemente en los build logs de tu integración continua. Para evitarlo, añades el argumento sensitive dentro del bloque output y lo pones a true. Terraform entonces ocultará el valor real en la pantalla de la consola, reemplazándolo con un tag de placeholder que indica que el valor es sensitive. Aquí está la clave. Configurar un output como sensitive solo lo oculta de la pantalla de la terminal. No cifra ni oculta los datos dentro del state file de Terraform. La contraseña o clave sigue almacenada en texto plano dentro de tus datos de estado en el disco o en tu backend remoto. El flag sensitive es puramente un filtro de visualización para la interfaz de línea de comandos, no un mecanismo de seguridad para tu almacenamiento. Los output values actúan, en última instancia, como tu API de configuración. Son la forma estructurada y predecible en la que devuelves información crítica a los humanos o a las herramientas de automatización en el momento en que finaliza una ejecución. Eso es todo por este episodio. ¡Gracias por escuchar y sigue desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 9 de 13. No toda la infraestructura de tu entorno cloud se creó con el código de Terraform que estás escribiendo. Sin embargo, tu código sigue necesitando una forma de conectarse a esos sistemas existentes de forma segura, sin alterarlos accidentalmente. Hacer queries con Data Sources es exactamente como gestionas esto. Un gran punto de confusión al aprender Terraform es la diferencia entre un resource block y un data block. Vamos a aclararlo ahora mismo. Un resource block le dice a Terraform que cree, actualice y gestione un objeto de infraestructura. Un data block solo hace un lookup de solo lectura. Le pide a la API del provider que encuentre un objeto existente y devuelva sus detalles para que tu configuración pueda leerlos. Esta capacidad de solo lectura es la base de una arquitectura de infraestructura desacoplada. Imagina un setup empresarial estándar. Un equipo de networking centralizado crea y gestiona la Virtual Network corporativa. Como desarrollador de aplicaciones, necesitas hacer deploy de una Virtual Machine de Azure y conectarla a esa red exacta. El código de la red no es tuyo. Tampoco deberías hacer hardcode del ID único de la red en tus archivos de Terraform, porque los IDs hardcodeados se rompen fácilmente si alguna vez se recrean los entornos. En su lugar, simplemente haces un lookup de la red. Esto lo haces definiendo un data block. La sintaxis se parece mucho a la de un resource block. Empiezas con la keyword data. Después, especificas el tipo de data source, como azurerm virtual network. Luego le das un nombre local, como corporate, que usarás para referenciarlo más adelante en tu código. Dentro del bloque, defines los argumentos de búsqueda. Estos actúan como filtros estrictos. Podrías pasar el nombre legible de la Virtual Network y el resource group al que pertenece. Terraform usa estos argumentos para construir una query. Cuando ejecutas un Terraform plan, Terraform se conecta a la API de Azure y busca una Virtual Network que coincida con tus filtros. Si la API devuelve exactamente un match, Terraform descarga las propiedades de esa red en memoria. Si la query devuelve cero matches, o si los filtros son demasiado permisivos y devuelven múltiples matches, Terraform se detiene inmediatamente y lanza un error. Esta rigidez es intencionada. Evita que hagas deploy de tu aplicación accidentalmente en la subnet o el entorno equivocados. Una vez que el data source obtiene la información correctamente, puedes extraer cualquier atributo exportado de él. La sintaxis para referenciar un data source está muy estructurada. Empiezas con la palabra data, seguida de un punto, el tipo de data source, un punto, tu nombre local y, finalmente, el atributo específico que necesitas. En nuestro escenario, escribirías data punto azurerm virtual network punto corporate punto id. Pasas esa string específica directamente a tu resource block de la Virtual Machine, evitando por completo la necesidad de hacer hardcode de un valor estático. Aquí viene la parte importante. Los data sources te permiten tratar tu infraestructura circundante como un servicio dinámico. No tienes que construir el entorno para interactuar con él, y puedes unir workspaces independientes de forma segura simplemente haciendo una query de los identificadores exactos que necesitas en runtime. Gracias por pasarte. Espero que hayas aprendido algo nuevo.

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 10 de 13. Si necesitas hacer deploy de cincuenta servidores web idénticos, lo último que quieres es copiar y pegar el mismo bloque de código cincuenta veces. Podrías buscar un while-loop o un for-loop tradicional, pero Terraform no funciona así. En su lugar, gestionas la escala a nivel de bloque usando count y for each. Por defecto, un bloque resource configura exactamente un objeto de infraestructura. Para provisionar múltiples objetos, añades el meta-argumento count dentro de ese bloque. Acepta un número entero. Si pones el count a tres, Terraform provisiona tres objetos a partir de ese único bloque de configuración. Estos objetos normalmente no pueden ser estrictamente idénticos en el mundo real. Necesitan nombres o direcciones IP únicas. Para gestionar esto, Terraform proporciona el objeto count punto index. Esta es una variable especial disponible solo dentro de los bloques que tienen un argumento count. Supongamos que estás haciendo deploy de tres máquinas virtuales de Azure. Escribes un bloque resource para la máquina virtual y pones el count a tres. Dentro del bloque, asignas el nombre de la máquina combinando la palabra web, un guion y el valor de count punto index. Como el index empieza en cero, Terraform evalúa este bloque y genera tres máquinas distintas llamadas web-zero, web-one y web-two. Añadir count cambia cómo Terraform trackea el recurso internamente. Un único recurso se identifica simplemente por su tipo y nombre. Una vez que añades count, esa address se convierte en un array. Ahora, en otras partes de tu código, referencias a instancias específicas usando sus números de index entre corchetes. Count es muy eficiente, pero tiene un riesgo mecánico específico relacionado con el orden de la lista. Esta es la clave: count identifica los recursos únicamente por su posición entera. Si usas una lista de valores para configurar un bloque con count, la posición del index es lo único que le importa a Terraform. Si tienes tres elementos y cambias el count a dos, Terraform destruye el último elemento del array, el index dos. Si inyectas un nuevo string en medio de tu lista de origen, todas las posiciones de index siguientes se desplazan hacia abajo. Terraform notará que la configuración para el index uno ha cambiado, la del index dos ha cambiado, y así sucesivamente. Es muy probable que destruya y recree infraestructura en perfecto estado simplemente porque el orden de la lista de origen cambió. Para solucionar esta vulnerabilidad, en su lugar usas el meta-argumento for each. Mientras que count acepta un número entero, for each acepta un map o un set de strings. En lugar de crear un array de objetos indexados por números secuenciales, for each crea un map de objetos trackeados por string keys explícitas. Si le pasas un set que contiene los strings frontend y backend, Terraform crea recursos identificados por esos nombres exactos. Si luego añades un nuevo string, o eliminas uno, Terraform solo añade o destruye ese recurso específico. El resto permanece intacto porque sus identificadores son string keys fijas, no posiciones numéricas frágiles. Usa count cuando los objetos de infraestructura sean realmente intercambiables, pero cambia a for each en el momento en que esos objetos requieran identidades distintas que deban sobrevivir a los cambios en tu lista de configuración. Gracias por escucharnos. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 11 de 13. Tu único fichero de configuración de Terraform funcionaba bien para un servidor web sencillo, pero a medida que tu infraestructura crece, se está convirtiendo rápidamente en un monolito desordenado e ilegible. Estás copiando y pegando los mismos resource blocks una y otra vez solo para cambiar un string de nombre o un tag de entorno. Es hora de dejar de repetir código y crear componentes reutilizables con módulos. Un módulo es un contenedor para múltiples resources que se utilizan conjuntamente. Si estás familiarizado con algún lenguaje de programación, puedes pensar en un módulo como una función. Escribes la lógica compleja una vez, la encapsulas y luego la llamas varias veces desde cualquier otro lugar. En Terraform, cada configuración ya tiene al menos un módulo. Los ficheros que se encuentran en tu directorio de trabajo principal forman lo que se denomina el root module. Cuando tu root module hace referencia a otro conjunto de ficheros de configuración, ese segundo conjunto se conoce como child module. Imagina un escenario específico. Un equipo centralizado de DevOps quiere garantizar que todas las storage accounts creadas en la empresa sean seguras por defecto, con cifrado, private endpoints y diagnostic logging estrictamente implementados. En lugar de confiar en que cada desarrollador de aplicaciones configure correctamente diez resources complejos diferentes, el equipo de DevOps crea un módulo estándar de Secure Azure Storage. Cuando un equipo de aplicaciones necesita almacenamiento, no escribe un bloque enorme de definiciones de resources. Simplemente escribe un module block en su root configuration. Dentro de ese module block, lo primero que define es un argumento source. El source le indica a Terraform exactamente dónde encontrar los ficheros del child module, ya sea una ruta de directorio local o un repositorio remoto. Debajo del source, el equipo de aplicaciones pasa argumentos. Al igual que al pasar argumentos a una función, proporcionan los datos específicos que el child module necesita para ejecutarse, como un nombre de aplicación único o un identificador de entorno. Estos argumentos se mapean directamente a las input variables definidas dentro del child module. El child module toma esos inputs, ejecuta las configuraciones de resources subyacentes y construye la infraestructura. El equipo de aplicaciones obtiene un almacenamiento compliant automáticamente, completamente aislado de la complejidad subyacente. Aquí está la clave. A menudo, la gente se confunde sobre cómo Terraform gestiona el scope entre estos módulos. Al llamar a un child module, los resources que contiene están estrictamente encapsulados. Tu root module no puede leer directamente una dirección IP, un connection string o un storage ID generado dentro de ese child module. El child module es una caja negra. Si tu root module necesita un dato que se ha generado dentro del child module, el child module debe exportarlo explícitamente mediante un output block. Las variables actúan como parámetros de entrada y los outputs como valores de retorno. Forman una interfaz estricta. Una vez que el child module exporta esos datos como un output, el root module por fin puede leerlos. Accedes a estos datos haciendo referencia a la palabra module, seguida del nombre específico que asignaste a tu module block, y luego el nombre del output. Si el child module devuelve como output un ID de storage account generado, tu root module puede obtenerlo usando esa sintaxis y pasarlo a una base de datos o a una máquina virtual que necesite conectarse a él. El verdadero poder de los módulos no es solo ahorrar líneas de código. Es la capacidad de definir un estándar arquitectónico una sola vez, ocultar la complejidad y presentar una interfaz limpia y predecible al resto de tu organización. Gracias por escuchar. Cuidaos todos.

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 12 de 13. Un state file local en tu disco duro funciona perfectamente cuando trabajas solo. Pero en el momento en que dos ingenieros intentan actualizar la misma infraestructura en el mismo segundo, tienes la receta perfecta para un entorno corrupto. Este es el punto de inflexión entre la experimentación individual y la colaboración en equipo, y nos lleva a la enterprise readiness: remote state y locking. Por defecto, Terraform escribe su vista actual de tu infraestructura en un archivo local llamado terraform punto tfstate. Este archivo es la source of truth crítica que mapea tu código de configuración con los recursos del mundo real. El problema surge cuando añades más personas a tu proyecto. Si un compañero realiza un cambio desde su máquina, tu portátil no se entera de que el entorno acaba de cambiar. Estás trabajando con información desactualizada. A veces, los equipos intentan solucionar esto haciendo commit del state file a su sistema de control de versiones. Esto supone un grave riesgo de seguridad. Los state files suelen almacenar datos confidenciales, como contraseñas de bases de datos o claves privadas, en plain text. El enfoque correcto consiste en configurar un remote backend. En lugar de guardar el state file en una máquina local, Terraform lee y escribe estos datos desde un data store centralizado y seguro. Normalmente, se trata de un servicio de object storage como un bucket de Amazon S3, un contenedor de Azure Blob Storage o un bucket de Google Cloud Storage. Al usar un remote backend, cada vez que alguien ejecuta un comando, Terraform consulta ese storage central para obtener la imagen más precisa y actualizada de la infraestructura. Transicionar a esta configuración requiere añadir un bloque de configuración de backend a tu código, definiendo dónde debe residir el state. Presta atención a este punto. Un error muy común es escribir esa configuración, guardar el archivo y asumir que el state ahora es remote. No lo es. Después de añadir el bloque de backend, debes ejecutar terraform init de nuevo. Ejecutar este comando de inicialización es el trigger que le dice a Terraform que copie físicamente tu state file local existente y lo migre al cloud backend. Mover el state file a una ubicación compartida resuelve el problema de visibilidad, pero te expone a modificaciones concurrentes. Si dos pipelines de deploy activan una actualización simultáneamente, ambos podrían intentar escribir en el remote state file al mismo tiempo, corrompiéndolo por completo. Por este motivo, los remote backends soportan state locking. Consideremos un entorno que utiliza Azure Blob Storage para su remote state. Dos ingenieros trabajan en actualizaciones diferentes. El ingeniero A ejecuta un apply. Antes de realizar cualquier cambio en los recursos cloud reales, Terraform se conecta al contenedor de Azure Storage y pone un lock en el remote state file. Una fracción de segundo después, el ingeniero B intenta ejecutar su propio apply. Terraform comprueba el remote backend, detecta el lock activo e intercepta inmediatamente el run del ingeniero B. En lugar de colisionar, Terraform se detiene de forma segura y devuelve un error, explicando que otro proceso tiene actualmente el lock. Una vez que el primer run finaliza correctamente, Terraform libera automáticamente el lock. Implementar un remote backend con lock es el paso definitivo para la infrastructure as code a nivel enterprise. Protege tus datos confidenciales y elimina las peligrosas race conditions. El remote state garantiza que, independientemente de quién ejecute el código o desde dónde, todo tu equipo esté firmemente anclado a la misma realidad exacta. ¡Gracias por escuchar, happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Terraform, episodio 13 de 13. Has escrito tu configuración, la has probado localmente y has hecho el deploy de tus recursos. Pero ejecutar cambios de infraestructura desde el portátil de un desarrollador es un cuello de botella, no una estrategia. Los applies manuales provocan conflictos en el state, cambios sin revisar y riesgos de seguridad. La automatización real se ejecuta de forma segura en un pipeline, lanzado automáticamente por el control de versiones. Esto nos lleva a los workflows empresariales y al CI/CD. Cuando pasas de trabajar solo a trabajar en equipo, el workflow principal de Write, Plan y Apply desaparece por completo de tu máquina local. El control de versiones se convierte en la fuente de la verdad absoluta. Dejas de ejecutar comandos directamente y dejas que los pipelines de integración continua orquesten los cambios en el state. Aquí está la clave. El pipeline divide la fase tradicional de plan en dos conceptos distintos: planes especulativos y planes concretos. Entender la diferencia es crucial para diseñar el pipeline. Imagina a un desarrollador que necesita aumentar el tamaño de una máquina virtual en Azure. Actualiza el tamaño de la instancia en la configuración, hace un commit del código y abre una Pull Request. En ese preciso instante, el pipeline lanza automáticamente un plan especulativo. Un plan especulativo simplemente muestra lo que Terraform tiene intención de hacer. Comprueba el código propuesto contra el state remoto para calcular el delta, pero es estrictamente de solo lectura. No se le puede hacer un apply bajo ninguna circunstancia. El pipeline coge el output de este plan especulativo y lo publica directamente como un comentario de texto en la Pull Request. Cuando un ingeniero senior revisa el código, no solo ve el cambio en la sintaxis. Ve el impacto exacto en la infraestructura. Sabe con precisión qué recursos de Azure se van a modificar, crear o destruir antes de dar su aprobación. Una vez que la Pull Request se aprueba y se hace el merge a la rama main, el pipeline lanza la segunda fase. Genera un plan concreto contra esa rama main. Este es un archivo de plan ejecutable. Como la rama main es la fuente de la verdad de confianza, el pipeline coge este plan concreto y le hace un apply inmediatamente. La infraestructura en vivo se actualiza automáticamente por el robot, no por un humano. Ejecutar Terraform de forma automatizada abre la puerta a controles empresariales avanzados. La política como código, usando frameworks como Sentinel, se integra directamente en este pipeline. Sentinel evalúa el plan antes de que llegue a ocurrir el apply. Si un desarrollador solicita por accidente una instancia de base de datos que viola las restricciones de costes o las reglas de compliance, el motor de políticas lo detecta y detiene el pipeline inmediatamente. Este workflow automatizado es lo que permite un modelo de infraestructura de autoservicio. Los ingenieros de plataforma construyen y prueban módulos reutilizables, mientras que los desarrolladores de aplicaciones simplemente envían una Pull Request pidiendo los recursos que necesitan. El pipeline hace el plan del cambio, la política como código verifica el compliance, y un compañero revisa la intención. El equipo de aplicaciones consigue su infraestructura rápidamente, y el equipo de plataforma aplica la seguridad sin actuar como un obstáculo manual. Con esto concluye nuestra serie de fundamentos. Ahora ya sabes cómo Terraform escala desde un único comando local hasta un motor empresarial automatizado. La mejor manera de consolidar este conocimiento es construir algo, leer la documentación oficial y experimentar con estos pipelines tú mismo. Si tienes ideas para futuros temas, visita devstories dot eu. Me gustaría tomarme un momento para darte las gracias por escucharnos; nos ayuda muchísimo. ¡Que tengas un buen día!