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 maîtriser le périmètre de chaque execution.

Ce que vous allez apprendre

Comprendre le role de run --all et de la run queue
Savoir cibler une unit précise avec --filter
Vérifier 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'exécution que Terragrunt construit avant de lancer les units. Elle s'appuie sur l'arborescence courante et, si besoin, sur les dépendances déclarées entre units.

Concrètement, Terragrunt détermine :

quelles units sont concernées ;
dans quel ordre elles doivent passer ;
lesquelles peuvent être traitées en parallèle.

L'exemple utilise

Cet exemple utilise deux units sans dépendances : 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 même 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 écrit.

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 réduire 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 résultat attendu est très simple :

service-a.txt existe après le premier run cible ;
service-b.txt n'existe pas encore.

Cette verification est importante parce qu'elle prouve que la sélection de units fonctionne réellement, pas seulement en théorie.

Elargir ensuite au reste du repo

Une fois le run cible verifie, elargissez ensuite :

terragrunt run --all apply

Le deuxième 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.

Étapes 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 apparaît 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 affichée

Terragrunt affiche avant l'exécution la liste des units retenues. Ce moment est important en pratique : il permet de vérifier que vous allez bien lancer la bonne chose, au bon endroit.

Sur un repo simple sans dépendances, la queue reste courte. Sur un repo plus grand, elle devient un outil de contrôle très utile avant les operations modificatrices.

Et la run queue avec dépendances ?

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 scénarios multi-composants plus riches.

Dans ce guide, on reste volontairement sur deux units indépendantes pour isoler la logique de ciblage et de sélection.

Erreurs fréquentes

Symptôme	Cause probable	Solution
Aucune unit découverte	Filtre trop restrictif ou chemin faux	Vérifier le dossier courant et l'expression `--filter`
Trop de units dans la queue	Filtre trop large	Commencer par un motif simple et vérifier la liste affichée
Un composant non cible est quand même touche	Dépendances déclarées ou commande globale sans filtre	Vérifier avec un filtre explicite et vérifier la queue

A retenir

run --all sert a piloter plusieurs units depuis un même point d'entrée.
La run queue montre ce que Terragrunt va vraiment exécuter.
--filter permet de réduire le blast radius et de ne viser qu'un sous-ensemble.
Un run cible doit toujours être valide par un résultat observable.
Plus le repo grandit, plus la lecture de la queue devient une etape de sécurité opérationnelle.

Prochaine etape

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