Terraform — Modules et variables
| Fiche express | |
|---|---|
| Type | Structuration réutilisable du code Terraform |
| Éléments | variables, locals, outputs, modules |
| Priorité variables | défaut → tfvars → TF_VAR_* → -var CLI |
| Bonne pratique clé | épingler la version des modules réutilisables |
| Voir aussi | Terraform — Concepts fondamentaux · Terraform — Providers on-prem · Glossaire cloud-native |
Cette page traite de la structuration réutilisable du code Terraform : modules, variables, outputs, locals, et versionnement.
Variables
Les variables paramètrent la configuration (entrées).
variable "node_count" {
type = number
default = 3
description = "Nombre de nœuds RKE2"
validation {
condition = var.node_count >= 1
error_message = "Au moins un nœud requis."
}
}
variable "vcenter_password" {
type = string
sensitive = true # masqué dans les logs / plan
}
Sources d'affectation (par ordre de priorité croissante) : valeur par défaut → fichier terraform.tfvars / *.auto.tfvars → variable d'environnement TF_VAR_* → option -var en CLI.
Types : primitifs (string, number, bool), collections (list, set, map), structurés (object, tuple).
Locals
Valeurs calculées internes, factorisées (pas d'entrée externe) :
locals {
common_tags = {
projet = "forge-v2"
gere_par = "terraform"
}
}
Outputs
Valeurs exposées après apply (sorties), consommables par un autre module ou affichées :
output "kubeconfig" {
value = rancher2_cluster.rke2.kube_config
sensitive = true
}
Modules
Un module est un répertoire contenant des fichiers .tf. Tout projet a un root module. On y appelle des child modules pour factoriser un motif réutilisable (ex. « un cluster RKE2 »).
<mermaid> flowchart TD
R[Root module
main.tf] --> N[module network] R --> C[module rke2_cluster] C --> V[module vm x3] N -->|outputs| C
</mermaid>
module "rke2_cluster" {
source = "./modules/rke2"
node_count = 3
network_id = module.network.id
}
Sources de module
- Chemin local :
./modules/rke2 - Registre public / privé :
registry.terraform.io/...ou registre GitLab - Git :
git::https://gitlab.example/infra/rke2.git//module?ref=v1.2.0
Toujours épingler une version (ref/version) pour la reproductibilité.
Bonnes pratiques
- Un module doit avoir une responsabilité unique et une interface claire (variables en entrée, outputs en sortie).
- Ne pas sur-abstraire : un module qui n'est instancié qu'une fois est souvent du bruit.
- Versionner les modules réutilisables comme du code applicatif (tags sémantiques).
- Documenter variables et outputs (le champ
descriptionalimenteterraform-docs).