Les notions de state et de provider

I. L'état ou state Terraform

Pour que Terraform puisse gérer efficacement des composants d'infrastructure au fil du temps, il doit garder en mémoire les ressources qu’il a créées, modifiées ou supprimées. C’est précisément le rôle du state, un élément central de son fonctionnement.

Le fichier d’état (state) conserve une représentation fidèle de l’infrastructure à un moment donné, si bien que Terraform peut comparer l’état actuel avec la configuration désirée, détecter les écarts et appliquer uniquement les changements nécessaires. Si des modifications sont apportées manuellement, en dehors de Terraform, le fichier d’état devient alors obsolète, ce qui peut provoquer des incohérences ou des comportements inattendus lors des déploiements suivants.

Il est important de noter que si une ressource déployée par Terraform est modifiée manuellement (par exemple, via le portail Azure ou une commande CLI), ces changements ne seront pas pris en compte dans le state : ceci peut provoquer des incohérences et des erreurs lors des prochaines exécutions ou même la re-création involontaire de ressources. Pour éviter ces désagréments, il est essentiel d’adopter une culture d’automatisation comme le propose l’approche DevOps. Utiliser Terraform de façon rigoureuse et efficace suppose que l’ensemble de l’équipe s’engage à ne pas effectuer de modifications manuelles, mais à faire évoluer l’infrastructure uniquement via le code. C’est à cette condition que les bénéfices de l’IaC comme la traçabilité, la reproductibilité et l'évolutivité peuvent être pleinement réalisés.

C’est grâce au state que la commande terraform plan peut proposer des changements précis, et que terraform apply peut agir de façon ciblée, sans tout redéployer à chaque fois.

Par défaut, le state est stocké localement dans un fichier nommé terraform.tfstate, mais dans les projets collaboratifs ou critiques, il est recommandé de l’enregistrer dans un backend distant, une notion qui mérite quelques précisions.

II. Le backend

Dans Terraform, le backend désigne le mécanisme qui permet de stocker et de gérer le fichier d’état (terraform.tfstate). Ce fichier est crucial puisqu'il contient l’inventaire des ressources déployées ainsi que leur état actuel selon Terraform. Il permet à l’outil de comparer la configuration déclarée dans le code avec l’infrastructure existante, et de déterminer les opérations à effectuer lors d’un plan ou d’un apply.

Comme nous l'avons mentionné plus haut, le state est conservé localement dans le répertoire du projet ou dans un sous-dossier.terraform généré lors de l'opération d'initialisation (terraform init). Cette solution est parfaitement fonctionnelle pour un environnement de test ou pour un usage individuel, mais elle comporte certaines limites :

• Si le fichier est supprimé accidentellement ou corrompu, Terraform perd toute trace de l’infrastructure qu’il a créée. Par conséquent, il ne sera plus en mesure de déterminer ce qui existe déjà, ni de supprimer ou de modifier des ressources de manière fiable.

• Dans un environnement collaboratif, chaque utilisateur disposerait d’un état local différent, ce qui pourrait entraîner des conflits et des comportements imprévisibles si plusieurs personnes appliquent des modifications en parallèle.

Pour pallier ces problèmes, il est possible de configurer un backend distant, comme un stockage S3 (AWS), un conteneur Azure Storage, Google Cloud Storage ou un serveur HTTP compatible. Ces options permettent de centraliser l’état, de verrouiller l’accès lors des modifications et d’assurer une meilleure coordination dans un contexte partagé ou automatisé.

Dans notre cas, nous allons utiliser le backend par défaut, c’est-à-dire le stockage local du fichier terraform.tfstate, ce qui est suffisant pour notre premier projet. Cette pratique nous permettra de mieux comprendre le fonctionnement de Terraform avant d’aborder des scénarios plus avancés.

III. Les providers

Pour que Terraform puisse créer, modifier ou supprimer des ressources sur une plateforme donnée, il doit s’appuyer sur un composant intermédiaire appelé provider. Ce dernier joue un rôle central, car il permet à l'outil de communiquer avec les API des différents environnements cibles comme les fournisseurs de services cloud tels qu'Azure, AWS, Google Cloud Platform ou encore des solutions sur site comme VMware et Nutanix.

Chaque provider encapsule toutes les particularités techniques des plateformes (API, formats, authentification) et expose à Terraform un ensemble de ressources que l’on peut déclarer et configurer à l’aide du langage HCL.

Dans le contexte de Terraform, une ressource représente un composant d’infrastructure à gérer, comme une machine virtuelle, une adresse IP, un réseau virtuel ou une base de données. Chaque ressource correspond à un élément concret que Terraform peut créer, modifier ou supprimer, en fonction de la configuration décrite dans les fichiers .tf. Il s'agit de l’unité de base à partir de laquelle une infrastructure est construite et déployée.

Lorsqu’un projet Terraform est initialisé avec la commande terraform init, l’outil télécharge automatiquement les providers spécifiés dans un répertoire local nommé .terraform qui est utilisé pour gérer les dépendances. Ce mécanisme permet à Terraform de rester modulaire et extensible, tout en ne chargeant que ce qui est nécessaire à un projet donné. La structure interne du répertoire .terraform reflète l’origine du provider (ici, hashicorp/azurerm) :

.terraform/
├── providers/
│   └── registry.terraform.io/
│       └── hashicorp/
│           └── azurerm/

La plupart des providers officiels, y compris ceux pour Azure, AWS, Google Cloud, sont disponibles sur le site du Terraform Registry où vous pouvez consulter la documentation de chacun d'entre eux et récupérer les blocs de configuration de base à adapter selon vos besoins.

À ce stade du cours, nous comprenons