Quand Terraform Apply s'exécute réellement : ce qui se passe après avoir approuvé le plan

Vous avez examiné la sortie du plan. Vous avez confirmé que Terraform va créer deux instances EC2, ne pas supprimer la base de données existante et attacher le bon groupe de sécurité. Maintenant, vous tapez terraform apply et appuyez sur Entrée. Le terminal défile avec des messages comme aws_instance.app_server: Creating... et vous attendez.

C'est le moment où l'infrastructure en tant que code cesse d'être un fichier de configuration pour devenir une infrastructure réelle. Les serveurs démarrent. Les réseaux sont configurés. Les enregistrements DNS sont créés. Mais que se passe-t-il exactement pendant terraform apply, et comment vous assurer que cette étape ne cause pas de problèmes ?

Pourquoi utiliser un fichier de plan sauvegardé

La façon la plus sûre d'exécuter terraform apply est de lui fournir un fichier de plan que vous avez généré précédemment. Après avoir exécuté terraform plan -out=plan.tfplan, vous pouvez exécuter terraform apply plan.tfplan. Cela garantit que Terraform applique exactement ce que vous avez examiné, ni plus, ni moins.

Voici la séquence de commandes exacte pour générer et appliquer un fichier de plan sauvegardé :

terraform plan -out=plan.tfplan
terraform apply plan.tfplan

Le risque d'exécuter terraform apply sans fichier de plan est subtil mais réel. Entre le moment où vous exécutez terraform plan et terraform apply, un autre membre de votre équipe pourrait fusionner une modification sur la même configuration. Ou vous pourriez modifier un fichier de variables sans vous en rendre compte. Lorsque vous exécutez terraform apply sans plan sauvegardé, Terraform réexécute le plan en utilisant la configuration existante à ce moment-là. Le résultat peut différer de ce que vous avez examiné il y a dix minutes.

Pour les environnements de production, utilisez toujours un fichier de plan sauvegardé. Cela crée une piste d'audit : vous pouvez pointer vers plan.tfplan et dire « c'est exactement ce qui a été approuvé ». Pour les environnements de staging ou de développement où les modifications sont petites et fréquentes, la commodité d'exécuter terraform apply sans fichier de plan peut être acceptable. Connaissez simplement le compromis.

Ce qui se passe pendant le processus d'application

Lorsque terraform apply s'exécute, il ne se contente pas d'« appliquer la configuration ». Il communique avec l'API du fournisseur pour chaque ressource qui doit être modifiée. Si vous créez une aws_instance, Terraform appelle l'API AWS EC2 pour lancer une instance. Si vous mettez à jour un google_storage_bucket, il appelle l'API Google Cloud Storage.

Chaque appel API peut prendre de quelques millisecondes à plusieurs minutes. La création d'une machine virtuelle prend généralement de 30 secondes à quelques minutes. Le provisionnement d'un cluster Kubernetes managé peut prendre 10 à 15 minutes. Terraform affiche la progression dans le terminal, mais il ne fournit pas de barre de progression pour chaque ressource individuelle. Vous voyez des messages comme :

Le diagramme suivant résume le flux d'application et les résultats en cas de succès ou d'échec :

flowchart TD A[Début terraform apply] --> B[Lire le fichier de plan ou re-planifier] B --> C[Acquérir le verrou d'état] C --> D[Pour chaque ressource : appeler l'API du fournisseur] D --> E{Toutes les ressources créées/mises à jour ?} E -- Oui --> F[Écrire l'état complet dans le fichier d'état] F --> G[Libérer le verrou d'état] G --> H[Apply réussi] E -- Non --> I[État partiel sauvegardé pour les ressources créées] I --> J[Libérer le verrou d'état] J --> K[Intervention manuelle nécessaire] K --> L[Corriger le problème et réappliquer] K --> M[Détruire manuellement ou utiliser terraform destroy] 
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]

Pendant ce temps, Terraform maintient le verrou d'état. Personne d'autre dans votre équipe ne peut exécuter terraform apply ou terraform plan tant que l'opération en cours n'est pas terminée ou n'a pas expiré. C'est intentionnel : cela empêche deux personnes de modifier la même infrastructure simultanément.

Que se passe-t-il en cas de succès de l'application

Après que toutes les ressources ont été créées ou mises à jour avec succès, Terraform écrit l'état actuel dans le fichier d'état. Ce fichier d'état enregistre chaque ressource avec son identifiant unique, tous ses attributs et les relations entre les ressources. Par exemple, si vous avez créé une instance EC2 et attaché un groupe de sécurité, le fichier d'état sait que aws_instance.app_server est associé à aws_security_group.web_sg.

Ce fichier d'état devient la source unique de vérité pour votre infrastructure. La prochaine fois que vous exécuterez terraform plan, Terraform comparera votre configuration avec le fichier d'état, et non avec les ressources cloud réelles. C'est pourquoi les fichiers d'état corrompus ou manquants causent autant de problèmes : Terraform perd son point de référence.

Que se passe-t-il en cas d'échec de l'application

Les échecs d'application sont suffisamment courants pour que vous sachiez comment les gérer. La création d'une ressource peut échouer pour les raisons suivantes :

  • Vous avez atteint une limite de quota (par exemple, trop d'instances EC2 dans une région)
  • Les identifiants du fournisseur ont expiré ou sont invalides
  • Il y a un conflit avec une ressource existante (par exemple, tentative de création d'un enregistrement DNS qui existe déjà)
  • Le fournisseur cloud subit une panne ou un ralentissement

Lorsqu'un échec se produit, Terraform n'annule pas tout. Il marque les ressources qui ont échoué et sauvegarde l'état pour tout ce qui a été créé avec succès. Cela signifie que vous vous retrouvez dans un état partiel : certaines ressources existent, d'autres non. Terraform ne nettoie pas automatiquement les ressources qui ont été créées avant l'échec.

Par exemple, si vous créez cinq ressources et que la quatrième échoue, les trois premières ressources existent toujours dans votre compte cloud. Le fichier d'état enregistre ces trois ressources comme créées. Vous devez décider de la marche à suivre :

  • Corriger le problème (par exemple, demander une augmentation de quota) et exécuter à nouveau terraform apply. Terraform tentera de créer les ressources restantes.
  • Détruire manuellement les ressources qui ont été créées et recommencer.
  • Utiliser terraform destroy pour tout nettoyer, mais seulement si vous êtes sûr de vouloir supprimer toutes les ressources.

Ce comportement d'état partiel est l'une des raisons pour lesquelles vous devriez tester les modifications d'infrastructure d'abord dans un environnement hors production. Un échec d'application en production peut laisser votre infrastructure dans un état incohérent nécessitant une intervention manuelle.

Liste de contrôle pratique avant d'exécuter Apply

Avant de taper terraform apply sur un environnement qui compte, passez en revue ces vérifications :

  • Avez-vous examiné la sortie du plan pour détecter des modifications inattendues, en particulier des suppressions ?
  • Le fichier d'état est-il sauvegardé ou stocké dans un backend distant avec versioning ?
  • Disposez-vous des identifiants pour annuler les modifications en cas de problème ?
  • Y a-t-il une fenêtre de maintenance ou une notification pour l'équipe ?
  • Pour la production : avez-vous utilisé un fichier de plan sauvegardé (terraform apply plan.tfplan) ?
  • Pour les modifications de base de données : avez-vous un plan de rollback de migration distinct de Terraform ?

L'essentiel à retenir

Exécuter terraform apply est le moment où votre configuration devient une infrastructure réelle. Utilisez un fichier de plan sauvegardé pour la production afin de garantir que vous appliquez exactement ce qui a été examiné. Comprenez que les échecs laissent un état partiel, et non des rollbacks automatiques. Et sachez toujours où se trouve votre fichier d'état et comment le récupérer, car sans lui, Terraform ne peut pas du tout gérer votre infrastructure.