Introduction
Dans les laboratoires précédents, vous jouiez le rôle du chef cuisinier en rédigeant des menus (des configurations) pour le robot (Terraform), afin qu’il les prépare (construise). Mais comment le robot se souvient-il de ce qu’il a déjà cuisiné ?
Imaginez que vous disposiez d’un entrepôt, mais que vous ayez perdu la liste d’inventaire. Vous ne sauriez pas ce que vous possédez, où cela se trouve ni si quelque chose a été volé.
Dans Terraform, cette liste d’inventaire s’appelle l’état (state). C’est la mémoire de Terraform. Elle enregistre les ressources qu’il a créées et associe les objets de configuration aux objets réels de l’infrastructure.
L’état rend la gestion déclarative concrètement exploitable. Sans lui, Terraform pourrait lire vos fichiers, mais il ne disposerait d’aucune mémoire fiable pour savoir quels objets réels correspondent à ces déclarations.
L’état est l’un des concepts les plus importants de Terraform. Sans lui, Terraform ne saurait pas ce qui existe déjà, ce qui a changé ni ce qui doit être mis à jour ou recréé.
Dans ce laboratoire, vous verrez comment Terraform utilise cet état pour maintenir votre infrastructure en bon état. Vous jouerez le rôle du « Chaos » en provoquant manuellement des incidents, puis vous observerez Terraform détecter les dommages et « réparer » automatiquement le système.
Inspecter l’état
Nous avons préconfiguré cet environnement pour vous. Un fichier main.tf existe et la commande terraform apply a déjà été exécutée. Cela signifie que l’infrastructure (un conteneur Docker) est déjà en fonctionnement.
Commencez par vérifier que le conteneur est actif :
sudo docker ps
Vous devriez voir un conteneur nommé tutorial.
Examinez maintenant les fichiers présents dans votre répertoire. Vous verrez terraform.tfstate.
ls -l
Ce fichier est le « journal secret » de Terraform. Il y consigne tout ce qu’il fait. Regardons ce qu’il contient.
cat terraform.tfstate
La sortie est au format JSON. Elle peut sembler complexe au premier abord, mais il s’agit simplement d’une manière structurée pour les ordinateurs de prendre des notes.
Quelque part dans ce texte, vous verrez docker_container ainsi que l’ID du conteneur en cours d’exécution. Cela prouve que Terraform « connaît » ce conteneur précis.
Règle essentielle : ne modifiez jamais ce fichier manuellement. Si vous le changez, Terraform peut perdre la mémoire et supprimer ou endommager accidentellement votre infrastructure. Laissez toujours Terraform gérer lui-même son journal.
Cet avertissement est important, car l’état contient des métadonnées faisant autorité : ce n’est pas un simple journal. Si vous le corrompez, Terraform risque ensuite de prendre des décisions destructrices ou difficiles à comprendre.
Créer une dérive
Terraform s’attend à être le seul responsable de la gestion de ces ressources. Mais dans le monde réel, des incidents peuvent se produire. Un serveur peut tomber en panne ou un collègue peut supprimer quelque chose par accident.
Cette situation s’appelle une dérive (Drift). Cela signifie que la « réalité » ne correspond plus au « plan ».
Les dérives sont fréquentes dans les environnements partagés, car des utilisateurs, des scripts, des pannes ou des systèmes externes peuvent modifier l’infrastructure en dehors du cycle normal de contrôle de Terraform.
Provoquons un peu de chaos. Nous allons contourner Terraform et supprimer directement le conteneur à l’aide de commandes Docker.
sudo docker rm -f tutorial
Vérifiez que le conteneur a bien disparu :
sudo docker ps
À ce stade, nous avons un problème :
- Réalité : le conteneur est arrêté et supprimé.
- Fichier d’état : Terraform pense que le conteneur fonctionne toujours (car personne ne l’en a informé).
Détecter la dérive
Voyons maintenant si Terraform remarque cette disparition.
Lorsque vous exécutez terraform plan, la première chose que fait Terraform est une « actualisation » (Refresh). Il interroge Docker en lui demandant : « Le conteneur dont l’ID est XYZ existe-t-il toujours ? »
Exécutez la commande de planification :
terraform plan
Observez attentivement la sortie. Vous devriez voir : docker_container.nginx: Refreshing state...
Terraform affichera ensuite un plan contenant un signe + vert (création).
Terraform will perform the following actions:
## docker_container.nginx will be created
+ resource "docker_container" "nginx" { ... }
Terraform a compris la situation ! Il a raisonné ainsi : « Mon plan indique qu’un conteneur doit exister. La réalité indique qu’il n’y en a aucun. Je dois donc en créer un nouveau pour atteindre l’état souhaité. »
Ce comportement de réconciliation est l’une des propriétés opérationnelles les plus importantes de Terraform. Terraform compare l’état souhaité, l’état enregistré et la réalité actuelle afin de déterminer la correction nécessaire.
Réparer l’infrastructure
C’est la capacité d’« autoréparation » de l’Infrastructure as Code. Comme notre code définit l’état souhaité (un conteneur en fonctionnement), Terraform peut corriger automatiquement toute dérive qui se produit.
Exécutez apply pour résoudre le problème :
terraform apply
Saisissez yes lorsque Terraform vous le demande.
Une fois l’opération terminée, vérifiez à nouveau Docker :
sudo docker ps
Le conteneur est de retour ! Il peut avoir un nouvel ID et s’agir d’une nouvelle instance, mais votre infrastructure correspond de nouveau, sur le plan fonctionnel, exactement à ce que vous avez défini dans le modèle.
Résumé
Dans ce laboratoire, vous avez constaté la puissance de l’état (State).
Vous avez appris :
- Le fichier d’état : la mémoire de Terraform concernant les éléments existants (
terraform.tfstate). - La détection des dérives : comment Terraform remarque les modifications effectuées à son insu, comme une suppression manuelle.
- L’autoréparation : comment
terraform applyrestaure automatiquement les ressources manquantes afin qu’elles correspondent à votre code.
Cette fiabilité explique pourquoi Terraform est utilisé pour gérer des infrastructures critiques. Même en cas d’incident, Terraform vous aide à revenir rapidement à un état connu et fonctionnel.
