Terragrunt pour structurer Terraform et OpenTofu

Terragrunt devient utile quand vos projets Terraform ou OpenTofu restent lisibles a l'échelle d'un module, mais commencent a devenir repetitifs a l'échelle d'un repo complet. Si vous dupliquez les mêmes conventions entre dev, staging et prod, si vous recopiez le backend partout, ou si vous ne savez plus comment lancer proprement plusieurs composants ensemble, Terragrunt est la couche qui remet de l'ordre.

Ce que vous allez apprendre

• Ce qu'est Terragrunt et ce qu'il ne remplace pas
• Le vocabulaire minimal pour suivre les guides pratiques sans vous perdre
• Comment Terragrunt fonctionne, etape par etape, au-dessus de Terraform ou OpenTofu
• Dans quel ordre lire les guides de cette section pour progresser efficacement

Terragrunt en une phrase

Terragrunt est une couche d'organisation au-dessus de Terraform ou OpenTofu. Il ne remplace ni le langage HCL, ni les providers, ni les resources. Il sert surtout a instancier vos modules, centraliser des règles communes et orchestrer plusieurs dossiers deployables.

Le problème qu'il résout

Sans Terragrunt, un repo d'infrastructure grossit souvent de cette façon :

• le même backend est recopie dans plusieurs dossiers ;
• les mêmes variables reviennent dans tous les environnements ;
• l'ordre entre composants devient flou ;
• un pipeline declenche trop large, faute de ciblage propre ;
• le repo reste exécutable, mais il devient pénible a maintenir.

Terragrunt apporte une réponse structurelle a ces problèmes. Il permet de garder les modules d'un côté, les instances concrètes de l'autre, et les règles communes a un niveau central.

Vocabulaire minimal

Si vous retenez mal le vocabulaire, les guides deviennent vite abstraits. Voici les definitions a garder en tête pour toute la section.

Terme	Ce que c'est	Concrètement
module	Le code Terraform ou OpenTofu reutilisable	Le dossier qui contient les resources, variables et outputs
unit	Un dossier deployable pilote par terragrunt.hcl	Une instance concrète d'un module avec ses propres valeurs
live repo	L'arborescence qui regroupe les units	Souvent rangee par environnement, compte, region ou application
include	Un mecanisme d'heritage Terragrunt	Une unit relit des conventions définies plus haut
root.hcl	Le fichier racine des règles partagées	Backend, generate, locals communs, conventions globales
run queue	La file d'exécution calculée par Terragrunt	L'ordre réel dans lequel les units vont être traitées
stack	Un groupe de units gérées ensemble	Implicite par l'arborescence ou explicite avec terragrunt.stack.hcl

Glissez pour voir

Le mot le plus important : unit

Un unit n'est pas un nouveau type de ressource. C'est simplement un dossier deployable qui contient un fichier terragrunt.hcl. Ce fichier indique quel module utiliser et avec quelles valeurs l'exécuter.

Comment Terragrunt fonctionne

Le modèle mental le plus simple est le suivant :

1. Vous écrivez un module Terraform

   Le module contient la logique Terraform ou OpenTofu reutilisable.

2. Vous créez une unit avec terragrunt.hcl

   Cette unit ne réécrit pas les resources. Elle choisit le module et fournit les valeurs d'entrée.

3. Terragrunt ajoute les règles communes

   Via include, root.hcl, remote_state ou generate, Terragrunt injecte ce qui doit être partage entre plusieurs units.

4. Terragrunt lance ensuite Terraform ou OpenTofu

   L'engine IaC fait le vrai travail de plan, apply et destroy.

En pratique, il faut retenir cette séparation des roles :

• Terraform ou OpenTofu décrivent et exécutent l'infrastructure ;
• Terragrunt organise comment cette infrastructure est instanciee et pilotée dans le repo.

Schema simple d'un live repo

Voici un exemple minimal pour visualiser ou se place Terragrunt :

• Répertoirelive/

  • root.hcl
  • Répertoire_env/

    • app.hcl
  • Répertoiredev/

    • Répertoireapp/

      • terragrunt.hcl
    • Répertoireworker/

      • terragrunt.hcl
• Répertoiremodules/

  • Répertoireapp/

    • main.tf
    • variables.tf
    • outputs.tf

Comment lire cette arborescence :

• modules/ contient la logique reutilisable ;
• live/ contient les units réelles a exécuter ;
• root.hcl porte les conventions communes ;
• _env/ factorise des réglages partages par famille de units ;
• chaque dossier comme dev/app est une unit concrète.

Quand Terragrunt vaut l'effort

Terragrunt commence a être rentable quand au moins un de ces problèmes apparaît :

Situation	Ce qui fait mal sans Terragrunt	Ce que Terragrunt apporte
Plusieurs environnements proches	Duplication entre dev, staging et prod	include, root.hcl et structure de live repo
Plusieurs composants dependants	Ordre de plan ou apply fragile	dependency, mock_outputs et run queue
Backend ou provider repetes partout	Fichiers presque identiques dans chaque dossier	remote_state et generate
Pipeline trop large	Trop de composants touches a chaque run	run --all et --filter

Glissez pour voir

Quand il est trop tot

Terragrunt n'est pas automatiquement un progrès. Il est souvent trop tot si :

• vous apprenez encore les bases de Terraform ;
• vous avez seulement un ou deux dossiers très simples ;
• vous ne dupliquez pas encore de logique ;
• votre vrai problème est d'abord la qualité des modules.

Dans ce cas, il vaut mieux stabiliser vos bases sur Terraform ou OpenTofu avant d'ajouter une couche d'orchestration.

A retenir

• Terragrunt n'est pas un remplacement de Terraform ou OpenTofu.
• Son vrai role est d'organiser un live repo, de centraliser des conventions et de piloter plusieurs units.
• Le mot unit désigne simplement un dossier deployable contenant un terragrunt.hcl.
• Si vous avez encore peu de duplication, il est souvent trop tot pour l'adopter.
• Si votre repo devient répétitif et difficile a orchestrer, il devient très vite rentable.

Prochaine étape

Installer Terragrunt Commencer ici pour installer Terragrunt avec mise et vérifier que la commande fonctionne avant le premier guide pratique.

×

📖 Voir la documentation →