Patterns et modules¶

DRY vs WET, modules réutilisables, workspaces, organisation du code IaC en monorepo ou multi-repo.

DRY vs WET¶

DRY (Don't Repeat Yourself) : factoriser ce qui se répété en modules réutilisables.

WET (Write Everything Twice, ou We Enjoy Typing) : accepter la duplication quand la factorisation nuit à la clarte ou au couplage.

Quand factoriser¶

• Le même pattern apparait dans trois contextes ou plus
• Le pattern va évoluer : le modifier a un seul endroit plutôt qu'en dix
• L'abstraction a du sens semantiquement (un module vpc-standard représenté quelque chose de clair)

Quand accepter la duplication¶

• Deux ressources se ressemblent aujourd'hui mais divergeront probablement — les coupler creerait des contraintes inutiles
• La factorisation nécessité des abstractions si complexes qu'elles deviennent incomprehensibles
• L'équipe qui consomme le module est différente de l'équipe qui le maintient, avec des besoins qui evoluent independamment

Modules réutilisables¶

Design d'un bon module¶

Un bon module Terraform ou rôle Ansible à les caractéristiques suivantes :

• Interface claire : les variables d'entree sont documentees, typees et ont des valeurs par défaut sensibles
• Périmètre limite : un module fait une chose bien plutôt que tout faire
• Pas d'opinions cachees : les comportements par défaut sont explicites et surchargeable
• Testable independamment : on peut l'utiliser en isolation sans dépendances implicites

Versioning¶

graph LR
    A["Module v1.0"] --> B["Module v1.1<br/>(ajout feature)"]
    B --> C["Module v2.0<br/>(breaking change)"]
    D["Consommateur A"] -->|"~> 1.0"| B
    E["Consommateur B"] -->|"= 1.0"| A
    F["Consommateur C"] -->|"~> 2.0"| C

Utilisez le versioning semantique (semver) pour vos modules. Un breaking change dans l'interface (suppression d'une variable, changement de comportement) implique un bump de version majeure.

Registry¶

Les modules peuvent être publies sur :

• Terraform Registry public : pour les modules open source
• Terraform Registry prive (Terraform Cloud/Enterprise) : pour les modules internes
• Git avec tags : la solution la plus simple pour commencer

Workspaces et environnements¶

Les workspaces Terraform permettent de gérer plusieurs states indépendants depuis le même code.

Workspaces vs répertoires distincts¶

Pour la plupart des équipes, des répertoires distincts par environnement sont plus surs et plus lisibles que les workspaces. Les workspaces conviennent aux environnements éphémères (preview, feature branches).

Monorepo vs multi-repo¶

Structure d'un repo IaC typique¶

graph TD
    R["infra/"] --> M["modules/"]
    R --> E["environments/"]
    M --> M1["vpc/"]
    M --> M2["eks/"]
    M --> M3["rds/"]
    E --> ENV1["dev/"]
    E --> ENV2["staging/"]
    E --> ENV3["prod/"]
    ENV1 --> T1["main.tf"]
    ENV1 --> T2["variables.tf"]
    ENV1 --> T3["terraform.tfvars"]

Critères de choix¶

Recommendation pratique¶

Commencez avec un monorepo infra/ dans votre repo applicatif ou un repo dédié. Passez en multi-repo quand des équipes indépendantes ont besoin d'autonomie et que le monorepo devient un goulot d'étranglement.

Outils¶