Comme annoncé précédemment, je prépare la certification Terraform Associate. Premier objectif de l’exam guide : “Understand Infrastructure as Code (IaC) concepts”. Avant de parler syntaxe HCL ou providers, il s’agit de poser les bases : qu’est-ce que l’IaC, et pourquoi ça a remplacé la gestion manuelle d’infrastructure.
Qu’est-ce que l’Infrastructure as Code
L’Infrastructure as Code, c’est décrire son infrastructure (serveurs, réseau, bases de données, permissions IAM…) sous forme de fichiers texte versionnables, plutôt que de la construire à la main via une console web ou des commandes ad hoc.
Ces fichiers deviennent la source de vérité : un outil (Terraform, mais aussi Pulumi, CloudFormation, Ansible…) les lit et se charge de créer, modifier ou supprimer les ressources correspondantes chez le fournisseur cloud.
Deux façons d’écrire cette description :
- Impératif : on décrit la suite d’étapes pour arriver au résultat (“crée un VPC, puis crée un subnet dedans, puis attache une route table…”). C’est l’approche d’un script bash ou d’un playbook Ansible classique.
- Déclaratif : on décrit l’état final voulu (“je veux un VPC avec ce CIDR et ces subnets”), et l’outil calcule lui-même les actions nécessaires pour y parvenir. C’est l’approche de Terraform.
L’approche déclarative est centrale pour comprendre Terraform : on ne lui dit jamais “crée ceci”, on lui dit “voici l’état que je veux”, et c’est le moteur (via le state et le plan) qui détermine le diff à appliquer.
Idempotence
Une propriété qui découle directement du déclaratif : réappliquer la même configuration plusieurs fois de suite ne doit rien changer si l’infrastructure correspond déjà à l’état décrit. terraform apply sur une configuration inchangée doit annoncer “No changes.” C’est ce qui rend l’IaC fiable en CI/CD : on peut la rejouer sans craindre de dupliquer des ressources ou de casser l’existant.
Pourquoi l’IaC plutôt que le clic dans une console
C’est la deuxième partie de l’objectif de l’exam guide : “Describe advantages of IaC patterns”. Ce qui m’a personnellement convaincu, avant même de penser à une certification :
- Versioning et historique. Chaque changement d’infra passe par un commit Git, avec un auteur, une date et (idéalement) une revue de code. Impossible d’obtenir ça avec des clics dans une console.
- Collaboration. Plusieurs personnes peuvent travailler sur la même infrastructure via des pull requests, sans se marcher dessus ni se demander “qui a changé ce security group hier soir”.
- Reproductibilité. Recréer un environnement identique (staging, nouvelle région, nouveau client) devient une question de minutes, pas de jours de configuration manuelle.
- Documentation vivante. Le code Terraform décrit l’infrastructure telle qu’elle est réellement, contrairement à un wiki qui devient obsolète dès qu’on oublie de le mettre à jour.
- Réduction de l’erreur humaine. Un plan Terraform montre le diff avant application ; un clic malheureux dans une console, lui, ne prévient pas.
Ce que je retiens
Ce premier module reste conceptuel, mais il pose un vocabulaire que je retrouverai tout au long de la certification : déclaratif, idempotence, state. Le module suivant s’attaque aux providers et au state.