Terragrunt : dépendances et mock

Comment faire quand une unit Terragrunt a besoin de la sortie d'une autre unit qui n'a pas encore été appliquée ? C'est le problème classique du premier plan multi-units. Le bloc dependency et l'option mock_outputs servent justement a gérer ce cas sans perdre le bénéfice d'un run multi-units.

Dans ce guide, on part d'un exemple concret avec deux units : une unit amont qui produit une sortie, puis une unit aval qui la consomme.

Ce que vous allez apprendre

Comprendre le role du bloc dependency pour lire les outputs d'une autre unit
Savoir quand mock_outputs devient nécessaire pour débloquer un premier plan
Lancer un plan puis un apply multi-units en ordre
Vérifier que le résultat final utilise bien les vraies sorties, pas les mocks

Le vocabulaire des dépendances

Avant de passer a la pratique, quatre termes reviennent dans tout ce guide :

Terme	Role
upstream	La unit amont qui produit une sortie
downstream	La unit aval qui consomme cette sortie
`dependency`	Le bloc Terragrunt qui permet de lire les outputs d'une autre unit
`mock_outputs`	Une valeur provisoire fournie pour laisser passer un premier `plan`

Imaginez que vous montez un meuble en deux étapes. L'étape 2 a besoin de connaître la hauteur exacte produite par l'étape 1. Tant que l'étape 1 n'est pas terminée, vous pouvez quand même planifier l'étape 2 avec une dimension approximative. C'est exactement le role de mock_outputs : donner une valeur provisoire pour avancer dans le plan, puis utiliser la vraie mesure au moment du montage réel.

Structure minimale du projet

Pour reproduire ce scenario, créez cette arborescence :

Répertoirelab-c/
- Répertoiremodules/
  - Répertoirewrite-file/
    main.tf
- Répertoirelive/
  - Répertoiredev/
    Répertoireupstream/
    terragrunt.hcl
    Répertoiredownstream/
    terragrunt.hcl

Le module reutilisable

Placez le module suivant dans modules/write-file/main.tf :

terraform {
  required_version = ">= 1.6.0"

  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.5"
    }
  }
}

variable "filename" {
  type = string
}

variable "content" {
  type = string
}

resource "local_file" "this" {
  filename = var.filename
  content  = var.content
}

output "file_path" {
  value = local_file.this.filename
}

output "content" {
  value = local_file.this.content
}

Les deux fichiers Terragrunt

Fichier live/dev/upstream/terragrunt.hcl :

terraform {
  source = "../../../modules/write-file"
}

inputs = {
  filename = "${get_terragrunt_dir()}/upstream.txt"
  content  = "hello from upstream"
}

Le bloc dependency

La unit downstream utilise ce pattern :

terraform {
  source = "../../../modules/write-file"
}

dependency "upstream" {
  config_path = "../upstream"
  mock_outputs = {
    content = "mocked upstream"
  }
  mock_outputs_allowed_terraform_commands = ["plan"]
}

inputs = {
  filename = "${get_terragrunt_dir()}/downstream.txt"
  content  = "downstream reads: ${dependency.upstream.outputs.content}"
}

Copiez ce second bloc dans live/dev/downstream/terragrunt.hcl.

Le raisonnement est simple :

config_path indique quelle unit lire ;
dependency.upstream.outputs... permet de récupérer ses outputs ;
mock_outputs fournit une valeur temporaire quand les outputs réels ne sont pas encore disponibles.

Pourquoi `plan` bloque sans mock_outputs

Lors d'un premier run --all plan, l'unit amont n'a pas encore d'état applique. Il n'existe donc pas encore d'outputs réels a lire. Terragrunt sait bien ordonner les units, mais il ne peut pas inventer une valeur qui n'a jamais été materialisee.

Le bloc mock_outputs donne alors une valeur de substitution pour laisser le plan avancer. C'est utile pour vérifier la structure globale avant le premier apply complet.

Pourquoi limiter les mocks a plan

Dans le pattern recommande, les mocks sont autorisés seulement ici :

mock_outputs_allowed_terraform_commands = ["plan"]

Cette restriction est importante. Elle dit explicitement :

pendant plan, une valeur de simulation est acceptable ;
pendant apply, on veut les vrais outputs de l'upstream.

Cette discipline évite de laisser trainer des valeurs fictives dans une phase ou la création réelle des ressources est en train de se produire.

Étapes pour reproduire

Voici la sequence a suivre :

Lancer terragrunt run --all plan

Verification : Terragrunt annonce bien que l'upstream n'a pas encore d'outputs réels, mais utilise les mock_outputs pour permettre au plan de continuer.
Lancer terragrunt run --all apply

Verification : l'unit upstream est appliquée avant l'unit downstream.
Vérifier les fichiers produits

Deux fichiers doivent exister :
- upstream.txt avec hello from upstream
- downstream.txt avec downstream reads: hello from upstream
Lancer terragrunt run --all destroy

Verification : les deux units sont detruites proprement ensuite.

Le point clé est que le contenu final de downstream.txt ne reprend pas la valeur mockee. Il reprend bien la vraie sortie de l'upstream après apply.

Dependency ou dependencies ?

Il faut bien distinguer deux blocs Terragrunt souvent confondus :

Bloc	Role
`dependency`	Lit des outputs d'une autre unit
`dependencies`	Indique seulement un ordre entre units, sans lecture d'outputs

Si vous avez besoin de consommer une sortie, utilisez dependency. Si vous ne voulez qu'imposer un ordre global, dependencies suffit souvent.

Erreurs fréquentes

Symptôme	Cause probable	Solution
Le `plan` casse avant le premier apply	Aucun output réel encore disponible	Ajouter `mock_outputs` sur la dependency
Le `apply` continue avec une fausse valeur	Les mocks restent autorisés trop largement	Limiter `mock_outputs_allowed_terraform_commands` a `plan`
Mauvais ordre d'exécution	`config_path` faux ou relation mal définie	Vérifier le chemin et la vraie dépendance logique

A retenir

Le bloc dependency sert a lire les outputs d'une autre unit.
mock_outputs sert surtout a débloquer un premier plan multi-units.
Il vaut mieux limiter les mocks a plan et utiliser les vrais outputs en apply.
Le résultat final doit être verifie avec une sortie observable, pas seulement avec le log.
Terragrunt sait ordonner les units, mais il a besoin d'aide quand les outputs n'existent pas encore.

Prochaine etape

Run queue et filtres Voir ensuite comment Terragrunt cible plusieurs units et construit sa file d'exécution.