Résoudre les problèmes courants lors de l’utilisation de Terraform sur Azure

Cet article répertorie les problèmes courants et les solutions possibles lors de l’utilisation de Terraform sur Azure.

Si vous rencontrez un problème spécifique à Terraform, utilisez l’un des canaux de support de la communauté de HashiCorp.

• Impossible de répertorier l’état d’inscription du fournisseur
• Erreurs VPN

Canaux de support spécifiques à HashiCorp Terraform

• Questions, cas d’usage et modèles utiles : section Terraform du portail de la communauté HashiCorp
• Questions, cas d’usage et modèles utiles : section Terraform du portail de la communauté HashiCorp

Impossible de répertorier l’état d’inscription du fournisseur

Message d’erreur :

Erreur : Impossible de répertorier l’état d’inscription du fournisseur. Cette erreur peut se produire en raison d'informations d'identification non valides ou parce que le principal de service n'est pas autorisé à utiliser l'API Resource Manager. erreur Azure : ressources. ProvidersClient#List : Échec de réponse à la demande : StatusCode=403 -- Erreur d’origine : autorest/azure : Service a retourné une erreur. Status=403 Code="AuthorizationFailed" Message="Le client '00000000-0000-0000-0000-000000000000' avec l'ID d'objet '00000000-0000-0000-0000-000000000000' n'est pas autorisé à effectuer l'action 'Microsoft.Resources/subscriptions/providers/read' sur l'étendue '/subscriptions/00000000-0000-0000-0000-000000000000' ou l'étendue n'est pas valide." Si l’accès a été accordé récemment, actualisez vos informations d’identification ».

Arrière-plan : Si vous exécutez des commandes Terraform à partir de l’Cloud Shell et définissez certaines variables d’environnement Terraform/Azure, des conflits peuvent s’afficher. Le tableau suivant répertorie les variables d’environnement et les valeurs Azure qu’elles représentent :

Cause : À l’heure où nous écrivons ces lignes, le script Terraform qui s’exécute dans Cloud Shell remplace les variables d’environnement ARM_TENANT_ID et ARM_SUBSCRIPTION_ID en utilisant les valeurs de l’abonnement Azure actuel. Par conséquent, si le principal de service auquel les variables d'environnement référence ne disposent pas des droits relatifs à l'abonnement Azure actuel, les opérations Terraform échouent.

Erreur lors de l’acquisition du verrou d’état

Message d’erreur :

Erreur : Erreur lors de l’acquisition du verrou d’état ; Message d’erreur : 2 erreurs se sont produites :
* le blob d’état est déjà verrouillé
* Les métadonnées d’objet blob « terraformlockid » étaient vides
Terraform pose un verrou sur l’état pour empêcher que plusieurs utilisateurs n’écrivent dans l’état en même temps. Résolvez le problème ci-dessus et réessayez. Pour la plupart des commandes, vous pouvez désactiver le verrouillage avec l’indicateur « -lock=false », mais cela n’est pas recommandé.

Arrière-plan : Si vous exécutez des commandes Terraform sur un fichier d’état Terraform et que cette erreur est le seul message qui s’affiche, les causes suivantes peuvent s’appliquer. Cette erreur s’applique aux fichiers d’état local et distant.

Cause : Il existe deux causes potentielles pour cette erreur. La première cause est qu’une commande Terraform est déjà en cours d’exécution sur le fichier d’état et qu’elle a placé un verrou sur ce fichier afin que rien ne casse. La deuxième cause potentielle est qu’une interruption de connexion s’est produite entre le fichier d’état et l’interface CLI lorsque les commandes étaient en cours d’exécution. Cette interruption se produit généralement lorsque vous utilisez des fichiers d’état distants.

Résolution : Tout d’abord, assurez-vous que vous n’exécutez pas déjà de commandes sur le fichier d’état. Si vous utilisez un fichier d’état local, vérifiez si vous avez des terminaux exécutant des commandes. Vous pouvez également vérifier vos pipelines de déploiement pour déterminer si un élément en cours d’exécution peut utiliser le fichier d’état. Si cette condition ne résout pas le problème, il est possible que la deuxième cause déclenche l’erreur. Pour un fichier d’état distant stocké dans le conteneur d’un compte de stockage Azure, vous pouvez localiser le fichier et cliquer sur le bouton Rompre le bail.

Si vous utilisez d’autres back-ends pour stocker votre fichier d’état, pour obtenir des recommandations, consultez la documentation HashiCorp.

Erreurs VPN

Pour plus d’informations sur la résolution des erreurs VPN, consultez l’article résoudre les problèmes d’une connexion VPN hybride.

Terraform prévoit supprimer et recréer un compte de stockage

Terraform peut planifier la suppression et la recréation d’un compte de stockage Azure après Azure modifie le compte de stockage en dehors de Terraform. Ce comportement peut se produire lors d’une conversion prise en charge du type de redondance d’un compte Stockage Azure, où account_replication_type passe de l’ensemble non zonal (LRS, GRS, RA-GRS) à l’ensemble zonal (ZRS, GZRS, RA-GZRS).

Avant d’appliquer le plan, passez en revue les modifications proposées et confirmez pourquoi Terraform considère le remplacement du compte de stockage nécessaire. La recréation d’un compte de stockage peut entraîner un temps d’arrêt de l’application ou une perte de données.

Pour réduire ce risque :

• Désactivez l’approbation automatique pour les déploiements qui gèrent les comptes de stockage et passez en revue tous les terraform plan.
• Configurez prevent_destroy = true dans le bloc lifecycle de la ressource de compte de stockage.
• Avant de commencer la conversion, ajoutez account_replication_type temporairement à ignore_changes.
• Après la conversion, exécutez terraform apply -refresh-only pour mettre à jour l’état Terraform, puis mettez à jour votre configuration Terraform pour qu’elle corresponde au compte de stockage déployé.
• Supprimez ignore_changes uniquement après l’exécution terraform plan et confirmez qu’elle ne signale aucune modification inattendue.

Pour obtenir un guide détaillé sur la conversion, consultez Éviter la dérive de Terraform pour les ressources Azure avec gestion d’état.