Module 7 — Modules locaux et design du dépôt

Durée indicative du cours : 1h30
Durée indicative de l’atelier : — (atelier / cas d’étude à venir)
Durée totale (cours + atelier) : ~2h30–3h00

Objectif du module

En Basics, le module 5 sépare main / variables / outputs, et le module 7 esquisse l’idée de module.
Ici, on passe à une architecture d’équipe : critères de découpage, modules locaux, tfvars multi-env, un repo ou plusieurs.

L’objectif pédagogique n’est pas une recette unique.
C’est de savoir décider et assumer des trade-offs.

Cas d’étude — petite plateforme lab Azure

Contexte : une équipe livre une landing zone light (réseau + identité minimale) et une appli web derrière.
Problème : un seul main.tf de 800 lignes, recopié par environnement, devient ingérable.
Solution explorée : même code + tfvars, puis modules métier, puis backend distant et CI.
Fil rouge : le même dépôt évolue en trois étapes (ci-dessous).

Étape 1 — Rappel Basics : un dossier, fichiers séparés

platform/
├── versions.tf
├── providers.tf
├── main.tf
├── network.tf          # optionnel dès qu’il y a du volume
├── variables.tf
├── outputs.tf
├── locals.tf
├── terraform.tfvars.example
└── .terraform.lock.hcl

Terraform fusionne tous les .tf du dossier.
Le découpage sert aux humains.

Fichier	Contenu typique
`versions.tf`	`required_version`, `required_providers`, parfois `backend`
`providers.tf`	blocs `provider`
`main.tf` / `network.tf` / …	ressources par domaine quand le fichier grossit
`variables.tf` / `outputs.tf` / `locals.tf`	interface et dérivés

Règle de lisibilité

Un fichier = un périmètre métier clair.
Si main.tf dépasse largement ce qu’on peut relire en revue, séparez par domaine (réseau, data, compute).

Rappel : un dossier racine = un state (par workspace).

Organisation des tfvars par environnement

Question fréquente : « On met un dossier environments/dev|uat|prd avec tout le HCL ? »

Réponse courte :

Oui pour les valeurs : même code .tf + un fichier (ou petit dossier) de tfvars par env, chargé avec -var-file.
Non / prudence : recopier tout le HCL dans environments/dev/*.tf, uat/*.tf, prd/*.tf — le code drift entre envs.

Motifs recommandés (sans dogme)

# A — simple (souvent suffisant)
env/
  dev.tfvars
  uat.tfvars
  prd.tfvars

# B — plusieurs fichiers de valeurs par env (toujours sans dupliquer les .tf)
environments/
  dev/
    terraform.tfvars
  uat/
    …
  prd/
    …

terraform plan -var-file=env/prd.tfvars
terraform apply -var-file=env/prd.tfvars

Concept	Rôle
tfvars par env	Valeurs différentes (taille, noms, SKU)
Workspaces CLI / TFC	States séparés
Repo / stack séparés	Quand droits, cadence ou divergences le justifient

Secrets

Pas de secrets dans des tfvars versionnés.
Injection CI, Key Vault, variables Terraform Cloud, ou mécanismes ephemeral (module 8).

Prérequis élèves : Basics — fournir les valeurs.

Étape 2 — Modulariser : quoi extraire

Signaux qu’il est temps

Le même bloc est copié trois fois.
Deux équipes consomment le même modèle (réseau, RG, storage).
Plusieurs envs partagent la forme mais pas les valeurs.
La revue de PR devient trop lourde sur un seul fichier.

Structure type d’un module local

modules/
  network/
    main.tf
    variables.tf
    outputs.tf
    README.md
    examples/          # optionnel mais précieux

Appel depuis la racine :

module "network" {
  source = "./modules/network"

  project     = var.project
  environment = var.environment
  location    = var.location
  vnet_cidr   = var.vnet_cidr
  subnets     = var.subnets
  tags        = var.tags
}

module "app" {
  source = "./modules/app"

  subnet_id = module.network.subnet_ids["app"]
  location  = var.location
  tags      = var.tags
}

Rôle	Responsabilité
Racine orchestratrice	Compose les modules, fournit tfvars, backend, providers
Module métier	Encapsule un domaine (`network`, `compute`, `identity`) avec une interface claire

Interface du module

Variables d’entrée minimales mais typées (module 8).
Outputs stables (contrats pour les consommateurs).
Versioning si le module est partagé (tag Git, Registry) — hors focus lab local.

Anti-patterns

Module fourre-tout (« utils » qui crée tout Azure).
Vingt paramètres dont la moitié ne sert jamais.
Couplage fort via une avalanche d’outputs internes.

Aperçu Basics

Le module 7 Basics introduit source et l’esprit paramètres.
Ici, on construit et on compose.

Un repo ou plusieurs ?

Approche	Avantages	Limites
Monorepo IaC	Revue unique, cohérence, refactor transverse	Droits fins, CI, taille du dépôt
Repo par domaine	Ownership clair (réseau vs app)	Dépendances, coordination des releases
Repo par environnement	Isolation forte	Drift de code si on duplique le HCL

Ce qui vit dans le repo Terraform :

.tf, .terraform.lock.hcl, docs, exemples, tfvars sans secrets.

Ce qui reste hors repo (en général) :

state distant, secrets, parfois les pipelines (repo CI séparé).

Consommation cross-repo :

terraform_remote_state ;
outputs publiés comme contrat entre équipes ;
modules versionnés (Git tag / Registry).

À enrichir — cas d’étude bout en bout

Livrables élèves : arborescence cible, tableau « quoi va où », schéma des states, liste des trade-offs.
Étape 3 (équipe / prod) : backend distant, CI plan sur PR, apply contrôlé, ownership des states.

Étape 3 — Équipe / prod (aperçu)

Backend distant (module 5).
Même code + -var-file (ou workspace TFC) par env.
Pipeline : fmt / validate / plan sur PR ; apply protégé.
Auth CI sans secret long terme (module 4 — WIF).

Suite

Poursuivre avec le module 8 — Variables, types et validations.
Théorie suivante : interfaces de modules solides (object, optional, validations, path.*, terraform.workspace).