Cours Terraform — infrastructure as code, HCL, état, plan et apply, modules, backends, import et OpenTofu

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. expliquer l'infrastructure as code et le cycle écrire, planifier, appliquer ;
2. lire et écrire un fichier HCL simple : blocs terraform, provider, resource, variable, output, locals, module ;
3. expliquer le rôle de l'état (tfstate), pourquoi il est sensible et pourquoi il ne se commite jamais ;
4. lire un plan (symboles +, -, ~, -/+) avant tout apply ou destroy ;
5. distinguer module racine et modules enfants, backend local et distant, workspaces ;
6. décrire l'import d'un objet existant et la détection de dérive ;
7. appliquer des bonnes pratiques de sécurité et d'organisation ;
8. situer OpenTofu et le changement de licence de HashiCorp avec leurs sources officielles ;
9. pratiquer sur un dossier local jetable, sans cloud réel.

Prérequis

• Ligne de commande ; notion de fichier de configuration déclaratif (comme un fichier YAML ou JSON).
• Cours « Concepts du cloud » (ressources, régions, coûts) pour comprendre ce que Terraform pilote en vrai.
• Aucun compte cloud n'est requis, ni pour lire ni pour les exercices.

Parcours et chapitres

1. Infrastructure as code et cycle de travail

D'après la page « Introduction » de la documentation, Terraform est un outil d'infrastructure as code : il permet de « définir, construire et gérer » des ressources cloud et sur site dans des fichiers de configuration lisibles, qu'on peut versionner et partager. Le flux de travail officiel tient en trois temps :

1. Write : décrire les ressources voulues (éventuellement chez plusieurs fournisseurs) ;
2. Plan : Terraform produit un plan d'exécution qui détaille les changements ;
3. Apply : après accord, les opérations sont exécutées dans le bon ordre.

Approche déclarative : on décrit le résultat voulu, pas la suite de gestes. Terraform passe par les API des plateformes grâce aux providers (fournisseurs), publiés sur le Terraform Registry : « des milliers » d'après la page (AWS, Azure, Google Cloud, Kubernetes, GitHub, etc.).

2. HCL : blocs, providers et ressources

La configuration s'écrit en HCL (HashiCorp Configuration Language) dans des fichiers .tf d'un même dossier (le module racine). Un fichier est fait de blocs (type "étiquette" { ... }) contenant des arguments (nom = valeur).

Une ressource se désigne par son adresse type.nom (par exemple local_file.exemple). Une référence à un autre objet (local_file.exemple.filename) crée une dépendance : Terraform en déduit l'ordre.

terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "<CONTRAINTE-DE-VERSION>"
    }
  }
}

resource "local_file" "exemple" {
  filename = "${path.module}/sortie/bonjour.txt"
  content  = "Bonjour depuis Terraform\n"
}

Points lus sur la page de la ressource local_file (fournisseur hashicorp/local) :

• filename est obligatoire ; les dossiers parents manquants sont créés ;
• exactement un des arguments content, content_base64 ou source donne le contenu ; sensitive_content est obsolète : utiliser la ressource local_sensitive_file pour un contenu sensible ;
• file_permission et directory_permission ont pour défaut 0777 (page consultée) : fixer des droits restrictifs (par exemple 0600) dès qu'un fichier n'est pas purement public ;
• Terraform considère le fichier comme supprimé s'il n'existe pas sur la machine qui relance apply.

Une ressource intégrée utile pour s'exercer sans fournisseur : terraform_data (adresse source terraform.io/builtin/terraform). Elle stocke une valeur (input) dans l'état et expose output ; triggers_replace force son remplacement quand une valeur change. Elle remplace l'ancienne null_resource (page « terraform_data »).

3. Variables, sorties et valeurs locales

Un bloc variable déclare une entrée du module ; on la lit avec var.<NOM>. Arguments lus (page « Input variables ») : type, description, default, sensitive, validation.

variable "message" {
  type        = string
  description = "Texte écrit dans le fichier d'exemple."
  default     = "Bonjour"
}

locals {
  contenu = "${var.message}, monde\n"
}

output "chemin_fichier" {
  description = "Chemin du fichier créé."
  value       = local_file.exemple.filename
}

Ordre de priorité des valeurs, de la plus forte à la plus faible (page consultée) :

1. options de ligne de commande -var et -var-file ;
2. fichiers *.auto.tfvars (ordre alphabétique) ;
3. terraform.tfvars.json ;
4. terraform.tfvars ;
5. variables d'environnement préfixées TF_VAR_ ;
6. valeur default du bloc.

Une sortie (output) expose une valeur après l'apply (terraform output, terraform output -json pour d'autres outils). Une sortie sensible reste lisible dans l'état.

4. L'état (tfstate)

D'après la page « State » : Terraform utilise l'état de l'espace de travail pour faire correspondre les objets réels avec la configuration, suivre des métadonnées et améliorer les performances. Par défaut l'état est un fichier local terraform.tfstate dans le dossier de travail.

• jamais terraform.tfstate, terraform.tfstate.backup, .terraform/ ni les fichiers *.tfvars secrets dans Git ;
• pas non plus dans un message, une capture ou un prompt à un assistant IA ;
• ne pas éditer l'état à la main : utiliser la commande terraform state (sous-commandes à lire dans l'aide ; non détaillées ici : non vérifié) ;
• pour travailler à plusieurs : état distant verrouillé (chapitre 8).

# .gitignore minimal pour un dossier Terraform
.terraform/
*.tfstate
*.tfstate.*
crash.log
*.tfvars

Ce modèle de .gitignore est une pratique courante ; son contenu exact n'a pas été relu sur une page officielle (non vérifié). Le fichier .terraform.lock.hcl est en général, lui, versionné (à confirmer).

Lecture de l'état sans le modifier. Des commandes comme terraform show et terraform state list affichent l'état : leur sortie peut contenir des secrets et ne se copie nulle part (syntaxes exactes : non vérifié).

5. init, plan, apply et destroy

Séquence de travail dans un dossier de configuration. Les commandes, lues dans la documentation, sont à lancer à la main, jamais par le générateur.

Étape 1 — initialiser (télécharge les providers)

terraform init

• Contexte : dossier de configuration jetable ; Terraform installé (version de Stéphane inconnue ; l'installation modifie le poste et n'est pas détaillée ici). Accès réseau au Terraform Registry si un provider doit être téléchargé.
• Droits : utilisateur ordinaire, écriture dans le dossier courant.
• Effet : crée le dossier .terraform/ (providers et modules téléchargés) et le fichier de verrouillage .terraform.lock.hcl. N'agit sur aucun objet réel. À relancer quand un backend, un provider ou un module change.
• Vérification : le message de fin indique une initialisation réussie.
• Retour arrière : supprimer le dossier .terraform/ (le fichier de verrouillage est à conserver ou non selon la pratique de l'équipe).

Étape 2 — formater et valider (lecture et correction locale)

terraform fmt -checkterraform validate

• Contexte : dossier initialisé. Ces deux commandes sont connues de la CLI ; leurs options exactes n'ont pas été relues (non vérifié).
• Droits : lecture des fichiers.
• Effet : fmt -check signale les fichiers mal formatés sans les modifier ; validate vérifie la cohérence de la configuration sans contacter d'infrastructure.
• Vérification : aucune erreur n'est affichée.
• Retour arrière : sans objet.

Étape 3 — planifier (lecture, prévisualisation)

terraform plan -out=plan.tfplan

• Contexte : dossier initialisé ; fournisseur configuré. Option -out=FILE lue sur la page terraform plan.
• Droits : ceux qu'il faut pour lire les objets gérés (dans nos exercices : lecture du dossier local).
• Effet : lit l'état et la réalité, compare à la configuration et propose des actions, sans rien modifier. Le fichier plan.tfplan peut contenir des valeurs sensibles : ne pas le commiter ni le partager.
• Vérification : relire chaque ligne. Symboles : + création, - suppression, ~ modification sur place, -/+ remplacement (suppression puis recréation, donc risque pour les données).
• Retour arrière : supprimer le fichier de plan.

Étape 4 — appliquer le plan relu

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

terraform apply plan.tfplan

• Contexte : dossier d'essai jetable (ou compte d'essai), plan produit juste avant et relu en entier ; état à jour. Appliquer un fichier de plan (terraform apply FILE) exécute exactement ce plan (page plan).
• Droits : ceux nécessaires pour créer, modifier ou supprimer les objets du plan.
• Effet : crée, modifie ou détruit des objets réels et écrit l'état (terraform.tfstate, secret).
• Vérification : terraform plan immédiatement après n'annonce plus aucun changement ; vérifier l'objet créé (dans nos exercices : le fichier dans le dossier de sortie).
• Retour arrière : modifier la configuration puis planifier et appliquer à nouveau, ou détruire (ci-dessous) ; une suppression d'objet n'est pas annulable (données perdues).

Étape 5 — prévisualiser puis détruire

terraform plan -destroy

• Contexte : dossier d'essai ; état à jour.
• Droits : lecture des objets gérés.
• Effet : montre tout ce qui serait détruit, sans rien détruire (mode -destroy de plan, page consultée).
• Vérification : la liste correspond exactement à ce qu'on veut retirer, et à rien d'autre.
• Retour arrière : sans objet.

Attention, effet notable. Cette commande peut supprimer ou retirer des éléments. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

terraform destroy

• Contexte : dossier ou compte d'essai uniquement ; plan -destroy relu juste avant ; sauvegarde des données utiles. La commande demande une confirmation : la lire, ne pas la contourner par une option d'approbation automatique. Sur autre chose qu'un essai, ne pas lancer sans validation de Stéphane.
• Droits : suppression des objets gérés par cette configuration.
• Effet : détruit tous les objets suivis par l'état de l'espace de travail courant ; vérifier l'espace actif (chapitre 9).
• Vérification : terraform state list ne liste plus rien ; l'objet réel a disparu.
• Retour arrière : aucun pour les données détruites ; recréer par plan puis apply rétablit la structure, pas les données.

6. Laboratoire local sans cloud

Objectif : voir tout le cycle sans ouvrir de compte. Dossier de travail neuf, hors de tout dépôt, par exemple un dossier de test vide créé à la main. Fichiers à y écrire : main.tf (chapitre 2), variables.tf (chapitre 3).

Déroulé conseillé (chaque commande décrite aux chapitres précédents) :

1. terraform init ; observer .terraform/ et .terraform.lock.hcl ;
2. terraform validate, puis terraform plan -out=plan.tfplan ; lire le plan : une création + de local_file.exemple ;
3. terraform apply plan.tfplan ; ouvrir le fichier créé et le fichier d'état (sans copier son contenu) ;
4. modifier message (-var 'message=Salut' au plan suivant) ; observer un -/+ ou un ~ selon le cas ;
5. dériver à la main : modifier ou supprimer le fichier créé, puis terraform plan : Terraform signale l'écart (chapitre 10) ;
6. terraform plan -destroy, puis terraform destroy, puis supprimer le dossier de test.

Variante sans téléchargement de provider : remplacer local_file par une ressource terraform_data (aucune installation de fournisseur) et observer l'état qui garde la valeur d'input.

resource "terraform_data" "exemple" {
  input = "valeur-factice"
}

output "valeur" {
  value = terraform_data.exemple.output
}

7. Modules

D'après la page « Modules » : le module racine est la configuration du dossier de travail ; un module enfant est appelé par un bloc module. Les modules sont réutilisables : on les écrit, on les distribue (Terraform Registry public, registre privé, dossier local, dépôt de gestion de versions), puis on les consomme avec source et version.

module "fichiers" {
  source = "./modules/fichiers"
  message = "Bonjour"
}

• Un module a ses entrées (variable) et ses sorties (output) ; le module appelant ne voit que les sorties.
• terraform init télécharge ou lie les modules.
• Un module de registre public est du code d'un tiers qui s'exécute avec vos droits : le relire et figer sa version avant usage (principe de prudence ; contrôle du contenu des modules : non vérifié).

8. Backends et état distant

Un backend définit où Terraform stocke l'état (page « Backend »). Sans configuration : backend local (fichier sur disque), adapté à un usage personnel, pas à une équipe. Backends distants cités : S3, Azure Storage (azurerm), Google Cloud Storage (gcs), Consul, HTTP, Kubernetes, PostgreSQL, etc. Certains gèrent le verrouillage d'état pendant une opération, ce qui évite deux apply simultanés.

terraform {
  backend "s3" {
    bucket = "<NOM-COMPARTIMENT>"
    key    = "<CHEMIN>/terraform.tfstate"
    region = "<REGION>"
  }
}

• Changer la configuration d'un backend impose de relancer terraform init ; Terraform propose alors de migrer l'état existant vers la nouvelle destination. Sauvegarder l'état avant (copie hors dépôt).
• Ne pas mettre d'identifiants dans la configuration du backend : la page recommande les variables d'environnement.
• Un état distant doit être chiffré, à accès restreint et sauvegardé (propriétés du stockage choisi : non vérifié). Les paramètres exacts d'un backend donné sont à lire sur sa page ; ce bloc est une illustration.
• terraform_remote_state et les environnements HCP Terraform ne sont pas traités ici.

9. Workspaces

Les workspaces (espaces de travail CLI) permettent plusieurs états à partir d'une seule configuration (page « Workspaces »). Il existe toujours un espace nommé default, non supprimable. Commandes : terraform workspace list, new, select, show, delete.

10. Import et dérive

Dérive. Les objets réels peuvent changer hors de Terraform (modification manuelle dans une console). Le plan compare la réalité à l'état et à la configuration et la fait apparaître. Le mode terraform plan -refresh-only met à jour l'état pour refléter la réalité sans changer les objets (page plan). La stratégie : soit on réaligne la réalité sur la configuration (apply), soit on met la configuration à jour pour accepter le changement. Ne jamais laisser des modifications manuelles s'installer.

Import. Pour mettre sous gestion de Terraform un objet existant, la page « Import » décrit : un bloc import (objet réel identifié par son id ou son identity) et un bloc resource correspondant dans la configuration, puis terraform apply ; alternativement, un bloc import seul avec terraform plan -generate-config-out pour générer la configuration de la ressource. L'ancienne commande terraform import existe aussi (non détaillée : non vérifié).

import {
  to = local_file.existant
  id = "<IDENTIFIANT-DE-L-OBJET>"
}

• Contrainte : l'id attendu dépend du fournisseur et de la ressource (page du provider) ; ne pas le deviner.
• Importer n'écrit pas l'objet : le plan montre l'import, puis l'état est mis à jour à l'apply. Relire que le plan ne prévoit ensuite aucune modification de l'objet importé.
• Cet exemple n'est pas à exécuter : la ressource local_file n'a pas été vérifiée comme importable (non vérifié).

11. Bonnes pratiques

1. Versionner les fichiers .tf (sans secrets) ; jamais l'état, .terraform/ ni les *.tfvars secrets.
2. État distant verrouillé, chiffré, à accès restreint pour tout travail partagé.
3. Lire le plan en entier, appliquer un plan enregistré, relire particulièrement les - et -/+.
4. Pas de secret en clair dans la configuration : variables d'environnement, coffre de secrets, identifiants temporaires du fournisseur ; sensitive masque l'affichage, pas l'état.
5. Figer les versions (Terraform, providers, modules) et relire les changements avant de monter de version.
6. Moindre privilège pour l'identité qui exécute Terraform ; une identité distincte par environnement.
7. Petits modules, noms explicites, description sur chaque variable et sortie ; terraform fmt et validate avant chaque commit.
8. Pas de modifications manuelles des objets gérés ; surveiller la dérive.
9. Étiqueter les ressources (propriétaire, projet) et poser un budget avant d'appliquer sur un compte cloud.
10. Séparer développement et production par des états et des droits distincts, pas seulement par des workspaces.

Les points 5 à 10 sont des pratiques d'usage courant : celles que les pages lues établissent explicitement sont les points 1 à 4 et la limite des workspaces ; les autres sont à confirmer dans la documentation « bonnes pratiques » de HashiCorp (non lue).

12. OpenTofu et changement de licence

Le changement de licence. Le 10 août 2023, HashiCorp a annoncé le passage de ses produits, dont Terraform, de la licence Mozilla Public License v2.0 (MPL 2.0) à la Business Source License v1.1 (BSL ou BUSL) pour les versions futures (billet officiel « HashiCorp adopts Business Source License »). La BSL restreint les usages par des fournisseurs de services concurrents : d'après le billet, ils ne pourraient plus intégrer les versions futures, correctifs et mises à jour de sécurité. Les API, SDK et « presque toutes les autres bibliothèques » restent en MPL 2.0. Conséquence pratique : vérifier la licence de la version utilisée et de son usage (particulier, entreprise, offre commerciale) ; l'analyse juridique dépasse ce cours et n'est pas vérifiée.

OpenTofu. D'après la FAQ officielle d'OpenTofu, c'est un fork de Terraform, créé à l'initiative de plusieurs entreprises en réaction au passage de HashiCorp à la BUSL ; le projet est sous licence MPL 2.0 et placé sous la gouvernance de la Linux Foundation. OpenTofu n'a pas ses propres fournisseurs : il utilise les fournisseurs existants via un registre séparé (search.opentofu.org) ; il est compatible avec les fichiers d'état créés jusqu'aux versions Terraform 1.5.x (d'après la FAQ). Sa page de migration affirme viser la compatibilité (« la plupart du code Terraform fonctionne sans modification ») et demande de sauvegarder l'état et le code avant toute migration ; elle recommande une attention particulière pour terraform_remote_state. La commande d'OpenTofu est tofu.

Choisir. Les deux outils partagent l'essentiel des concepts de ce cours. Les différences (fonctionnalités propres à chacun, versions comparables, compatibilité actuelle entre Terraform 1.16 et OpenTofu 1.13, services managés) n'ont pas été établies : non vérifié. Ne pas migrer un projet sans lire la page de migration et sans sauvegarde de l'état.

Exercices et vérifications de fin de cours

Papier ou dossier local jetable ; aucun cloud réel.

1. Cycle. Redessiner écrire, planifier, appliquer et dire ce que lit et ce qu'écrit chaque étape.
2. HCL. Lire main.tf du chapitre 2 et donner l'adresse de la ressource, la dépendance éventuelle et l'effet d'un changement de content.
3. Variables. Écrire une variable message avec description et valeur par défaut, et prédire la valeur effective si terraform.tfvars et -var la fixent toutes les deux.
4. État. Écrire la liste de ce qui est exclu de Git dans un dossier Terraform et dire pourquoi pour chaque entrée.
5. Lecture d'un plan. Face à un plan montrant un -/+, dire ce qui est détruit puis recréé et quoi vérifier avant d'appliquer.
6. Laboratoire. Dérouler le chapitre 6 dans un dossier jetable : init, plan, apply, dérive provoquée à la main, nouveau plan, plan de destruction, destruction, suppression du dossier.
7. Modules. Extraire la ressource dans un module local et appeler le module avec une valeur différente.
8. Backend. Expliquer ce qui change dans le travail d'équipe avec un état distant verrouillé.
9. Licence. Rédiger en trois lignes la différence entre Terraform (BSL) et OpenTofu (MPL 2.0) avec les sources.

Critères de réussite

• Distinguer plan (lecture) et apply (effet), et ne jamais appliquer sans avoir lu le plan.
• Savoir que terraform.tfstate est un secret et ne se commite jamais.
• Savoir que sensitive masque l'affichage mais pas l'état.
• Expliquer module racine, module enfant, backend, workspace, import, dérive.
• Situer OpenTofu et le changement de licence avec leurs sources officielles.
• Dire ce qui n'a pas été vérifié.