El cloud, con su amplio conjunto de soluciones que lo ofrecen todo, desde comunicaciones en red sencillas hasta computación «a escala planetaria», se está convirtiendo en el hogar de facto de la mayoría de las organizaciones independientemente de su tamaño. El ecosistema de la mayoría de los proveedores de cloud es ahora más grande que nunca e incluye máquinas virtuales sencillas, clústeres administrados complejos e incluso infraestructura con un alto grado de sofisticación. Microsoft Azure, por ejemplo, ofrece una gran variedad de servicios bien diseñados para los usuarios finales. Estas soluciones se basan en una infraestructura resiliente por naturaleza y tienen acuerdos de nivel de servicio (SLA) bien definidos1 para satisfacer las necesidades de todos los clientes, desde pequeñas start-ups hasta grandes empresas.
Aunque la naturaleza dinámica de la computación en el cloud es una bendición para las organizaciones, puede ser difícil mantener servicios en entornos de cloud a medida que crece tu organización. Cuando utilices cada vez más servicios basados en el cloud para satisfacer tus crecientes necesidades empresariales, te darás cuenta rápidamente de que ya no puedes mantener tus aplicaciones y la infraestructura subyacente haciendo clic simplemente en la consola web cada vez que quieras realizar una nueva acción. El diseño evolutivo del cloud se basaba en generaciones anteriores de hardware e infraestructura virtualizada con un plano de control programable que proporciona flexibilidad en forma de capas de API. Estas API las utilizan las herramientas de infraestructura como código (IaC) para permitir a los profesionales del cloud mantener fácilmente sus entornos.
Cuando se desea crear una infraestructura de producción desde cero, hay que empezar a tratar las definiciones de infraestructura de la misma manera que se trata el código. El aprovisionamiento y escalado manual de la infraestructura no solo es engorroso y laborioso; también es un proceso propenso a errores: no se puede crear la misma infraestructura dos veces con el mismo nivel de confianza. En lo que respecta a la infraestructura como código, también se heredan los principios de ingeniería de software, como el control de versiones, la capacidad de prueba, la automatización y la velocidad de desarrollo como parte de la estrategia de DevOps. IaC garantiza que tu infraestructura se pueda crear de una manera coherente y repetible. Ahora que hay más equipos de desarrollo de software que han adoptado metodologías Agile, estos equipos se ven obligados a mover características y soluciones con mayor frecuencia y más rapidez al cloud. Por tanto, la infraestructura está estrechamente relacionada con las aplicaciones y se requiere que los equipos administren las aplicaciones y la infraestructura a través de un proceso fluido. Además, los equipos necesitan iterar e implementar repetidamente nuevas características e infraestructura subyacente con más frecuencia. Una forma rápida de implementar IaC es utilizar las plantillas predefinidas ofrecidas por los proveedores de cloud, que proporcionan instrucciones sobre cómo crear una infraestructura. Azure admite de forma nativa las plantillas de Azure Resource Manager (ARM), que se utilizan para definir y crear recursos de infraestructura, y arrojan luz sobre la filosofía de IaC. Esta combinación del cloud e IaC permite a las organizaciones introducir cambios de forma más rápida y eficiente.
Este capítulo sirve de base para desarrollar un amplio conocimiento de IaC y Azure. En primer lugar, presentaremos el concepto de IaC y su importancia en la creación de infraestructura nativa en el cloud. A continuación, presentaremos Microsoft Azure, el proveedor de cloud que utilizaremos a lo largo del libro.
Seguidamente, profundizaremos en Terraform como herramienta para implementar IaC. También vamos a hablar de Packer, que es básicamente una herramienta para crear imágenes de máquina, y Ansible, para presentarte la administración de la configuración mientras creas aplicaciones nativas en el cloud. Por último, hablaremos de Azure DevOps antes de concluir el capítulo. Empecemos.

La infraestructura como código y su importancia en el mundo nativo del cloud
En el pasado, cuando un equipo de TI quería adquirir hardware nuevo para la implementación de aplicaciones, primero tenía que iniciar una solicitud de aprovisionamiento de hardware, que tardaba días o incluso semanas en completarse. Incluso después de que el hardware se entregara finalmente on-premises, se tardaban unos días más en tenerlo funcionando para que las aplicaciones pudieran implementarse en él. Hoy en día, con el crecimiento de DevOps y el cloud, estos procesos lentos han desaparecido. Los ciclos de lanzamiento se han vuelto más cortos y la velocidad con la que se pueden cumplir los requisitos empresariales ha aumentado.
Sin embargo, incluso con la introducción del cloud, la administración de la infraestructura sigue siendo un problema. Aunque los servidores físicos se reemplazaron por servidores virtuales y la administración de infraestructura compleja pasó a ser responsabilidad del proveedor de cloud, el crecimiento y el escalado de la infraestructura seguían siendo tareas difíciles y propensas a errores. Los equipos de ingeniería necesitaban crear constantemente nuevas infraestructuras y pilas de software mientras continuaban manteniendo la infraestructura antigua. Para aliviar el tedio y el agotamiento asociados a estas tareas, se automatizó la creación y gestión de sistemas basados en el cloud, lo que dio lugar a un entorno de infraestructura y aplicaciones robusto.
Con el tiempo, a medida que se adaptaba el código para aprovisionar las capas de computación, redes y almacenamiento de la pila, se hicieron evidentes los beneficios de tratar la infraestructura como código. Esto condujo al movimiento de la adaptación de IaC en entornos de cloud.
La infraestructura como código es un enfoque que consiste en tratar la infraestructura como instrucciones programables. Al igual que se comprueban los archivos de control de código fuente, se comprueban las definiciones de la infraestructura. Tratar la infraestructura como código proporciona numerosas ventajas, incluidas las siguientes:

• La capacidad de comprobar una versión de las definiciones de infraestructura y revertir a una versión determinada en caso de que surja un problema
• La idempotencia, que te permite reproducir exactamente la misma infraestructura con el mínimo esfuerzo
• Registro, supervisión y solución de problemas estandarizados en toda la pila
• Reducción de los puntos únicos de error en tus equipos de ingeniería (es decir, cuando solo un ingeniero sabe crear un tipo determinado de sistema)
• Mayor productividad del desarrollador (los ingenieros de fiabilidad del sitio [SRE] o los ingenieros de DevOps pueden dedicarse a escribir código que los desarrolladores pueden usar para crear un entorno de prueba)
• Interacción manual mínima, que da lugar a una infraestructura menos propensa a errores
• Reducción drástica del tiempo medio de recuperación (MTTR) ante errores
• La capacidad de probar tu infraestructura incluso antes de que se cree

Con los beneficios de IaC, es evidente que estas herramientas desempeñan un papel importante en los entornos nativos del cloud modernos donde las aplicaciones deben cambiar sobre la marcha. Los cambios pueden ser menores, como añadir una nueva etiqueta de configuración, o más importantes, como añadir nuevos clústeres para mantenerse al día con los requisitos de capacidad. Una estrategia de IaC fiable ayuda a los desarrolladores a administrar estos cambios fácilmente sin renunciar a la velocidad del proceso de desarrollo de software. Una vez integrada la IaC en el núcleo del proceso de creación de la infraestructura, también ayuda a crear una infraestructura antifrágil.

Infraestructura antifrágil
La infraestructura antifrágil son sistemas que pueden soportar el estrés y mostrar elasticidad, además de resiliencia. «Antifrágil» hace referencia a la creación de una infraestructura que pueda manejar eventos impredecibles e irregulares mientras se hace más fuerte.

Las aplicaciones nativas en el cloud actuales se consideran aplicaciones en movimiento, ya que la infraestructura subyacente también sigue cambiando y actualizándose. El cloud te permite tratar tus infraestructuras como entidades de corta duración en lugar de entidades permanentes. El enfoque nativo del cloud aboga por la creación de infraestructuras reemplazables en lugar de la reparación de la infraestructura rota. Dado que el enfoque nativo del cloud desvincula las aplicaciones de la infraestructura, ofrece a los ingenieros el control y la confianza necesarios para realizar cambios en la infraestructura, sabiendo que pueden dar marcha atrás y avanzar con facilidad.

Filosofía de infraestructura nativa en el cloud
Cuando crees infraestructura nativa en el cloud, trata siempre tu infraestructura subyacente como entidades de corta duración en lugar de sistemas de larga duración y mantenibles. Esto significa que si un servidor deja de funcionar, será fácil destruirlo y poner en funcionamiento un nuevo servidor al instante, en lugar de intentar arreglarlo.

El cambio de la arquitectura monolítica a los microservicios también ayudó a la IaC a ganar impulso al garantizar que las aplicaciones modernas fueran capaces de seguir la metodología de «aplicaciones de nueve factores», lo que permite tomar decisiones de infraestructura con independencia del desarrollo de aplicaciones. Otra ventaja importante de la IaC en a creación de infraestructura nativa en el cloud es que permite una infraestructura inmutable; es decir, una vez que la infraestructura se implementa, no se puede cambiar ni configurar. En un escenario típico de implementación de aplicaciones mutables, se desarrolla una aplicación, después se implementa en la infraestructura subyacente y, finalmente, se configura en la infraestructura subyacente (figura 2-1). Este proceso introduce una desviación de la configuración, cuyo resultado es una infraestructura que es diferente de su estado inicial. La infraestructura inmutable, sin embargo, consiste en la reimplementación de la infraestructura y las aplicaciones cada vez que se inserta un nuevo cambio, lo que mantiene la infraestructura en su estado exacto. La inmutabilidad se logra desarrollando y configurando la aplicación en un estado preconfigurado (por ejemplo, una imagen de máquina) e implementándola después (figura 2-2).

Las principales ventajas de crear infraestructuras inmutables son:

• Infraestructura/sistemas predecibles en lugar de infraestructura/sistemas reactivos
• Implementaciones que ahora son atómicas por naturaleza
• Más control de la infraestructura, lo que conduce a una mejor telemetría

Ahora que hemos hablado de la IaC y sus ventajas a la hora de crear infraestructura nativa en el cloud, veamos cómo puedes usar Microsoft Azure en tu infraestructura nativa en el cloud.

Introducción a Azure y configuración del entorno
Microsoft Azure es un proveedor de cloud con decenas de regiones en todo el mundo. Azure te permite crear e implementar rápidamente la infraestructura a través de medios manuales y automatizados, como comentaremos a lo largo de este libro. Azure como PaaS (plataforma como servicio) ofrece mucha flexibilidad a la comunidad de desarrolladores para innovar, crear e implementar aplicaciones. Elegimos Azure como nuestro entorno de cloud por su velocidad, flexibilidad, seguridad, recuperación ante desastres y una curva de aprendizaje sencilla.
En esta sección, explicaremos conceptos básicos sobre Azure y cómo crear una cuenta de Azure.

Fundamentos de Azure y preparación del entorno
Antes de empezar a usar Azure, es importante conocer algunos de sus componentes básicos. Conocer estos conceptos te ayudará a fundamentar las decisiones de políticas en el futuro

Inquilino
Un inquilino de Azure es una representación de Azure Active Directory (AAD) de una organización. Probablemente ya estés familiarizado con los servicios tradicionales de Active Directory (AD). Cuando una organización crea una cuenta con Microsoft, se crea una instancia de AAD.
Todas las instancias de AAD están completamente separadas unas de otras, al igual que todas las identidades (cuentas de usuario o servicio). Si tienes un inquilino de Microsoft (por ejemplo, para Office 365), puedes utilizarlo para tus soluciones de Azure. También puedes crear tu propio inquilino de AAD a través de Azure Portal. Recuerda habilitar la autenticación multifactor (MFA)2 en tu inquilino.

Suscripciones
Las suscripciones de Azure son esencialmente un contenedor de facturación para tus recursos. También puedes definir políticas específicas de Azure en el nivel de suscripción.
Grupos de administración
Los grupos de administración de Azure proporcionan un medio para organizar y administrar las suscripciones. Puedes utilizar grupos de administración para aplicar políticas/gobierno a todos los recursos (incluidas las suscripciones) dentro del grupo de administración. Todas las suscripciones del grupo de administración heredarán la política del grupo de administración de forma predeterminada.
Grupos de recursos
Un grupo de recursos es un contenedor que almacena recursos relacionados para una solución de Azure. El grupo de recursos incluye los recursos que deseas administrar como grupo. Tú decides qué recursos pertenecen a un grupo de recursos en función de lo que tenga más sentido para tu organización. Además, los recursos pueden estar ubicados en diferentes regiones del grupo de recursos.
Regiones
Una región de Azure contiene dos o más zonas de disponibilidad. Una zona de disponibilidad es un centro de datos físicamente aislado en una región geográfica.

En la figura 2-3 se ilustra cómo se asocian entre sí estos componentes básicos

Creación de una cuenta de Azure
Puedes crear una cuenta de Azure yendo a https://azure.microsoft.com y utilizando el plan gratuito. Deberás iniciar sesión con una cuenta de Microsoft; puedes usar una cuenta de Hotmail, Outlook u Office 365, aunque te recomendamos que utilices también MFA. Sigue las instrucciones del sitio web de Azure para crear tu cuenta. Para continuar, haz clic en el enlace Mi cuenta en la esquina superior derecha o ve directamente a Microsoft Azure Portal.Ahora vamos a hablar de cómo usar la CLI de Azure.

Instalación de la CLI de Azure
La CLI de Azure es un conjunto de comandos que se pueden utilizar para crear y administrar recursos de Azure. Puedes utilizar la CLI en el navegador web en Azure Portal o puedes descargar la versión correspondiente para instalarla localmente en tu máquina. Por ejemplo, en macOS puedes instalar la CLI de Azure con el comando brew install azure-cli.
Puedes interactuar con Azure a través del portal usando el comando az de la siguiente manera:

Incluso puedes utilizar la CLI de Azure para crear scripts declarativos en tu infraestructura en el cloud. Estos scripts se pueden ejecutar en PowerShell o Bash. Aunque los scripts de Azure funcionan bien para tareas como la creación, el desmontaje y la nueva implementación de la infraestructura, tareas como actualizar un entorno existente no son sencillas debido a la falta de idempotencia en los comandos de la CLI de Azure.
Además de Azure, hay otras herramientas disponibles para crear y administrar entornos de cloud. A continuación, veremos algunas de las más destacadas.

Herramientas de IaC destacadas
Como se mencionó anteriormente, se pueden utilizar herramientas adicionales para crear infraestructura nativa en el cloud siguiendo el enfoque de IaC. Aquí nos centraremos en tres de las herramientas de código abierto más populares que se pueden utilizar con una variedad de proveedores de cloud:

• Terraform, una herramienta de IaC basada en CLI
• Packer, una herramienta de CLI para crear imágenes de máquina
• Ansible, una herramienta de administración de la configuración

Puedes utilizar todas estas herramientas también en configuraciones de integración/implementación continua (CI/CD); en este escenario, en cuanto escribas una nueva configuración, la puedes integrar continuamente en la canalización de implementación.

Terraform
Terraform es una herramienta IaC de código abierto de HashiCorp, escrita en el lenguaje de programación Go. La palabra terraform significa transformar el entorno de un planeta para que se asemeje a la atmósfera de la tierra, de modo que los seres humanos podamos vivir en él. Esta analogía se aplica cuando observas a los proveedores de cloud como entornos que deben transformarse en una infraestructura manejable para ayudar a tu aplicación a aprovechar al máximo el cloud y alcanzar su verdadero potencial.
Terraform te ayuda a crear, cambiar y versionar la infraestructura en el cloud de una manera segura y eficiente. Utiliza una sintaxis declarativa, lo que significa que solo tienes que decirle qué deseas crear en lugar de cómo deseas crearlo. Una ventaja importante de Terraform es su compatibilidad con un lenguaje específico del dominio (DSL) fácil de entender llamado HashiCorp Configuration Language (HCL), que es relativamente fácil de interpretar para las personas. Otra opción es usar JSON para la misma finalidad. Además, Terraform es independiente del cloud y, por lo tanto, es compatible con varios proveedores de cloud, lo que hace que sea muy fácil de aprender, ya que no tienes que volver a aprender el lenguaje (HCL/JSON) para un proveedor de cloud diferente. En esta sección, explicaremos cómo se puede utilizar Terraform para crear infraestructura sobre Azure utilizando la filosofía de IaC.
Para que entiendas cómo funciona Terraform, primero tenemos que examinar alguna terminología básica:

Proveedores
Un proveedor en Terraform es normalmente (pero no siempre) un proveedor de cloud. La responsabilidad del proveedor es exponer los recursos (por ejemplo, recursos en el cloud) e interpretar la API. Algunos de los proveedores admitidos por Terraform son Azure, Amazon Web Services (AWS), Google Cloud Platform (GCP) y PagerDuty.
Plan
Cuando creas tu infraestructura mediante el comando terraform plan, Terraform crea un plan de ejecución que se basa en el código que escribes a través de los archivos de configuración (.tf). El plan de ejecución incluye los pasos que realizará Terraform para crear la infraestructura solicitada.
Apply
Cuando estés satisfecho con el plan que ha creado Terraform, puedes usar el comando terraform apply para crear la infraestructura, que finalmente alcanzará el estado deseado (si no hay conflictos ni errores).

Estado
Terraform requiere una forma de almacenar el estado de la infraestructura para que pueda administrarla. Los estados se almacenan en archivos de estado basados en texto que mantienen la correspondencia entre los recursos del cloud y tu configuración. Por lo general, Terraform puede almacenar el estado de la infraestructura de dos maneras: localmente en el sistema donde lo inicializas o de forma remota. Almacenar el estado de forma remota es el método recomendado, porque mantiene la copia de seguridad del estado de la infraestructura y pueden reunirse más ingenieros para crear infraestructura, ya que ahora hay una única fuente de verdad que permite conocer el estado actual de la infraestructura. Los archivos de estado no deben registrarse en un repositorio Git, ya que pueden contener secretos; puedes utilizar Azure Blob Storage en su lugar. Terraform también admite el bloqueo predeterminado de los archivos de estado.
Módulo
Un módulo de terraform es un grupo formado por una gran cantidad de recursos que se utilizan juntos. Los módulos ayudan a crear infraestructura reutilizable abstrayendo los recursos que se configuran una vez y se utilizan varias veces. Una de las principales ventajas del uso de módulos es que te permiten reutilizar código que se puede compartir posteriormente con los equipos para distintos proyectos.
Back-end
Un back-end describe cómo se cargará un estado. Es donde se almacenará finalmente el archivo de estado. Puedes utilizar el almacenamiento de archivos local o el almacenamiento de blobs de Azure con este propósito.

En la figura 2-4 se muestran los bloques provider y resource. El bloque provider indica la versión de Azure Resource Manager, mientras que los dos bloques resource crean el grupo de recursos de Azure y la red virtual.

Ahora que hemos presentado los fundamentos de Terraform, veamos cómo funcionan juntos para aprovisionar infraestructura nativa en el cloud en Azure. En la figura 2-5 se ilustra el flujo de trabajo general.

Para empezar a usar Terraform, sigue estos pasos:

1. Inicializa Terraform con el comando terraform init. No puedes ejecutar plan ni apply si no has inicializado el directorio.
2. Después de inicializar correctamente Terraform, crea el plan de ejecución o un simulacro con el comando terraform plan.
3. Cuando estés satisfecho con el resultado del plan, crea tu infraestructura con el comando terraform apply.

En función del proveedor que utilices, la infraestructura se aprovisionará en el entorno del proveedor de cloud correspondiente (en nuestro caso, es Microsoft Azure). Si quieres destruir tu infraestructura, puedes simplemente ejecutar el comando terraform destroy, que eliminará la infraestructura correspondiente al directorio actual. Es muy importante prestar especial atención al eliminar la infraestructura con Terraform.

Ten mucho cuidado cuando elimines la infraestructura con Terraform. Una vez que se elimina una infraestructura, el archivo de estado se actualiza con los valores actualizados. Antes de eliminar la infraestructura, comprueba visualmente el resultado de terraform destroy para no eliminar accidentalmente la información importante.

Ahora que ya tienes conocimientos generales sobre el flujo de trabajo y los detalles operativos, vamos a seguir trabajando con Terraform

Instalación de Terraform
Para instalar Terraform en tu equipo,3 primero debes encontrar el paquete binario correspondiente a tu sistema operativo. Si utilizas Azure Cloud Shell, se empleará la última versión de Terraform de forma predeterminada. En el momento de escribir este libro, la versión actual de Terraform es 0.12.28. Para encontrar el paquete binario adecuado:

Cuando tengas el archivo ZIP, descomprime el binario y muévelo a /usr/local/bin. Puedes verificar que Terraform está instalado utilizando la ayuda de Terraform desde el shell:

Configuración del acceso de Terraform a una cuenta de Microsoft Azure
Ahora que has configurado tu cuenta de Azure e instalado Terraform localmente, puedes configurar Terraform para que acceda a tu cuenta de Azure:

1. Haz clic en el icono de Cloud Shell en la esquina superior derecha de tu cuenta de Azure Portal y, a continuación, haz clic en «Crear almacenamiento». Se creará una nueva cuenta de almacenamiento. Este proceso tarda unos minutos.
2. Después de seleccionar Cloud Shell, puedes elegir Bash o PowerShell. También puedes cambiar el shell más adelante si quieres. A lo largo de este libro, vamos a utilizar el shell Bash. Una vez que se haya completado la configuración, verás lo siguiente:
   Requesting a Cloud Shell.Succeeded.
   Connecting terminal…
   Welcome to Azure Cloud Shell
   Type «az» to use Azure CLI
   Type «help» to learn about Cloud Shell
   $
3. Ahora debes obtener una lista de valores de id. de suscripción e id. de inquilino. Para ello, ejecuta el siguiente comando en Cloud Shell, que muestra todos los nombres de cuentas de Azure, los identificadores de suscripción y los identificadores de inquilino:
   $ az account list –query «[].{name:name, subscriptionId:id, tenantId:tenantId}»
   [
   {
   «name»: «Visual Studio Enterprise»,
   «subscriptionId»: «b1234567-89017-6135-v94s-3v16ifk86912»,
   «tenantId»: «ba0198-d28a-41ck-a2od-d8419714a098»
   }
   ]
   $
4. Anota el valor de subscriptionId del resultado JSON devuelto. A continuación, mientras sigues en Cloud Shell, reemplaza el valor de subscriptionId por el siguiente comando:
   $ az account set –subscription=»b1234567-89017-6135-v94s-3v16ifk86912″
   El comando anterior se ejecuta sin devolver ningún resultado.

5. Crea una entidad de servicio4 para su uso con Terraform con el siguiente comando de Cloud Shell:
   $ az ad sp create-for-rbac –role=»Contributor» \
   –scopes=»/subscriptions/b1234567-89017-6135-v94s-3v16ifk86912″
   Creating a role assignment under the scope of \
   «/subscriptions/b1234567-89017-6135-v94s-3v16ifk86912»
   Retrying role assignment creation: 1/36
   {
   «appId»: «b0b88757-6ab2-3v41-1234-23ss224vd41e»,
   «displayName»: «azure-cli-2020-07-03-18-24-17»,
   «name»: «http://azure-cli-2020-07-03-18-24-17»,
   «password»: «aH2cK.asfbbashfbjafsADNknvsaklvQQ»,
   «tenant»: «ba0198-d28a-41ck-a2od-d8419714a098»
   }
   $
   Este comando devuelve los valores appId, displayName, name, password y tenant.
6. Utiliza los siguientes datos para configurar variables de entorno de Terraform en la máquina local:
   ARM_SUBSCRIPTION_ID=
   ARM_CLIENT_ID=
   ARM_CLIENT_SECRET=
   ARM_TENANT_ID=
7. En tu .bash_profile (o, si lo prefieres, envvar.sh), reemplaza las variables del código anterior de la siguiente manera:

!/bin/sh

echo «Setting environment variables for Terraform»
export ARM_SUBSCRIPTION_ID=b1234567-89017-6135-v94s-3v16ifk86912
export ARM_CLIENT_ID=b0b88757-6ab2-3v41-1234-23ss224vd41e
export ARM_CLIENT_SECRET=aH2cK.asfbbashfbjafsADNknvsaklvQQ
export ARM_TENANT_ID=ba0198-d28a-41ck-a2od-d8419714a098

Not needed for public, required for usgovernment, german, china

export ARM_ENVIRONMENT=public

8. Escribe source .bash_profile en tu terminal para leer y ejecutar comandos desde el archivo hasta el entorno del shell actual.

Ahora puedes usar Cloud Shell para interactuar con los recursos de Azure o, si lo prefieres, utiliza la CLI de Azure en tu equipo local para interactuar con Azure.

Llegados a este punto, es necesario iniciar la sesión en Azure mediante la línea de comandos, lo que te redirigirá al navegador para autenticarte. Una vez que te hayas autentificado correctamente, podrás iniciar sesión:

Ahora que has iniciado sesión correctamente y te has autenticado con Azure, puedes comprobar el directorio ~/.azure, que contiene la información de autenticación y autorización:

Uso básico y configuración de la infraestructura con Terraform
Ahora que has configurado correctamente Terraform para que se comunique con Azure, puedes crear una infraestructura básica. A medida que trabajes en estos pasos, podrás empezar a atar cabos y usar Terraform eficazmente.
Todo el código de Terraform relacionado con este capítulo está disponible en el repositorio de GitHub del libro, que puedes clonar en tu equipo local.
Ve al directorio Test, donde encontrarás un archivo llamado test.tf. En el ejemplo 2-1 se muestra el contenido de este archivo. En este ejemplo, vamos a usar un archivo de estado local para almacenar el estado actual de la infraestructura.

El código creará un grupo de recursos denominado testResourceGroup en westus.
Para ejecutar este archivo, sigue estos pasos:

Ejecuta terraform init para inicializar Terraform y descargar el proveedor de AzureRM:

Después de inicializarse correctamente, ejecuta terraform plan:

Como puedes ver en el resultado anterior, estamos intentando crear un grupo de recursos con el nombre testResourceGroup. Ahora puedes crear el recurso ejecutando terraform apply. Recuerda que debes escribir explícitamente yes para continuar:

Esto debería crear un grupo de recursos, como se muestra en la figura 2-6. Puedes verificarlo en Azure Portal.

También deberías verlo desde la CLI. Ten en cuenta que la operación del shell no es específica de la región. Puedes ver recursos en varias ubicaciones. Utiliza el siguiente comando para mostrar el grupo de recursos:

En el directorio Test, verás un archivo denominado terraform.tfstate que se creó después de aprovisionar el grupo de recursos. Este es el archivo de estado que mantiene el estado actual de la infraestructura.

Explorar la infraestructura de Azure con Terraform
Ahora que hemos creado una infraestructura básica con Terraform, vamos a continuar y crear una infraestructura adicional.
En el ejemplo 2-1, te mostramos cómo almacenar tu estado localmente. Aunque este no es un proceso recomendado, está bien para el uso básico, como en el caso del ejemplo de creación del grupo de recursos (test.tf). Es mejor utilizar almacenamiento remoto, como Azure Blob Storage, que proporciona durabilidad y seguridad para las configuraciones de infraestructura.

Los estados de Terraform son la fuente de verdad y siempre deben almacenarse en un back-end como Consul o Amazon DynamoDB Azure Storage, ya que este back-end almacenará de forma segura el estado de tu infraestructura junto con el control de versiones para facilitar la administración o la reversión en caso de desastre. Los estados no deben registrarse en el sistema de control de versiones de Git, porque Git contiene secretos.

En los subapartados siguientes, crearemos almacenamiento de blobs en nuestra cuenta de Azure para almacenar todos nuestros estados de infraestructura. También vamos a seguir el principio DRY («Don’t repeat yourself») asegurándonos de utilizar el módulo de Terraform. Vamos a explicar cómo crear redes virtuales y máquinas virtuales. Puedes encontrar los módulos en el repositorio de GitHub de este captítulo.

Creación de almacenamiento de blobs de Azure Para crear almacenamiento de blobs de Azure, necesitas utilizar el siguiente módulo: https://bit.ly/3bM6jCx.
Ahora, sigue los pasos descritos en «Uso básico y configuración de la infraestructura con Terraform» de la página 20 para implementar la cuenta de almacenamiento. Cuando ejecutes el comando terraform plan, verás una gran cantidad de información sobre el plan entre los módulos. También observarás que los módulos (por ejemplo, Storage_accounts) se han abstraído, mientras que el archivo de recursos tiene el siguiente aspecto:

Esto demuestra el poder de abstraer la infraestructura repetible detrás de los módulos. Una vez que utilices terraform apply, al cabo de unos minutos verás una cuenta de almacenamiento denominada cnabookprod y un blob llamado cloud-native-with-azure:

Anota el resultado de la operación terraform apply del paso anterior y copia el valor de la clave de acceso principal. Deberás actualizar el valor de la clave principal en el mismo .bash_profile en tu equipo local de la siguiente manera:

Ahora podemos crear una infraestructura adicional con seguridad y almacenar el estado de la infraestructura en el almacenamiento de blobs.

Creación de una red virtual e instancias de Azure. Ahora crearemos una red virtual en Azure siguiendo la configuración de Terraform que se describe en https://bit.ly/3bHE342.
También explicaremos el flujo sintáctico del módulo de red virtual, lo que te permitirá entender mejor lo simple que es el código.

Echa un vistazo más de cerca al módulo Virtual_network en el directorio /Modules/Services/Virtual_network para ver el proceso paso a paso de creación de una red virtual:

1. Crea un grupo de seguridad de red mediante azurerm_network_security_group.
2. Añade la regla de seguridad y asóciala al grupo de seguridad del paso 1.
3. Crea un plan de protección DDoS.
4. Crea una red virtual.
5. Crea cuatro subredes diferentes dentro de la red virtual.
6. Crea una interfaz de red y asóciala a una subred (privada).
7. Crea direcciones IP públicas.
8. Crea una subred pública asociándola una IP pública.

El resultado final de apply de Terraform tiene el siguiente aspecto:

Como se muestra en la figura 2-9, Terraform ha almacenado el estado de la red virtual en la cuenta de almacenamiento de blobs que creamos anteriormente.

Del mismo modo, puedes seguir los pasos anteriores e iniciar una máquina virtual dentro de una de las subredes mediante el módulo de Terraform en https://bit.ly/3bQjTEV

Cuando termines de crear los recursos en este ejemplo, asegúrate de destruirlos mediante el comando terraform destroy dentro de cada directorio de recursos en caso de que la facturación se haya habilitado para tu cuenta de Azure.

Plantillas de Terraform y ARM
Antes de pasar al siguiente apartado, echemos un vistazo a lo que Azure ofrece de forma nativa para implementar la infraestructura como código. Como se ha señalado anteriormente, Azure utiliza plantillas de ARM para implementar la infraestructura como código para cargas de trabajo basadas en Azure. Las plantillas de ARM vienen en un archivo JSON5 que define la infraestructura y la configuración del proyecto. El archivo utiliza una sintaxis declarativa similar a Terraform, que te permite definir la configuración de la infraestructura deseada. Además de la sintaxis declarativa, las plantillas de ARM también heredan la idempotencia; es decir, puedes implementar la misma plantilla varias veces y obtener los mismos tipos de recursos en el mismo estado. El administrador de recursos es responsable de convertir la plantilla de ARM en una operación de API REST. Por ejemplo, si implementas la siguiente plantilla de ARM:

el administrador de recursos convertirá el JSON en una operación de API REST, que se enviará al proveedor de recursos Microsoft.Storage de la siguiente manera:

Packer
Al principio de este capítulo, presentamos el término infraestructura inmutable, que representa el cambio en el aprovisionamiento y la implementación de aplicaciones nativas en el cloud. Una de las herramientas más utilizadas para crear una imagen de máquina preconfigurada6 es Packer. Las imágenes de máquina son principalmente recursos informáticos que tienen todas las configuraciones, metadatos, artefactos y archivos relacionados preinstalados/configurados. Packer es una herramienta de código abierto de HashiCorp que se utiliza para crear imágenes de máquina a partir de una configuración definida. Automatiza todo el proceso de creación de imágenes de máquina, lo que aumenta la velocidad de implementación de la infraestructura. Al igual que Terraform se utiliza para crear infraestructura, Packer ayuda a crear imágenes de máquina al preparar todo el software esencial, binarios, etc., en la imagen de máquina.
Además, dado que todo el software de la imagen de máquina se instala y configura antes de crear la imagen, Packer ayuda a mejorar la estabilidad general de la infraestructura. También es compatible con diferentes proveedores de cloud, que crean imágenes de máquina idénticas en múltiples plataformas. Vamos a profundizar un poco más en cómo se puede usar Packer para crear imágenes en Azure.

Instalación de Packer
Para empezar a usar Packer, descarga el binario de Packer correspondiente a tu máquina local7. Descomprime el binario y muévelo a /usr/local/bin. Esto debería configurar Packer en tu equipo; puedes comprobarlo ejecutando packer –help en tu shell:

Creación de una imagen de Linux en Azure
Packer utiliza un archivo de configuración que define la imagen de máquina. El archivo de configuración se denomina plantilla de Packer y está escrito en JSON. La plantilla incluye constructores y aprovisionadores. Los constructores crean una imagen de máquina para una plataforma leyendo las claves de configuración y autenticación. Los aprovisionadores son responsables de instalar y configurar el software sobre la imagen de máquina antes de que la imagen se convierta en inmutable. En la figura 2-10 se ilustra el proceso de creación de imágenes de Packer.

Puedes encontrar el código relacionado con la creación de imágenes de máquina de Packer en https://bit.ly/3GRgswf. Para ejecutar este código, primero debes actualizarlo con los detalles de autenticación del archivo example.json. Puedes utilizar los detalles de autenticación de tu cuenta de Azure del archivo bash_profile. El resultado de la ejecución debe parecerse al siguiente:

En la figura 2-11 se muestra la imagen que hemos creado en Azure Portal. Puedes comprobar que la imagen tenga el servidor web Nginx y el equilibrador de carga y el servidor proxy HAProxy preconfigurados iniciando máquinas virtuales que usen la imagen.

Ahora que ya conoces el papel de Packer como herramienta de creación de imágenes, echemos un vistazo a Ansible, un magnífico complemento para la administración de entornos nativos en el cloud complejos.

Ansible
Ansible es una sencilla herramienta de administración de la configuración que te permite aprovisionar, configurar y administrar servidores. Ansible facilita la administración de servidores que no tienen ningún agente preinstalado en ejecución, aunque también puedes configurarlo como un sistema basado en agentes. Además, puedes utilizar Ansible como herramienta una vez que hayas creado la infraestructura mediante Terraform y las imágenes de máquina preconfiguradas con Packer.
Los conceptos básicos de Ansible son los siguientes:

Nodo de control
Normalmente, este es el nodo desde el que se ejecuta el cuaderno de estrategias de Ansible. Podría ser cualquier nodo donde esté instalado Ansible. Para ejecutar un cuaderno de estrategias de Ansible, puedes ejecutar el siguiente comando en tu terminal:

ansible-playbook -vi path_to_host_inventory_file playbook.yaml

Nodos administrados
Los nodos o los hosts que deseas administrar se denominan «nodos administrados». Estos nodos suelen ser servidores remotos. Lo mejor de Ansible es que no es necesario instalar un agente en las instancias remotas para administrarlas. Todo lo que necesitas es un daemon de Secure Shell (SSH) que esté a la escucha y Python instalado en los hosts. Ansible crea una conexión SSH para ejecutar los cuadernos de estrategias.
Archivo de inventario
El archivo de inventario contiene la lista de todos los hosts que administra Ansible. El inventario suele contener direcciones IP, nombres de host, el nombre de usuario SSH y las claves para conectarse a la máquina remota. A continuación, se muestra un ejemplo del inventario:

Como Ansible no requiere mucha sobrecarga y está escrito en YAML, es una excelente herramienta para usarla después de la configuración. En este libro, en ocasiones, utilizaremos Ansible para aprovisionar partes de los servicios.

Antes de terminar este capítulo, echemos un vistazo rápido a Azure DevOps, que nos ayuda a combinar todas estas herramientas de forma automatizada para crear una canalización CI/CD.

Azure DevOps e infraestructura como código
Azure ofrece Azure DevOps, que proporciona una completa cadena de herramientas de DevOps para el desarrollo y la implementación de aplicaciones, y es principalmente un servicio alojado para implementar canalizaciones de CI/CD. También puedes usar Terraform, Ansible y Packer juntos y crear canalizaciones de varias fases para tus proyectos. Azure DevOps tiene muchos servicios, incluido Azure Pipeline, que se utiliza principalmente para crear, probar e implementar las canalizaciones de CI/CD. No vamos a explicar Azure DevOps, ya que queda fuera del alcance de este libro, pero puedes obtener más información sobre cómo configurar Azure DevOps en la documentación oficial.

Resumen
En este capítulo, presentamos los pasos para la creación de un entorno nativo del cloud moderno con Azure. Creaste una cuenta de Azure, que te servirá en los próximos capítulos a medida que conozcas mejor las tecnologías nativas del cloud. También presentamos Terraform, Packer y Ansible: tres útiles orquestadores nativos del cloud que te ayudarán a implementar y administrar tu infraestructura en el cloud. Terraform es una herramienta independiente del cloud para desarrollar infraestructura como código desde cero; Packer se utiliza para crear imágenes de máquina para el desarrollo de artefactos inmutables y Ansible es una herramienta de administración de la configuración.
Con este conocimiento básico de Azure y las tecnologías relacionadas, podemos pasar al siguiente capítulo, donde hablaremos de contenedores, del registro de contenedores y del uso de contenedores en tu aplicación.