Terragrunt : dependances et mock

Comment faire quand une unit Terragrunt a besoin de la sortie d’une autre unit qui n’a pas encore ete appliquee ? C’est le probleme classique du premier plan multi-units. Le bloc dependency et l’option mock_outputs servent justement a gerer ce cas sans perdre le benefice 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 necessaire pour debloquer un premier plan
Lancer un plan puis un apply multi-units en ordre
Verifier que le resultat final utilise bien les vraies sorties, pas les mocks

Le vocabulaire des dependances

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 etapes. L’etape 2 a besoin de connaitre la hauteur exacte produite par l’etape 1. Tant que l’etape 1 n’est pas terminee, vous pouvez quand meme planifier l’etape 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 reel.

Structure minimale du projet

Pour reproduire ce scenario, creez 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 recuperer ses outputs ;
mock_outputs fournit une valeur temporaire quand les outputs reels 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’etat applique. Il n’existe donc pas encore d’outputs reels a lire. Terragrunt sait bien ordonner les units, mais il ne peut pas inventer une valeur qui n’a jamais ete materialisee.

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

Pourquoi limiter les mocks a plan

Dans le pattern recommande, les mocks sont autorises 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 evite de laisser trainer des valeurs fictives dans une phase ou la creation reelle des ressources est en train de se produire.

Etapes 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 reels, mais utilise les mock_outputs pour permettre au plan de continuer.
Lancer terragrunt run --all apply

Verification : l’unit upstream est appliquee avant l’unit downstream.
Verifier 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 cle est que le contenu final de downstream.txt ne reprend pas la valeur mockee. Il reprend bien la vraie sortie de l’upstream apres 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 frequentes

Symptome	Cause probable	Solution
Le `plan` casse avant le premier apply	Aucun output reel encore disponible	Ajouter `mock_outputs` sur la dependency
Le `apply` continue avec une fausse valeur	Les mocks restent autorises trop largement	Limiter `mock_outputs_allowed_terraform_commands` a `plan`
Mauvais ordre d’execution	`config_path` faux ou relation mal definie	Verifier le chemin et la vraie dependance logique

A retenir

Le bloc dependency sert a lire les outputs d’une autre unit.
mock_outputs sert surtout a debloquer un premier plan multi-units.
Il vaut mieux limiter les mocks a plan et utiliser les vrais outputs en apply.
Le resultat final doit etre 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'execution.