Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Terraform permet la définition, l’aperçu et le déploiement d’une infrastructure cloud. À l’aide de Terraform, vous créez des fichiers de configuration à l’aide de la syntaxe HCL. La syntaxe HCL vous permet de spécifier un fournisseur de services cloud, tel qu’Azure, et les éléments qui composent votre infrastructure cloud. Après avoir créé vos fichiers de configuration, vous créez un plan d’exécution qui vous permet d’afficher un aperçu de vos modifications d’infrastructure avant leur déploiement. Une fois que vous avez vérifié les modifications, vous appliquez le plan d’exécution pour déployer l’infrastructure.
Le fournisseur AzAPI Terraform inclut une validation de pré-exécution intégrée qui valide votre configuration de ressources Azure conformément au schéma de l’API ARM pendant terraform plan, avant la création ou la modification des ressources dans Azure. La vérification préalable intercepte les erreurs de configuration dès le début, telles que les préfixes d'adresses non valides, les combinaisons de propriétés non prises en charge ou les violations du quota, sans engendrer les coûts d’un déploiement échoué.
La validation préliminaire est l'un des principaux différenciateurs d'AzAPI et fonctionne en mode natif avec l'architecture directe vers ARM-API du fournisseur. Vous pouvez également exécuter un préflight à partir de l’extension Microsoft Terraform VS Code sans définir directement le drapeau du fournisseur.
Prerequisites
- Abonnement Azure : si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
Configurez Terraform : Si ce n’est déjà fait, configurez Terraform à l’aide de l’une des options suivantes :
Lorsque vous vous connectez au portail Azure avec un compte Microsoft, l’abonnement Azure par défaut pour ce compte est utilisé.
Terraform s’authentifie automatiquement à l’aide d’informations de l’abonnement Azure par défaut.
Exécutez az account show pour vérifier le compte Microsoft actuel et l’abonnement Azure.
az account show
Toutes les modifications que vous apportez via Terraform se trouvent sur l’abonnement Azure affiché. Si c’est ce que vous voulez, ignorez le reste de cet article.
Activer la validation préliminaire
Défini enable_preflight = true dans le provider "azapi" bloc :
provider "azapi" {
enable_preflight = true
}
La pré-vérification est désactivée par défaut pour préserver la compatibilité rétroactive. Activez-la dans les environnements où vous souhaitez une validation anticipée, comme les pipelines CI et les vérifications de pull requests.
Exemple : détecter un préfixe d'adresse non valide pendant la phase de planification
La configuration suivante crée un réseau virtuel avec un bloc CIDR (Classless Inter-Domain Routing) non valide. Une fois la prévérification activée, l’erreur s’affiche pendant terraform plan plutôt que pendant 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
]
}
}
}
}
Lorsque vous exécutez terraform plan avec cette configuration, la vérification préalable retourne une erreur similaire à :
Error: preflight validation failed for resource "azapi_resource.vnet":
The value '10.0.0.0/160' is not a valid CIDR block.
La correction du préfixe d’adresse à une valeur valide (par exemple, 10.0.0.0/16) efface l’erreur.
Ce que la vérification avant vol valide
Le processus de prévalidation envoie le corps de la ressource au point de terminaison de prévalidation de l’API ARM, qui valide :
- Valeurs de propriété par rapport au schéma de ressource ARM (par exemple, des plages CIDR valides (Inter-Domain routage sans classe), des noms de référence SKU autorisés, des champs obligatoires).
- Contraintes de quota et de capacité au niveau de l’abonnement pour les types de ressources pris en charge.
- Conformité des affectations d'Azure Policy qui s’exécutent en mode pré-exécution.
Le contrôle préalable ne valide pas :
- Dépendances entre ressources ou séquencement.
- Ressources qui n’ont pas de prise en charge du point de terminaison de préversion ARM (le fournisseur ignore silencieusement la validation pour ces types de ressources).
- Échecs d’authentification ou d’autorisation (Gestion des identités et des accès (IAM) : ces échecs s’affichent pendant
terraform apply.
Utiliser le préversion dans les pipelines CI
L’ajout d’un préflight à un pipeline CI fournit une étape de validation rapide et non-destructive qui détecte les erreurs de configuration avant la fusion du code. Activez enable_preflight = true dans le bloc fournisseur de votre configuration Terraform, puis exécutez terraform plan:
provider "azapi" {
enable_preflight = true
}
Étant donné que les tests préliminaires s'exécutent pendant terraform plan sans effets secondaires, il est sans risque de l'exécuter dans des workflows de pull request sur des abonnements Azure en direct.
Désactiver le bruit de sortie avec ignore_no_op_changes
Si vous exécutez des plans à plusieurs reprises, AzAPI peut détecter des différences mineures no-op entre la configuration et l’état ARM (par exemple, les valeurs par défaut normalisées retournées par l’API). Pour supprimer ces différences au moment du plan et vous concentrer sur les modifications réelles, définissez ignore_no_op_changes = true dans le bloc fournisseur :
provider "azapi" {
enable_preflight = true
ignore_no_op_changes = true
}