Terraform avancé : modules, tests, état
Ce cours prolonge Terraform et OpenTofu : les fondamentaux. À la fin du premier cours, le dépôt signalements-iac décrit toute l'infrastructure de Signalements dans un seul répertoire, avec un fichier de valeurs par environnement. C'est suffisant pour une application et une équipe. Ce cours traite de ce qui arrive ensuite : une deuxième application, une deuxième équipe, des dizaines de ressources de plus, et des années de maintenance.
L'approche
Le cours part du dépôt du premier cours et le fait évoluer, leçon après leçon : extraction de modules, publication avec des versions, composition en couches (réseau, données, application), tests automatisés, politiques vérifiées sur les plans, découpage de l'état, puis mises à jour. Chaque leçon s'appuie sur la documentation de Terraform et d'OpenTofu, et signale les différences entre les deux outils.
Comme dans le premier cours, les démonstrations qui ne créent rien dans le cloud ont été exécutées avec Terraform 1.16, et les sorties montrées sont réelles ; ce qui touche Scaleway est validé contre le schéma du fournisseur, sans sortie inventée.
Il est de niveau 300 (Concevoir) : les leçons présentent des arbitrages plus que des recettes, et le cours se valide par un projet relu par un pair.
Ce qu'il faut
- Le dépôt
signalements-iacdu lab du premier cours, ou l'envie de le reconstruire. - Terraform 1.16 ou OpenTofu 1.11 ou plus récent, Git, et un compte Scaleway pour les leçons qui appliquent.
Les leçons
- Les modules : pourquoi et comment
- Concevoir l'interface d'un module
- Sources, versions et registres de modules
- Composer une infrastructure en couches
- Tester avec terraform test
- Validations, vérifications et politiques
- Les secrets hors de l'état
- Découper et refactoriser les états
- Orchestrer plusieurs états
- Mettre à jour sans casser
Pour valider : le quiz et le projet relu par un pair (niveau 300).
Plan du cours
- Les modules : pourquoi et comment
300 Concevoir
Regrouper des ressources en un module réutilisable : module racine et modules enfants, bloc module, entrées et sorties, ce qu'un module cache. Extraction du réseau de Signalements dans un module local, adresses d'état et bloc moved pour ne rien recréer, et les cas où ne pas faire de module. - Concevoir l'interface d'un module
300 Concevoir
Une interface de module étroite, typée et validée : objets avec optional() et valeurs par défaut, nullable, validations, sorties utiles, dépréciation, absence de bloc provider, count et for_each sur un module, documentation et structure de répertoire standard. Appliqué au module réseau de Signalements. - Sources, versions et registres de modules
300 Concevoir
Où vivent les modules et comment les versionner : sources locales, Git (ref, tag, empreinte de commit), registre public et privé, versionnement sémantique appliqué à l'infrastructure, changements cassants, évaluation des modules publics comme risque de chaîne d'approvisionnement, et cache de .terraform/modules. - Composer une infrastructure en couches
300 Concevoir
Découper une infrastructure en couches (réseau, données, application) qui ont chacune leur état et leur cycle de vie, et la répéter par environnement : transmission d'informations entre couches (sources de données, terraform_remote_state, sorties publiées), arborescence du dépôt, duplication ou factorisation, et arbitrages de rayon d'impact. - Tester avec terraform test
300 Concevoir
Tester un module Terraform ou OpenTofu : fichiers .tftest.hcl, blocs run en plan et en apply, assertions, variables, expect_failures, fournisseurs simulés (mock_provider) et override_resource, tests unitaires et d'intégration, nettoyage, tofu test, et place des tests dans la chaîne d'intégration continue. - Validations, vérifications et politiques
300 Concevoir
Poser des garde-fous à chaque étage : validations de variables, preconditions et postconditions, blocs check pour les contrôles continus, puis politique as code sur le plan JSON avec OPA, Rego et conftest. Avec la structure réelle de resource_changes, une politique « pas de bucket public, étiquettes obligatoires » pour Signalements, et la place de chaque contrôle dans le pipeline. - Les secrets hors de l'état
300 Concevoir
Empêcher les mots de passe et les jetons d'entrer dans l'état et dans les plans : variables, sorties et ressources éphémères, arguments en écriture seule (password_wo, data_wo) et leurs versions, lecture d'un secret depuis Secret Manager sans l'enregistrer, génération côté fournisseur, chiffrement de l'état avec OpenTofu, rotation. Avec des démonstrations réelles de ce qui apparaît, ou non, dans l'état. - Découper et refactoriser les états
300 Concevoir
Savoir quand un état est devenu trop gros, et comment le découper ou le réorganiser sans rien détruire : blocs moved (dans un état), état déplacé par state mv -state-out, blocs removed et import (entre états), garde-fous avec un plan vide attendu. Avec une démonstration réelle sur deux états locaux et la séparation de Signalements en couches. - Orchestrer plusieurs états
300 Concevoir
Quand l'infrastructure est découpée en plusieurs états, il faut une chose qui sache dans quel ordre appliquer, comment passer les sorties d'une couche à l'autre et comment ne pas répéter le backend partout. Scripts et Make, Terragrunt, Terramate, Stacks de HCP Terraform, Atlantis, fonctionnalités d'OpenTofu (variables dans le backend), et critères pour choisir. - Mettre à jour sans casser
300 Concevoir
Faire vivre une infrastructure as code pendant des années : épingler et mettre à jour Terraform et OpenTofu (required_version, gestionnaires de versions), les fournisseurs (fichier de verrou, init -upgrade, notes de version, changements de schéma), les modules ; automatiser avec Renovate et Dependabot ; migrer de Terraform vers OpenTofu et revenir ; dérouler une mise à jour progressive de la préproduction à la production.