Terragrunt : run --all, run queue et filtres

Vous avez plusieurs units dans votre repo et vous ne voulez pas tout appliquer a chaque changement ? Terragrunt propose justement run --all pour piloter plusieurs units et --filter pour n’en cibler qu’un sous-ensemble. Ce guide vous apprend a lire la run queue et a maitriser le perimetre de chaque execution.

Ce que vous allez apprendre

Comprendre le role de run --all et de la run queue
Savoir cibler une unit precise avec --filter
Verifier qu’un run cible n’impacte pas les autres units
Passer d’un run localise a un run plus large en toute confiance

Qu’est-ce que la run queue ?

La run queue est la file d’execution que Terragrunt construit avant de lancer les units. Elle s’appuie sur l’arborescence courante et, si besoin, sur les dependances declarees entre units.

Concretement, Terragrunt determine :

quelles units sont concernees ;
dans quel ordre elles doivent passer ;
lesquelles peuvent etre traitees en parallele.

L’exemple utilise

Cet exemple utilise deux units sans dependances : service-a et service-b.

Répertoirelab-e/
- Répertoiremodules/
  - Répertoirewrite-file/
    main.tf
- Répertoirelive/
  - Répertoiredev/
    Répertoireservice-a/
    terragrunt.hcl
    Répertoireservice-b/
    terragrunt.hcl

Le module est le meme que dans le premier guide. Placez-le 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 units ne changent ensuite que par le nom du fichier et le contenu ecrit.

Fichier live/dev/service-a/terragrunt.hcl :

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

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

Fichier live/dev/service-b/terragrunt.hcl :

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

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

Le premier test cible seulement service-a :

terragrunt run --all --filter './service-a' -- apply

Dans cet exemple, une seule unit est alors incluse dans la queue.

Pourquoi commencer par un filtre

Le filtre sert a reduire le blast radius. Au lieu de lancer l’ensemble du repo, vous pouvez valider un changement localise sur un seul composant.

Dans cet exemple, le resultat attendu est tres simple :

service-a.txt existe apres le premier run cible ;
service-b.txt n’existe pas encore.

Cette verification est importante parce qu’elle prouve que la selection de units fonctionne reellement, pas seulement en theorie.

Elargir ensuite au reste du repo

Une fois le run cible verifie, elargissez ensuite :

terragrunt run --all apply

Le deuxieme composant est alors applique a son tour. On passe d’un run localise a un run plus large, avec une verification observable sur les fichiers produits par les deux units.

Etapes pour reproduire

Lancer un apply cible sur service-a
Fenêtre de terminal
```
terragrunt run --all --filter './service-a' -- apply
```
Verification : service-a.txt existe et service-b.txt n’existe pas.
Lancer un apply global
Fenêtre de terminal
```
terragrunt run --all apply
```
Verification : service-b.txt apparait a son tour.
Nettoyer avec destroy
Fenêtre de terminal
```
terragrunt run --all destroy
```
Verification : les deux units sont detruites proprement.

Comment lire la queue affichee

Terragrunt affiche avant l’execution la liste des units retenues. Ce moment est important en pratique : il permet de verifier que vous allez bien lancer la bonne chose, au bon endroit.

Sur un repo simple sans dependances, la queue reste courte. Sur un repo plus grand, elle devient un outil de controle tres utile avant les operations modificatrices.

Et la run queue avec dependances ?

Quand des dependencies ou dependency existent entre units, la queue ne se contente plus de lister des dossiers. Elle suit aussi l’ordre impose par le DAG. C’est ce qui rend ensuite Terragrunt pertinent pour les scenarios multi-composants plus riches.

Dans ce guide, on reste volontairement sur deux units independantes pour isoler la logique de ciblage et de selection.

Erreurs frequentes

Symptome	Cause probable	Solution
Aucune unit decouverte	Filtre trop restrictif ou chemin faux	Verifier le dossier courant et l’expression `--filter`
Trop de units dans la queue	Filtre trop large	Commencer par un motif simple et verifier la liste affichee
Un composant non cible est quand meme touche	Dependances declarees ou commande globale sans filtre	Verifier avec un filtre explicite et verifier la queue

A retenir

run --all sert a piloter plusieurs units depuis un meme point d’entree.
La run queue montre ce que Terragrunt va vraiment executer.
--filter permet de reduire le blast radius et de ne viser qu’un sous-ensemble.
Un run cible doit toujours etre valide par un resultat observable.
Plus le repo grandit, plus la lecture de la queue devient une etape de securite operationnelle.

Prochaine etape

Terragrunt stack.hcl Passer ensuite a une composition explicite de plusieurs units quand l'arborescence implicite ne suffit plus.