Tu veux « faire du Terraform » vite. Pas écrire 800 lignes de HCL, pas te battre avec le state à 2 h du matin, pas découvrir trop tard que tu as tout recréé par erreur. Juste des patterns simples, répétables, qui évitent les bourdes classiques.
Je te propose 5 patterns que j’utilise quand je dois livrer vite et propre. Pas parfait, mais sûr. Et franchement, quand tu débutes, c’est exactement ce qu’il te faut.
1) Un module racine minimal, un dossier par environnement
Le piège numéro 1, c’est de tout mélanger. Un seul dossier, des variables « au cas où », et un jour tu applies sur prod avec les valeurs de dev. Oui, ça arrive.
Structure simple :
text infra/ modules/ vpc/ compute/ envs/ dev/ main.tf backend.tf versions.tf terraform.tfvars prod/ main.tf backend.tf versions.tf terraform.tfvars
Idée clé : envs/dev et envs/prod ne contiennent presque rien, juste l’assemblage. Les vraies ressources réutilisables vivent dans modules/.
Dans le module racine (ex. envs/dev/main.tf) tu fais juste :
hcl module "vpc" { source = "../../modules/vpc" cidr = var.vpc_cidr }
Résultat : tu limites le blast radius. Un apply = un environnement. Déjà, tu dors mieux.
2) Un backend distant dès le début, avec verrouillage
Le state local, c’est bien pour 20 minutes. Ensuite c’est un risque. Surtout si tu bosses sur plusieurs machines, ou en équipe, ou juste avec un futur toi un peu distrait.
Pattern : backend distant + lock.
Exemples courants :
- AWS : S3 + DynamoDB (locking)
- Azure : Storage Account (locking natif)
- GCP : GCS (locking via mécanismes côté GCP, selon intégration)
Le point important : le state doit être partagé et verrouillé. Et versionné côté stockage si possible. Tu n’as pas besoin d’être un expert SRE pour ça, juste d’être prudent.
Et tant qu’on y est : sépare le state par environnement. Un state dev, un state prod. Pas négociable.
3) Variables typées + validations, pour éviter les valeurs débiles
Quand tu vas vite, tu passes des variables vite. Et c’est là que tu te tires une balle dans le pied.
Pattern : types + validation.
hcl variable "env" { type = string description = "Nom de l'environnement" validation { condition = contains(["dev", "prod"], var.env) error_message = "env doit être dev ou prod." } }
variable "instance_count" { type = number description = "Nombre d'instances" validation { condition = var.instance_count >= 1 && var.instance_count <= 10 error_message = "instance_count doit être entre 1 et 10." } }
C’est bête, mais ça bloque 80 % des erreurs humaines. Et ce pattern, tu le réutilises partout.
Astuce : évite de surcharger avec 50 variables. Commence petit, ajoute seulement quand tu en as vraiment besoin.
4) Nommage et tags constants, via locals
Le chaos, c’est quand chaque ressource a un nom différent selon l’humeur, et que les tags sont oubliés une fois sur deux. Après tu fais du cost tracking à la main. L’enfer.
Pattern : locals pour standardiser nommage + tags.
hcl locals { name_prefix = "${var.project}-${var.env}" common_tags = { project = var.project env = var.env owner = var.owner } }
Puis tu l’utilises partout :
hcl resource "aws_instance" "app" { ami = var.ami_id instance_type = var.instance_type tags = merge(local.common_tags, { name = "${local.name_prefix}-app" }) }
Le gain est énorme. Lisibilité. Recherches plus faciles. Et tu évites les ressources « orphelines ».
5) Plan reproductible en CI, et apply seulement sur validation
Même en solo, prends l’habitude : plan d’abord, apply ensuite. Et idéalement, tu stockes le plan.
Pattern simple :
terraform fmt -checkterraform validateterraform plan -out=tfplan- revue rapide
terraform apply tfplan
Pourquoi -out ? Parce que tu applies exactement ce que tu as planifié. Pas « un plan recalculé » après un petit changement ou une variable qui bouge.
En CI, tu peux faire :
- sur PR : fmt, validate, plan (commenté dans la PR)
- sur merge : apply (manuel ou protégé)
Ce pattern, c’est la différence entre « je teste en prod » et « je contrôle ce que je déploie ».
Mini check-list rapide (celle que je garde sous la main)
- Un dossier par environnement
- Backend distant + locking
- Variables typées + validations
localspour tags et conventions- Plan en CI, apply contrôlé
Si tu veux, je peux publier une version « starter kit » avec cette structure prête à cloner sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com), avec un exemple concret AWS ou Azure. Dis-moi juste ta cible, et ton niveau de tolérance au « minimal mais propre ».
Et oui, Terraform c’est un outil. Mais ces 5 patterns, c’est la ceinture de sécurité.
Questions fréquemment posées
Pourquoi est-il important d'avoir un module racine minimal et un dossier par environnement dans Terraform ?
Avoir un module racine minimal et un dossier distinct par environnement (comme dev et prod) permet de ne pas mélanger les configurations, évitant ainsi des erreurs comme appliquer des variables de dev en production. Cette structure simplifie la gestion, limite le 'blast radius' des erreurs et facilite le déploiement sécurisé par environnement.
Quels sont les avantages d'utiliser un backend distant avec verrouillage dès le début ?
Utiliser un backend distant avec verrouillage garantit que l'état Terraform est partagé, sécurisé, versionné et protégé contre les modifications concurrentes. Cela évite les conflits, surtout en équipe ou sur plusieurs machines, et assure une meilleure fiabilité du déploiement. Chaque environnement doit avoir son propre state séparé pour éviter les interférences.
Comment les variables typées avec validations aident-elles à prévenir les erreurs dans Terraform ?
Définir des variables avec des types précis et des règles de validation bloque l'entrée de valeurs incorrectes ou incohérentes avant l'exécution. Par exemple, limiter une variable 'env' aux valeurs 'dev' ou 'prod' évite des erreurs humaines fréquentes et améliore la robustesse du code Terraform.
Pourquoi utiliser des locals pour standardiser le nommage et les tags dans Terraform ?
Les locals permettent de centraliser la définition des préfixes de noms et des tags communs, assurant une cohérence dans toute l'infrastructure. Cela facilite la lisibilité, la recherche de ressources, le suivi des coûts et évite la création de ressources orphelines dues à un nommage incohérent ou à l'oubli de tags.
Quelle est la bonne pratique recommandée pour exécuter Terraform en intégration continue (CI) ?
La bonne pratique est d'effectuer d'abord un 'terraform fmt -check' pour vérifier le format, puis 'terraform validate' pour valider la configuration, suivi d'un 'terraform plan' stocké. L'application ('apply') ne doit être réalisée qu'après validation manuelle ou automatisée du plan afin d'éviter des changements imprévus.
Comment ces 5 patterns simplifient-ils l'utilisation rapide et sûre de Terraform ?
Ces patterns fournissent une approche simple, répétable et sécurisée : structuration claire par environnement, gestion fiable du state avec backend distant verrouillé, contrôle strict des variables via types et validations, standardisation du nommage/tags via locals, et processus CI rigoureux avec planification avant application. Cela réduit significativement les erreurs classiques tout en permettant une livraison rapide et propre.
0 Commentaires