Compartir a través de

Infraestructura como código

  • Artículo

La infraestructura como código (IaC) es una práctica clave de DevOps que conlleva 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 publicar cambios más rápidos y con mayor confianza. Entre las ventajas de IaC se incluyen las siguientes:

  • Mayor confianza en las implementaciones
  • Posibilidad de administrar varios entornos
  • Conocimientos mejorados del estado de la infraestructura

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

Tooling

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

  • La infraestructura como código imperativa supone escribir scripts en lenguajes como Bash o PowerShell. El usuario determina explícitamente los comandos que se van a ejecutar para producir el resultado deseado. Cuando se usan implementaciones imperativas, depende del usuario administrar la secuencia de dependencias, el control de errores y las actualizaciones de recursos.
  • La infraestructura como código declarativa supone escribir una definición que indique cómo quiere que sea el entorno. En esta definición, se especifica un resultado deseado en lugar del modo en que quiere que se realice. Las herramientas describen cómo hacer que el resultado suceda inspeccionando el estado actual, comparándolo con el estado de destino y, luego, aplicando las diferencias.

Plantillas ARM

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

Bicep

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 va a 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 un público que no son desarrolladores porque usan una sintaxis concisa.

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'
  }
}

Terraform

Revise la información sobre Terraform.

Azure CLI

Revise la información sobre la CLI de Azure.

Módulos de infraestructura como 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 un conjunto de recursos diseñados para 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 centre en una tarea específica y de que todos los módulos sean reutilizables para varias implementaciones y cargas de trabajo.

Módulos de Bicep

Bicep le permite crear y llamar a 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 los administre un módulo.

Publicación de módulos de Bicep

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

  • Registro público: el registro de módulos públicos 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 información sobre cómo publicar módulos en un registro en una canalización de CI/CD, consulte Bicep y Acciones de 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 las plantillas están pensadas para ser plantillas completas, pero Bicep le permite usarlas para implementar módulos.
  • Sistema de control de versiones: puede cargar módulos directamente con herramientas de control de versiones, como GitHub o Azure DevOps.

Módulos de Terraform

Terraform le 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 archivos .tf del directorio de trabajo principal. Cada módulo puede llamar a otros módulos, lo que le permite incluir los módulos secundarios en el archivo de configuración principal. También se puede llamar a los 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 que llama.
  • Valores de salida para devolver resultados a un módulo de llamada.
  • Recursos para definir uno o varios objetos de infraestructura para que los administre un módulo.

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 fácilmente 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 con herramientas de control de versiones, como GitHub. Para 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 la optimización de la implementación, reduce el trabajo de configuración y automatiza las implementaciones de todo el entorno.

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

    • Si adopta un enfoque imperativo, indique explícitamente los comandos que se ejecutarán para producir el resultado deseado.

    • Si adopta un enfoque declarativo, especifique el resultado deseado en lugar del modo en que quiere conseguirlo.

  • 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:

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

    • Las herramientas no nativas, como Terraform, le 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 entre las no nativas. Si su organización es multinube o ya usa Terraform y está bien familiarizado con él, 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 IaC para recursos que se implementan normalmente juntos. Puede asegurarse de que cada módulo se centra en una tarea específica y de que los módulos son reutilizables para varias implementaciones y cargas de trabajo.

  • Considere la posibilidad de adoptar una estrategia de publicación para los módulos 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 se establece para garantizar la calidad de las implementaciones y del entorno de Azure.

Recomendaciones de diseño

  • Adopte un enfoque de IaC para implementar, administrar, gobernar y admitir implementaciones de zonas de aterrizaje de Azure.

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

    • Solo quiere usar herramientas nativas de Azure. Es posible que su organización tenga experiencia previa con la implementación de plantillas de ARM o de 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 actualmente usa Terraform para implementar 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 las zonas de aterrizaje de Azure ya publicadas en registros públicos. Para más información, consulte el módulo de Terraform para las zonas de aterrizaje de Azure.

    • Quiere usar módulos que mantienen, actualizan y admiten 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:

    • Quiere crear sus propios módulos en función de los requisitos de la organización.

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

  • Use una canalización de CI/CD para implementar artefactos de IaC y garantizar la calidad de la implementación y los entornos de Azure.