Habilitar la validación previa en el proveedor de Terraform de AzAPI

Terraform habilita la definición, la versión preliminar y la implementación de la infraestructura en la nube. Con Terraform, se crean archivos de configuración mediante la sintaxis de HCL. La sintaxis de HCL permite especificar el proveedor de la nube, como Azure, y los elementos que componen la infraestructura de la nube. Después de crear los archivos de configuración, se crea un plan de ejecución que permite obtener una vista previa de los cambios de infraestructura antes de implementarlos. Una vez que compruebe los cambios, aplique el plan de ejecución para implementar la infraestructura.

El proveedor de Terraform de AzAPI incluye una validación previa integrada que verifica la configuración de los recursos de Azure contra el esquema API de ARM durante terraform plan, antes de que se creen o modifiquen los recursos en Azure. La comprobación previa detecta los errores de configuración al principio, como prefijos de dirección no válidos, combinaciones de propiedades no admitidas o infracciones de cuota, sin incurrir en el costo de una implementación con errores.

La validación previa es uno de los diferenciadores clave de AzAPI y funciona de forma nativa con la arquitectura directa a la ARM-API del proveedor. También puede ejecutar la prueba previa desde la extensión de VS Code de Microsoft Terraform sin establecer la marca de proveedor directamente.

Prerequisites

  • Suscripción de Azure: Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Al iniciar sesión en Azure Portal con una cuenta Microsoft, se usa la suscripción de Azure predeterminada para esa cuenta.

Terraform se autentica automáticamente mediante la información de la suscripción de Azure predeterminada.

Ejecute az account show para comprobar la cuenta Microsoft actual y la suscripción de Azure.

az account show

Los cambios que realice a través de Terraform se encuentran en la suscripción de Azure mostrada. Si es lo que desea, omita el resto de este artículo.

Habilitar la validación previa

Establezca enable_preflight = true en el bloque provider "azapi".

provider "azapi" {
  enable_preflight = true
}

Preflight está deshabilitado por defecto para conservar la compatibilidad con versiones anteriores. Habilite en entornos en los que desee una validación temprana, como canalizaciones de CI y comprobaciones de solicitudes de incorporación de cambios.

Ejemplo: Captura un prefijo de dirección no válido durante el tiempo de planificación

La siguiente configuración crea una red virtual con un bloque CIDR (enrutamiento entre dominios sin clases) no válido. Con la comprobación previa habilitada, el error aparece durante terraform plan en lugar de durante terraform apply:

terraform {
  required_providers {
    azapi = {
      source  = "Azure/azapi"
      version = "~> 2.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

provider "azapi" {
  enable_preflight = true
}

resource "azurerm_resource_group" "example" {
  name     = "rg-preflight-demo"
  location = "eastus"
}

resource "azapi_resource" "vnet" {
  type      = "Microsoft.Network/virtualNetworks@2024-01-01"
  parent_id = azurerm_resource_group.example.id
  name      = "vnet-example"
  location  = "eastus"

  body = {
    properties = {
      addressSpace = {
        addressPrefixes = [
          "10.0.0.0/160"  # Invalid prefix length — preflight catches this at plan time
        ]
      }
    }
  }
}

Cuando se ejecuta terraform plan con esta configuración, preflight devuelve un error similar al siguiente:

Error: preflight validation failed for resource "azapi_resource.vnet":
  The value '10.0.0.0/160' is not a valid CIDR block.

Al corregir el prefijo de dirección a un valor válido (por ejemplo, 10.0.0.0/16), se borra el error.

Qué verifica el proceso de preflight

Preflight envía el cuerpo del recurso al punto de conexión de preflight de la API de ARM, que valida:

  • Valores de propiedad contra el esquema de recursos de ARM (por ejemplo, rangos válidos de CIDR (enrutamiento interdominios sin clases), nombres permitidos de SKU, campos obligatorios).
  • Restricciones de cuota y de capacidad a nivel de suscripción para los tipos de recursos admitidos.
  • Cumplimiento de directivas para las asignaciones de Azure Policy que se ejecutan en modo preflight.

La preflight no valida:

  • Dependencias entre recursos o secuenciación.
  • Recursos que no tienen compatibilidad con el punto de conexión previo de ARM (el proveedor omite silenciosamente la validación de esos tipos de recursos).
  • Errores de autenticación o autorización (Identity and Access Management (IAM)): estos errores se muestran durante terraform apply.

Uso de la versión preliminar en canalizaciones de CI

Añadir pruebas previas a un pipeline de CI proporciona un paso de validación rápido y no destructivo que detecta errores de configuración antes de fusionar el código. Habilite enable_preflight = true en el bloque de proveedor de la configuración de Terraform y, a continuación, ejecute terraform plan:

provider "azapi" {
  enable_preflight = true
}

Dado que preflight se ejecuta durante terraform plan sin efectos secundarios, es seguro ejecutarlo en flujos de trabajo de pull request contra suscripciones de Azure activas.

Deshabilitar el ruido de salida con ignore_no_op_changes

Si ejecuta planes repetidamente, AzAPI podría detectar pequeñas diferencias sin operación entre la configuración y el estado de ARM (por ejemplo, valores predeterminados normalizados devueltos por la API). Para suprimir estas diferencias en tiempo de plan y centrarse en los cambios reales, establezca ignore_no_op_changes = true en el bloque de proveedor:

provider "azapi" {
  enable_preflight      = true
  ignore_no_op_changes  = true
}

Pasos siguientes