Terraform : créer des modules avec variables et outputs

Un module n’est pertinent que s’il encapsule une responsabilité reproductible avec un contrat d’entrée et de sortie stable.

1. Utiliser un petit exemple de convention de nommage pour apprendre l’interface, sans le présenter comme un module cloud complet.
2. Créer les répertoires du module et du projet racine.
3. Prévoir main.tf, variables.tf, outputs.tf et un README dans le module.

mkdir -p terraform-modules-lab/modules/naming
cd terraform-modules-lab
find . -maxdepth 3 -type d

Une interface explicite évite de mélanger valeurs de configuration, secrets et conventions implicites.

1. Dans modules/naming/variables.tf, déclarer le service et l’environnement.
2. Refuser les valeurs vides pour le service.
3. Documenter le sens de chaque entrée dans le README du module.

# modules/naming/variables.tf
variable "service" {
  description = "Nom court du service"
  type        = string
  validation {
    condition     = length(trimspace(var.service)) > 0
    error_message = "Le nom du service est obligatoire."
  }
}
variable "environment" {
  description = "Environnement cible"
  type        = string
}

Le corps du module calcule une valeur et expose uniquement ce que le consommateur doit connaître.

1. Créer le fichier main.tf de ce module enfant avec un local et une ressource de laboratoire.
2. Créer outputs.tf pour retourner le résultat.
3. Conserver la configuration des providers dans le module racine dans les projets cloud réels.

# modules/naming/main.tf
locals {
  fullname = "${var.service}-${var.environment}"
}
resource "terraform_data" "identity" {
  input = local.fullname
}

# modules/naming/outputs.tf
output "fullname" {
  description = "Nom du service contextualisé"
  value       = terraform_data.identity.output
}

La racine choisit les paramètres et peut composer plusieurs modules sans exposer leurs ressources internes.

1. Créer main.tf à la racine et utiliser une source locale relative.
2. Récupérer module.naming.fullname dans un output racine.
3. Ne pas ajouter un attribut version : il n’est pas applicable à une source de module locale.

# main.tf (racine)
terraform {
  required_version = ">= 1.5.0, < 2.0.0"
}
module "naming" {
  source      = "./modules/naming"
  service     = "api"
  environment = "recette"
}
output "service_name" {
  value = module.naming.fullname
}

Un module utile doit être vérifié à partir de son appelant, pas simplement parce que ses fichiers existent.

1. Exécuter les contrôles depuis le répertoire racine ; lire le plan.
2. Appliquer uniquement ce laboratoire, puis vérifier l’output API attendu.
3. Changer environment en integration et relire le nouveau plan avant toute application.

terraform init
terraform fmt -recursive
terraform validate
terraform plan
terraform apply
terraform output service_name

La réutilisation en équipe repose sur la documentation, les versions et une revue des breaking changes.

1. Ajouter un README présentant objectif, inputs, outputs, exemples et limites.
2. Définir la politique de version pour un registre de modules ; épingler une version validée côté appelant.
3. Éviter les arbres de modules profondément imbriqués et tester les sorties à chaque évolution.

# Exemple de source de registre à adapter :
# module "reseau" {
#   source  = "organisation/reseau/aws"
#   version = "1.2.3"
# }