Suite de ma série sur la certification Terraform Associate, après le premier module sur l’Infrastructure as Code. Le deuxième module de l’exam guide s’intitule “Terraform Fundamentals” : il s’agit de comprendre ce que sont les providers et comment le state fonctionne.

Les providers

Terraform ne parle nativement à aucun cloud. Tout se fait via des providers : des plugins qui traduisent le langage déclaratif HCL en appels API vers AWS, GCP, Azure, mais aussi Kubernetes, Cloudflare, Datadog, GitHub… Le cœur de Terraform (le CLI, le state, le langage) reste identique quel que soit le provider utilisé.

• Chaque provider ajoute un ensemble de types de ressources et/ou de data sources que Terraform peut gérer.
• Chaque type de ressource est implémenté par un provider ; sans providers, Terraform ne peut gérer aucun type d’infrastructure.
• Terraform exige un nom local unique pour chaque provider au sein d’un module.
• N’importe qui peut développer et distribuer ses propres providers Terraform
• Quand un provider est défini dans le module racine, Terraform transmet implicitement cette configuration à tous les modules enfants, afin que tous les modules utilisent la même configuration.

Ne pas confondre required_providerset provider:

required_providers

• Sert uniquement à terraform init : source (adresse dans le registry) + contrainte de version, pour savoir quel plugin télécharger.
• Pas de credentials, pas de région, aucune logique d’exécution.
• Un seul bloc par module.

provider

• Configure une instance réelle du provider : région, credentials, endpoints custom, etc.
• Peut apparaître plusieurs fois pour le même provider via alias (ex. déployer sur plusieurs régions AWS dans le même module).
• Sans lui, init fonctionne mais plan/apply échouera (ou retombera sur des credentials par défaut via variables d’env/CLI).

Dependency lock

• Le fichier lock ne suit que les dépendances des providers.
• Terraform crée ou met à jour automatiquement ce fichier à chaque exécution de terraform init.
• Ce fichier appartient à la configuration dans son ensemble, et non à chaque module pris séparément.

Comportement d’installation des dépendances

• Quand terraform init installe les providers nécessaires à une configuration, Terraform prend en compte à la fois les contraintes de version de la configuration et celles déjà enregistrées dans le fichier de lock.
• Si un provider n’a pas encore de version enregistrée, Terraform choisit la version la plus récente qui respecte la contrainte, puis met à jour le fichier de lock avec ce choix.
• On peut forcer ce comportement avec l’option -upgrade sur terraform init.

Le state : la mémoire de Terraform

Le fichier terraform.tfstate est ce qui permet à Terraform d’être déclaratif : c’est lui qui fait le lien entre la configuration HCL (ce que je veux) et les ressources réellement créées chez le fournisseur (ce qui existe). Sans state, Terraform ne pourrait pas savoir qu’un aws_instance.web dans le code correspond à l’instance i-0abc123 déjà en place.

Ses rôles concrets :

• Mapping vers le monde réel. Le state associe chaque ressource déclarée à un identifiant réel côté fournisseur, indispensable pour savoir quoi modifier ou détruire.
• Metadata. Il stocke aussi des informations que l’API du fournisseur n’expose pas toujours (dépendances entre ressources, par exemple), utiles pour calculer un plan correct.
• Performance. Pour de grosses infrastructures, relire l’état de centaines de ressources via l’API à chaque commande serait lent. Le state fait office de cache.
• Collaboration. En le stockant à distance (S3, GCS, Terraform Cloud…) avec un mécanisme de lock, plusieurs personnes peuvent exécuter des apply sans risquer d’écraser le travail des autres. C’est un point que j’avais déjà creusé en pratique dans mes articles sur the-forge-infra.

State distant (remote state)

• Terraform écrit les données de state dans un espace de stockage distant, qui peut ensuite être partagé entre tous les membres d’une équipe. Terraform prend en charge le stockage du state dans HCP Terraform, HashiCorp Consul, Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, et d’autres.
• Le state distant est implémenté par un backend, ou par HCP Terraform, tous deux configurables dans le module racine de la configuration.
• La data source terraform_remote_state utilise le dernier snapshot de state d’un backend donné pour récupérer les valeurs de sortie (outputs) du module racine d’une autre configuration Terraform.
• Pour les backends distants les plus complets, Terraform peut aussi verrouiller le state afin d’empêcher des exécutions concurrentes sur le même state.

Ce que je retiens

• required_providers vs provider : le premier dit à terraform init quoi télécharger (source, version), le second configure une instance réelle (région, credentials) et peut se dupliquer via des alias.
• Le state n’est pas un détail d’implémentation : c’est lui qui fait le lien entre le code HCL et les ressources réelles, sert de cache de métadonnées pour construire les plans, et permet le travail en équipe une fois stocké à distance avec un lock.
• Le fichier de lock ne concerne que les providers : il garantit des versions reproductibles à init, indépendamment des modules.

Prochaine étape de la série : le workflow Terraform.