Infraestructura como código

La infraestructura como código (IaC) es una práctica clave de DevOps que implica la administración de la infraestructura, como redes, servicios de proceso, bases de datos, almacenamientos y topología de conexión, en un modelo descriptivo. IaC permite a los equipos desarrollar y liberar cambios más rápidos y con mayor confianza. Entre las ventajas de IaC se incluyen:

• Mayor confianza en las implementaciones
• Capacidad de administrar varios entornos
• Comprensión mejorada del estado de la infraestructura

Para obtener más información sobre las ventajas de usar la infraestructura como código, consulte Infraestructura repetible.

Fabricación de herramientas

Hay dos enfoques que puede adoptar al implementar la infraestructura como código.

• La infraestructura imperativa como código implica escribir scripts en lenguajes como Bash o PowerShell. Indicas explícitamente los comandos que se ejecutan para generar un resultado deseado. Cuando se usan implementaciones imperativas, es necesario administrar la secuencia de dependencias, el control de errores y las actualizaciones de recursos.
• La infraestructura declarativa como código implica escribir una definición que defina cómo desea que su entorno tenga un aspecto. En esta definición, se especifica un resultado deseado en lugar de cómo desea que se realice. Las herramientas determinan cómo lograr el resultado inspeccionando tu estado actual, comparándolo con el estado deseado y aplicando las diferencias.

Plantillas ARM

Revise la información sobre las plantillas de Azure Resource Manager (plantillas de ARM).

• ¿Qué son las plantillas de ARM?

• Plantillas de ARM: información general sobre la infraestructura como código

Bíceps

Bicep es un lenguaje específico de dominio (DSL) que usa una sintaxis declarativa para implementar recursos de Azure. En los archivos de Bicep, defina la infraestructura que pretende implementar y sus propiedades. En comparación con las plantillas de ARM, los archivos de Bicep son más fáciles de leer y escribir para una audiencia que no es de desarrollador porque usan una sintaxis concisa.

Este código de Bicep de ejemplo implementa una cuenta de Azure Storage en la región del grupo de recursos. Aplica redundancia de tipo Standard_LRS y el tipo de almacenamiento StorageV2. El nivel de acceso se establece en "Frecuente" para el acceso frecuente a los datos.

param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Terraformación

Revise la información sobre Terraform.

• Introducción a Terraform en Azure

• Terraform: introducción a la infraestructura como código

CLI de Azure

Revise la información sobre la CLI de Azure.

• Interfaz de la línea de comandos (CLI) de Azure

• CLI de Azure: Introducción a la infraestructura como código

Infraestructura como módulos de código

Uno de los objetivos de usar código para implementar la infraestructura es evitar duplicar el trabajo o crear varias plantillas con el mismo propósito o similar. Los módulos de infraestructura deben ser reutilizables y flexibles y deben tener un propósito claro.

Los módulos son archivos independientes, que normalmente contienen conjuntos de recursos destinados a implementarse juntos. Los módulos permiten dividir plantillas complejas en conjuntos de código más pequeños y fáciles de administrar. Puede asegurarse de que cada módulo se centra en una tarea específica y que todos los módulos son reutilizables para varias implementaciones y cargas de trabajo.

Módulos de Bicep

Bicep permite crear e invocar módulos. Una vez creados los módulos, se pueden consumir desde cualquier otra plantilla de Bicep. Un módulo de Bicep de alta calidad debe definir varios recursos relacionados. Por ejemplo, al definir una función de Azure, normalmente se implementa una aplicación determinada, un plan de hospedaje para esa aplicación y una cuenta de almacenamiento para los metadatos de esa aplicación. Estos componentes se definen por separado, pero forman una agrupación lógica de recursos, por lo que debe considerar la posibilidad de definirlos juntos como módulo.

Los módulos de Bicep suelen usar:

• Parámetros para aceptar valores de un módulo de llamada.
• Valores de salida para devolver resultados a un módulo de llamada.
• Recursos para definir uno o varios objetos de infraestructura para que un módulo lo administre.

Publicación de módulos de Bicep

Existen varias opciones para publicar y compartir módulos de Bicep.

• Registro público: El registro de módulo público se hospeda en un registro de contenedor de Microsoft (MCR). Su código fuente y los módulos que contiene se almacenan en GitHub.
• Registro privado: Puede usar Azure Container Registry para publicar módulos en un registro privado. Para obtener información sobre cómo publicar módulos en un registro en una canalización de CI/CD, consulte Acciones de Bicep y GitHub, o si lo prefiere, Bicep y Azure Pipelines.
• Especificación de plantilla: Puede usar especificaciones de plantilla para publicar módulos de Bicep. Las especificaciones de plantilla están diseñadas para ser plantillas completas, pero Bicep permite usar especificaciones de plantilla para implementar módulos.
• Sistema de control de versiones: Puede cargar módulos directamente desde herramientas de control de versiones como GitHub o Azure DevOps.

Módulos de Terraform

Terraform permite crear y llamar a módulos. Cada configuración de Terraform tiene al menos un módulo, conocido como módulo raíz, que consta de recursos definidos en .tf archivos del directorio de trabajo principal. Cada módulo puede llamar a otros módulos, lo que le permite incluir módulos secundarios en el archivo de configuración principal. También se puede llamar a módulos varias veces dentro de la misma configuración o desde configuraciones diferentes.

Los módulos se definen con todos los mismos conceptos del lenguaje de configuración. Normalmente usan:

• Variables de entrada para aceptar valores de un módulo de llamada.
• Valores de salida para devolver resultados a un módulo de llamada.
• Recursos para definir uno o varios objetos de infraestructura para que un módulo lo administre.

Publicación de módulos de Terraform

Tiene varias opciones para publicar y compartir módulos de Terraform:

• Registro público: HashiCorp tiene su propio Registro de módulos de Terraform que permite a los usuarios generar módulos de Terraform que se pueden compartir. Actualmente hay varios módulos de Azure publicados en el Registro de módulos de Terraform.
• Registro privado: Puede publicar sin problemas módulos de Terraform en un repositorio privado, como Terraform Cloud Private Registry o Azure Container Registry.
• Sistema de control de versiones: Puede cargar módulos privados directamente desde herramientas de control de versiones como GitHub. Para obtener información sobre los orígenes admitidos, consulte Orígenes de módulos de Terraform.

Consideraciones de diseño

• Considere la posibilidad de usar IaC al implementar recursos de zona de aterrizaje en Azure. IaC realiza plenamente la optimización de la implementación, reduce el esfuerzo de configuración y automatiza la implementación de todo el entorno.

• Determine si debe adoptar un enfoque imperativo o declarativo de IaC.

  • Si se adopta un enfoque imperativo, indica explícitamente los comandos que deben ejecutarse para producir el resultado deseado.

  • Si adopta un enfoque declarativo, especifique el resultado deseado en lugar de cómo lo desea.

• Considere los ámbitos de implementación. Tenga una buena comprensión de los niveles de administración y la jerarquía de Azure. Cada implementación de IaC debe conocer el ámbito en el que se implementan los recursos de Azure.

• Determine si debe usar una herramienta IaC nativa o no nativa de Azure. Algunos puntos que se deben tener en cuenta:

  • Microsoft admite completamente las herramientas nativas de Azure, como la CLI de Azure, las plantillas de ARM y Bicep, lo que permite que sus nuevas características se integren más rápido.

  • Las herramientas no nativas como Terraform permiten administrar la infraestructura como código en varios proveedores de nube, como AWS o GCP. Sin embargo, las nuevas características de Azure pueden tardar algún tiempo en incluirse en elementos no nativos. Si su organización es multinube o su organización ya usa y está bien familiarizado en Terraform, considere la posibilidad de usar Terraform para implementar zonas de aterrizaje de Azure.

• Dado que los módulos permiten dividir plantillas complejas en conjuntos de código más pequeños, considere la posibilidad de usar módulos de IaC para los recursos que se implementan conjuntamente. Puede asegurarse de que cada módulo se centra en una tarea específica y es reutilizable para varias implementaciones y cargas de trabajo.

• Considere la posibilidad de adoptar una estrategia de publicación para los módulos de IaC eligiendo entre registros públicos, registros privados o un sistema de control de versiones, como un repositorio de Git.

• Considere la posibilidad de usar una canalización de CI/CD para implementaciones de IaC. Una canalización aplica el proceso reutilizable que estableciste para garantizar la calidad de tus implementaciones y del entorno de Azure.

Recomendaciones de diseño

• Adopte un enfoque de IaC para implementar, administrar, gobernar y dar soporte a las zonas de aterrizaje de Azure.

• Use las herramientas nativas de Azure para IaC en los escenarios siguientes:

  • Desea utilizar únicamente herramientas nativas de Azure. Es posible que su organización tenga una experiencia de implementación anterior de plantillas de ARM o Bicep.

  • Su organización quiere tener compatibilidad inmediata con todas las versiones preliminares y de disponibilidad general de los servicios de Azure.

• Use herramientas no nativas para IaC en los escenarios siguientes:

  • Su organización usa actualmente Terraform para implementar la infraestructura en otras nubes, como AWS o GCP.

  • Su organización no necesita tener compatibilidad inmediata con todas las versiones preliminares y de disponibilidad general de los servicios de Azure.

• Use módulos IaC reutilizables para evitar el trabajo repetitivo. Puede compartir módulos en toda la organización para implementar varios proyectos o cargas de trabajo y administrar código menos complejo.

• Publique y use módulos iaC desde registros públicos en los escenarios siguientes:

  • Quiere usar módulos para la zona de aterrizaje de Azure ya publicada en registros públicos. Para más información, consulte el módulo de Terraform para zonas de aterrizaje de Azure.

  • Quiere usar módulos que son mantenidos, actualizados y admitidos por Microsoft, Terraform u otros proveedores de módulos.

    • Asegúrese de comprobar la instrucción de soporte técnico de cualquier proveedor de módulos que evalúe.

• Publique y use módulos iaC desde registros privados o sistemas de control de versiones en los escenarios siguientes:

  • Quieres crear tus propios módulos basados en los requisitos de tu organización.

  • Quiere tener control total de todas las características y mantener, actualizar y publicar nuevas versiones de módulos.

• Utiliza un flujo de trabajo de CI/CD para implementar artefactos de IaC y garantizar la calidad en la implementación y en los entornos de Azure.