infra / terraform
Pourquoi l'Infrastructure as Code et installation
Explication
Un peu d'histoire
Terraform est créé par HashiCorp, entreprise fondée en 2012 par Mitchell Hashimoto et Armon Dadgar, deux étudiants de l'université de Washington passionnés d'infrastructure distribuée. L'outil sort publiquement en juillet 2014, à une époque où gérer des infrastructures cloud (AWS existe depuis 2006) se faisait encore majoritairement via des clics dans des consoles web ou des scripts maison peu fiables. HashiCorp invente pour l'occasion son propre langage de configuration, HCL (HashiCorp Configuration Language), pensé pour rester lisible par un humain tout en restant suffisamment structuré pour être traité par une machine. Terraform devient rapidement l'outil de référence de l'Infrastructure as Code, au point de dépasser en popularité ses concurrents plus anciens comme CloudFormation (limité à AWS) ou Puppet/Chef (pensés pour la configuration plutôt que le provisioning).
Pourquoi apprendre Terraform aujourd'hui
Presque toutes les offres d'emploi DevOps, SRE ou Cloud Engineer mentionnent Terraform comme compétence attendue, tant l'outil est devenu un standard de facto dans l'industrie, tous clouds confondus (AWS, Azure, GCP, mais aussi Kubernetes, Datadog ou Cloudflare). Concrètement, une entreprise qui gère son infrastructure "à la main" perd un temps considérable en incidents liés à des changements manuels non documentés, et prend un risque réel de ne plus savoir reproduire son infrastructure en cas de sinistre — Terraform répond directement à ces deux problèmes.
Ce que vous allez apprendre
- Comprendre ce qu'apporte concrètement l'Infrastructure as Code par rapport à la console cloud manuelle
- Installer Terraform sur Linux ou macOS via les canaux officiels
- Distinguer une approche déclarative d'une approche impérative de gestion d'infrastructure
- Gérer plusieurs versions de Terraform en parallèle avec
tfenv - Identifier les sous-commandes de base disponibles via
terraform -help
Dans quel contexte ?
Une petite entreprise gère depuis deux ans son serveur de production en se connectant directement à la console AWS pour créer des instances EC2 à la main. Le jour où ce serveur doit être reproduit à l'identique dans une seconde région pour la reprise après sinistre, plus personne ne se souvient exactement des paramètres utilisés à l'origine (type d'instance, groupes de sécurité, tags). C'est exactement le problème que l'Infrastructure as Code résout : décrire l'infrastructure dans des fichiers, une bonne fois pour toutes.
D'abord, il faut comprendre ce que veut dire "déclaratif"
La plupart des débutants viennent d'un monde impératif : un script bash qui dit "fais ceci, puis cela, puis encore ceci". Terraform fonctionne différemment : on décrit l'état FINAL désiré ("je veux un bucket S3 nommé X"), et c'est Terraform lui-même qui calcule les actions nécessaires pour atteindre cet état, qu'il parte de zéro ou d'une infrastructure déjà partiellement créée.
Cette approche change complètement la façon de penser l'infrastructure : on ne raisonne plus en "étapes à exécuter", mais en "résultat final souhaité".
| Approche | Exemple | Limite |
|---|---|---|
| Console cloud (clic manuel) | Créer une instance EC2 à la souris | Non reproductible, non versionné |
| Script impératif (bash + CLI cloud) | Appeler aws ec2 run-instances dans un script | Doit gérer lui-même les cas déjà existants |
| Infrastructure as Code déclarative (Terraform) | Décrire l'état voulu en HCL | Nécessite d'apprendre le langage HCL |
Prérequis
Aucune connaissance préalable en cloud ou en Terraform n'est nécessaire pour cette leçon d'introduction. Un compte AWS gratuit (ou tout autre cloud) suffira pour les leçons pratiques suivantes.
Une fois ce principe compris, il reste une question pratique : comment installer l'outil ?
Sur Linux, HashiCorp fournit un dépôt APT officiel, la méthode la plus fiable pour rester à jour avec les correctifs de sécurité. Sur macOS, Homebrew propose un tap dédié, tout aussi simple à maintenir.
Bonne pratique
En équipe, utilise tfenv plutôt qu'une installation unique de Terraform. Un projet ancien peut nécessiter une version précise (1.5.0) tandis qu'un projet plus récent en exige une autre (1.9.0) : tfenv permet de basculer entre les deux sans tout désinstaller/réinstaller à chaque fois.
Le piège à éviter dès le départ
Beaucoup de débutants installent Terraform une seule fois et ne s'inquiètent jamais des versions ensuite — jusqu'au jour où un terraform apply échoue en CI avec une erreur de compatibilité, parce que la version locale d'un développeur diffère de celle utilisée par le pipeline. Fixer une version minimale explicite (vue dans la prochaine leçon avec required_version) évite ce genre de surprise.
Maintenant que Terraform est installé, la prochaine leçon aborde le tout premier fichier de configuration réel : comment déclarer un provider et créer sa toute première ressource cloud.
Commandes & code
Pourquoi l'Infrastructure as Code et installation
L'Infrastructure as Code (IaC) décrit l'infrastructure dans des fichiers versionnés plutôt que via des clics manuels.
# Installation Linux (via le dépôt officiel HashiCorp)
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform -y
# macOS
brew tap hashicorp/tap
brew install hashicorp/tap/terraform
# Vérifier l'installation
terraform version
terraform -help # liste toutes les sous-commandes disponibles
# Gestion de versions multiples avec tfenv (recommandé en équipe)
tfenv install 1.9.0
tfenv use 1.9.0
tfenv list # versions installées localement# Pourquoi l'IaC plutôt que la console cloud ?
# - Reproductible : la même config produit la même infra, à chaque fois
# - Versionnée : historique Git, revue de code (pull request) avant tout changement d'infra
# - Déclarative : on décrit l'état DÉSIRÉ, l'outil calcule le chemin pour y arriver
# - Terraform est multi-cloud : un seul langage (HCL) pour AWS, Azure, GCP, Kubernetes...Résumé
- Terraform est déclaratif : on décrit l'état voulu, il calcule et applique le diff nécessaire.
- L'installation via le dépôt officiel ou
tfenv(gestion de versions) sont les deux approches standards. - L'IaC apporte reproductibilité, revue de code et historique versionné à l'infrastructure.
Exercices pratiques
Mission : fiabiliser les versions Terraform de l'équipe
Objectif : Diagnostiquer une panne de CI causée par une divergence de version Terraform et sécuriser la configuration contre ce risque.
Contexte
Un développeur travaille en local avec Terraform 1.5.0 installé via le dépôt APT il y a plusieurs mois. La CI, elle, utilise Terraform 1.9.0 installé via tfenv. Un terraform apply qui fonctionne parfaitement en local échoue en CI avec une erreur de compatibilité liée à une syntaxe HCL introduite après la version 1.5.0. Aucun bloc required_version n'a été écrit dans le fichier main.tf.