Projet : industrialiser le dépôt signalements-iac
Ce projet clôt le cours Terraform avancé : modules, tests, état. Le niveau 300 (Concevoir) se valide par un livrable que relit une autre personne avec la grille ci-dessous, et non par un script : les choix de découpage et d'interface n'ont pas une seule bonne réponse, mais ils doivent être justifiés. Comptez deux jours de travail, puis une heure et demie de revue.
Le point de départ
Le dépôt signalements-iac du lab du premier cours, appliqué en préproduction : un seul répertoire, un état par environnement, toute l'architecture de Signalements dans une vingtaine de ressources.
Ce qu'il faut livrer
- Un dépôt de modules (
lyneko-modulesou un répertoiremodules/versionné à part) contenant au moins trois modules : réseau, base de données, application. Chacun a une interface typée et validée, des sorties documentées, unREADME, un exemple, et au moins deux teststerraform test(un en plan, un avec un fournisseur simulé). Les modules sont publiés avec des étiquettes Git suivant le versionnement sémantique. - Un dépôt de composition qui appelle ces modules par version épinglée, découpé en couches (réseau, données, application) et en environnements (préproduction, production), avec un état distant et verrouillé par couche et par environnement.
- Une refactorisation sans destruction : la migration de l'état existant vers la nouvelle organisation, avec des blocs
moved,removedetimport. La préproduction déjà appliquée doit passer à la nouvelle structure sans qu'aucune ressource ne soit détruite ni recréée ; joignez les plans qui le prouvent. - Des politiques vérifiées en CI : au moins trois règles écrites en Rego (ou avec un autre outil justifié) et vérifiées sur le plan JSON, dont une sur les étiquettes obligatoires et une sur l'absence d'exposition publique de la base.
- Aucun secret dans l'état ni dans les plans : mots de passe éphémères et arguments en écriture seule, secrets rangés dans Secret Manager.
- Un document de conception de trois pages au plus : le découpage retenu et les options écartées, l'interface de chaque module, la stratégie de version et de mise à jour, le procédé de refactorisation, et ce qui reste à faire.
La revue
La personne qui relit dispose d'une heure et demie, du dépôt et des plans joints. Elle note chaque critère de 0 à 2 (0 : absent ou faux ; 1 : présent mais incomplet ou non justifié ; 2 : complet et justifié), puis échange avec l'auteur sur les points à 0 et 1.
| Critère | Ce que la relecture vérifie |
|---|---|
| Interfaces | Chaque module expose peu de variables, typées, validées, avec des valeurs par défaut raisonnables ; aucun bloc provider dans un module réutilisable |
| Découpage | Les couches correspondent à des rythmes de changement et des droits différents ; le document justifie le découpage et les options écartées |
| Passage entre couches | Les informations circulent par des sources de données ou des sorties explicites, sans lire l'état complet d'une autre couche sans raison |
| Versions | Les modules sont appelés par une version épinglée ; les changements cassants sont signalés par la version majeure et une note |
| Tests | Les tests vérifient un comportement (validation, sortie calculée, absence d'exposition), pas seulement que le code s'exécute ; ils tournent en CI |
| Politiques | Les règles sont exécutées sur le plan, échouent réellement sur un contre-exemple fourni, et leurs messages disent quoi corriger |
| Secrets | Aucune valeur secrète dans l'état ni dans un plan enregistré ; la relecture le vérifie sur l'état de préproduction |
| Refactorisation | Les plans de migration ne contiennent aucune destruction ; les blocs moved et removed sont gardés jusqu'à ce que tous les états soient migrés |
| Mises à jour | Le document décrit comment un nouveau fournisseur ou une nouvelle version d'un module passe de la préproduction à la production |
| Lisibilité | Une personne qui découvre le dépôt sait, en lisant le README et le document, où modifier quoi et dans quel ordre appliquer |
Le niveau 300 est validé à 15 points sur 20, sans aucun 0 sur Secrets, Refactorisation et Découpage.
Conseils
- Faites la refactorisation avant d'ajouter des fonctionnalités : un plan de migration vide de toute destruction est beaucoup plus facile à obtenir quand rien d'autre ne change en même temps.
- Écrivez les tests d'un module en même temps que son interface : ils montrent vite une variable inutile ou un nom ambigu.
- Gardez une branche par étape (modules, couches, migration, politiques) : la revue n'en sera que plus simple.