Terraform : le guide complet pour débuter avec l’Infrastructure as Code
Terraform gère votre infrastructure en la décrivant comme code déclaratif.
- Créé par HashiCorp en 2014 comme outil open source IaC.
- Déclarez des resources (VM, réseau, DNS) dans un fichier texte.
- Le workflow repose sur 3 commandes : init, plan, apply.
- Le state (
terraform.tfstate) enregistre l’état réel comparé au voulu. - Déployez 10 environnements identiques en une seule commande.
Concepts fondamentaux de Terraform et Infrastructure as Code
Qu’est-ce que Terraform et pourquoi l’utiliser ?
Terraform est un outil open source créé par HashiCorp en 2014, qui permet de gérer votre infrastructure en la décrivant sous forme de code. Plutôt que de cliquer manuellement dans une console cloud pour créer chaque serveur, vous écrivez un fichier texte décrivant l’état voulu de votre infrastructure : une VM avec 2 CPU, un volume de stockage, une adresse IP publique, etc. Terraform compare ensuite cet état voulu à la réalité de votre infrastructure et applique automatiquement les écarts constatés.
L’approche Infrastructure as Code (IaC) transforme radicalement votre travail. Imaginez devoir configurer 50 serveurs à la main : vous risquez des erreurs, des oublis et y passeriez des heures. Avec Terraform, vous décrivez votre infrastructure dans un fichier, puis 10 environnements identiques se créent en une seule commande.
C’est ce qui explique son adoption massive : Terraform pilote aujourd’hui plus de 1 millier de providers couvrant tous les grands acteurs du cloud.
Les composants essentiels : provider, resource, state, workflow
Pour bien démarrer, quatre concepts structurent tout projet Terraform :
- Provider : plugin pont entre le code HCL et l’API du cloud, il traduit vos intentions en appels techniques
- Resource : élément d’infrastructure (VM, réseau, DNS), c’est le composant de base à déclarer
- State : fichier JSON
terraform.tfstate, la mémoire de Terraform qui enregistre l’état réel - Workflow : cycle en 3 commandes
initpour préparer,planpour prévisualiser,applypour appliquer
Le workflow est le rythme de travail que vous répéterez à chaque modification : vous écrivez du code HCL, vous lancez terraform plan pour voir ce qui va changer, puis terraform apply pour exécuter. Ce cycle simple, répété à chaque évolution, vous donne un contrôle total sur votre infrastructure tout en gardant une trace écrite de chaque modification.
Fournisseurs cloud : AWS, Azure, Hetzner, KVM
| Fournisseur | Provider à utiliser | Cas d’usage typique | Spécificité clé |
|---|---|---|---|
| AWS | aws | Instance EC2, subnet, security groups | Gestion fine via IAM |
| Azure | azurerm | Machines virtuelles, services managés | Nécessite Azure CLI configurée |
| Hetzner | hcloud | Serveurs européens à petit prix | API token Read & Write requis |
| KVM/libvirt | libvirt | Lab local, tests sans facture | Aucun compte cloud nécessaire |
| Docker | docker | Images, conteneurs, networks, volumes | Idéal pour s’entraîner en local |
Terraform pilote à ce jour plus d’un millier de providers, chacun agissant comme un pont entre votre code HCL et l’API du fournisseur choisi. Pas de panique : pour débuter, concentrez-vous sur un seul provider et maîtrisez ses ressources avant d’en explorer d’autres.
Côté cloud public, AWS et Azure dominent avec leurs providers matures et leur documentation exhaustive. Hetzner séduit par ses prix compétitifs et ses datacenters européens un excellent compromis pour apprendre sans investir. Si vous voulez pratiquer gratuitement, le provider Docker ou KVM via libvirt vous permet de créer des machines virtuelles en local, sans compte cloud ni facture surprise, à l’image de l’orchestration de conteneurs avec Kubernetes qui automatise le déploiement et la mise à l’échelle.
Le choix de votre fournisseur dépend avant tout de votre objectif : un hébergement rapide et léger penchera vers Hetzner, tandis qu’une infrastructure d’entreprise s’orientera naturellement vers AWS ou Azure. Pour la formation, rien ne remplace un environnement local avec KVM vous pouvez tout casser, tout recommencer, sans conséquences.
Cette flexibilité dans le choix du fournisseur rappelle l’importance de bien sélectionner ses outils de stockage de données : une base vectorielle comme Pinecone offre un scaling automatique et des recherches de similarité en millisecondes, un atout pour les applications modernes.
Premier projet pas-à-pas : création et déploiement
Avant d’écrire votre première ligne de code, il est essentiel de comprendre comment un projet Terraform s’organise. Cette structure standard, bien que simple, est la clé d’un déploiement propre et maintenable. Le cycle de vie complet repose sur 3 commandes : init, plan et apply.
Structure d’un projet Terraform : les 3 fichiers essentiels
Un projet Terraform minimaliste mais efficace se compose de trois fichiers distincts, chacun ayant une responsabilité unique. Cette séparation stricte facilite la lecture, la collaboration et la maintenance, même pour un projet de test.
- variables.tf : déclare les paramètres d’entrée (tokens, noms, tailles).
- main.tf : définit les ressources à créer (le cœur de l’infrastructure).
- outputs.tf : affiche les valeurs résultantes (IP, ID, URL).
Déploiement concret : du plan à l’apply
Prenons l’exemple d’un serveur chez Hetzner. Une fois votre structure en place, vous exécutez les commandes dans l’ordre. La commande terraform init télécharge le provider, puis terraform plan analyse l’écart entre l’état actuel et l’état désiré. Enfin, terraform apply applique les changements après confirmation.
- Prérequis : un compte Hetzner avec un API token Read & Write.
- terraform init : initialise le projet et télécharge le plugin.
- terraform plan : affiche un aperçu des actions à venir.
- Confirmer apply : tapez yes pour appliquer les changements.
- Vérifier outputs : l’IP publique et l’ID sont affichés dans le terminal.
- Nettoyer : utilisez terraform destroy pour supprimer les ressources.
Ce processus aboutit à un serveur provisionné en quelques secondes, avec les outputs affichés directement à l’écran. Pour les tests, n’oubliez jamais la dernière étape de nettoyage, surtout si vous utilisez des ressources cloud facturées à l’heure.
Installation de Terraform et gestion du state
Installation et configuration de Terraform sur son environnement
L’installation de Terraform est un processus rapide et indolore grâce à son architecture de binaire unique. Contrairement à d’autres outils qui dépendent de nombreux prérequis système, Terraform fonctionne nativement avec votre système d’exploitation. En moins d’1 minute, vous pouvez passer de zéro à une installation fonctionnelle, prête pour votre premier déploiement.
Après l’installation, la vérification est immédiate : la commande `terraform -version` confirme l’installation et affiche la version utilisée. La version 1.14.x est celle recommandée pour suivre ce parcours d’apprentissage, car elle garantit une compatibilité totale avec les fonctionnalités décrites dans la formation.
State local et distant : bonnes pratiques essentielles
Le fichier `terraform.tfstate` est la mémoire de votre infrastructure. Il contient l’état exact de vos ressources : adresses IP, identifiants, configurations. Cette richesse d’informations en fait une cible sensible pour les attaquants, mais aussi un élément critique de votre projet. La règle absolue : ne committez jamais ce fichier dans Git. S’il contient des données sensibles comme des IP publiques ou des identifiants d’accès, son exposition dans un dépôt public serait une faille désastreuse.
| Type de state | Avantages | Quand l’utiliser |
|---|---|---|
| Local (fichier) | Simple, aucun coût | Débutant, projets solo |
| Distant (S3, Blob) | Partage d’équipe, locking | Équipe, production |
Pour une équipe, le state distant est indispensable. Un backend comme Azure Blob Storage ou AWS S3 permet un accès partagé, un versioning automatique et surtout le locking ce verrou empêche deux membres de modifier l’infrastructure simultanément, évitant ainsi des conflits destructeurs.
Une formation structurée sur 9 modules avec 91 leçons et 7 quiz consacre 3 leçons spécifiques aux données sensibles. Ce temps est nécessaire car la gestion du state est une compétence à part entière : on n’édite jamais le fichier manuellement, uniquement via les commandes `terraform state`. Ces règles simples vous éviteront les erreurs les plus coûteuses.
Module 4 : Bonnes pratiques, data sources et comparaison avec Ansible
Bonnes pratiques et comparaison avec Ansible
Adopter les bonnes pratiques Terraform dès le départ évite les erreurs coûteuses. Avant chaque déploiement, lisez systématiquement la sortie de terraform plan pour vérifier les actions prévues. Séparez vos fichiers par responsabilité variables.tf, main.tf et outputs.tf et épinglez les versions des providers en committant le fichier .terraform.lock.hcl. Validez toujours votre configuration avec les commandes terraform fmt et terraform validate avant de pousser votre code.
Utilisez des variables plutôt que des valeurs en dur, et passez les secrets via des variables d’environnement TF_VAR_. Pour les projets de test, pensez à terraform destroy pour nettoyer vos ressources et éviter les coûts inutiles.
La comparaison avec Ansible est fréquente. Là où Terraform est déclaratif et gère le cycle de vie complet des ressources cloud, Ansible est plutôt impératif et excelle dans la configuration des serveurs après leur création. Ces deux outils sont complémentaires : Terraform crée les machines, Ansible les configure. L’utilisation conjointe est une pratique courante dans l’industrie.
Prérequis avant de commencer et sources de données (data source)
Avant de vous lancer, sachez que la manipulation de Terraform exige un minimum de compétences techniques. Les prérequis sont les suivants :
- Ligne de commande Linux : compétence essentielle, tout se passe en terminal
- Lecture du langage HCL : savoir lire et comprendre un fichier.tf
- Hyperviseur KVM : utile pour créer un laboratoire local gratuit
- Compte cloud avec API token : par exemple un compte Hetzner avec un token en lecture/écriture
Les data sources sont des fonctions clés de Terraform. Contrairement aux ressources, elles permettent d’interroger des éléments existants sans les gérer, comme des images Docker ou des réseaux déjà créés. Elles s’avèrent précieuses pour intégrer Terraform dans une infrastructure préexistante, en récupérant des informations dynamiques tout en évitant de recréer ce qui existe déjà.
Pour approfondir ces notions, sachez qu’une formation complète de 39 heures, structurée en 9 modules et 91 leçons, vous permettra de maîtriser ce sujet en détail, avec des quiz et une banque d’entraînement de 217 questions.
Terraform vs OpenTofu : différences et implications
La divergence entre Terraform et OpenTofu est d’abord juridique avant d’être technique. En août 2023, HashiCorp a fait passer Terraform sous licence BSL 1.1, qualifiée de « source-available » plutôt que véritablement open source. Ce changement a immédiatement motivé la création d’OpenTofu, un fork né la même année sous licence MPL-2.0, désormais hébergé par la Linux Foundation. Pour la majorité des utilisateurs, les deux outils restent extrêmement proches : même langage HCL, mêmes providers, même gestion du state et même compatibilité avec vos modules existants.
La migration pratique se résume souvent à remplacer la commande terraform par tofu. OpenTofu introduit néanmoins quelques divergences, comme le chiffrement natif du state. Ce choix dépendra surtout de votre tolérance au risque et de votre politique open source, plutôt que d’un écart fonctionnel majeur.