Terragrunt en CI/CD : cibler, limiter le blast radius, promouvoir

Vous voulez intégrer Terragrunt dans votre pipeline CI/CD sans risquer d'appliquer tout le repo a chaque changement ? Le bon usage consiste a partir du bon dossier, a lancer des commandes non interactives, puis a cibler seulement les units utiles. Ce guide montre ce flux sur un exemple minimal avec deux units, puis explique comment transposer la même logique a plusieurs environnements.

Ce que vous allez apprendre

Comprendre quelles commandes Terragrunt sont adaptées a un pipeline
Lancer un run cible et non interactif
Maîtriser le blast radius d'une execution CI/CD
Comprendre la logique de promotion par environnement

L'exemple minimal

Le scenario le plus utile pour parler CI/CD est celui de deux units sans dépendances, afin de vérifier qu'un pipeline cible bien une seule partie du repo avant d'elargir son périmètre.

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

Placez le module commun 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
}

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 principe : partir du bon dossier

Le pipeline ne doit pas partir du haut du repo par réflexe. Sur ce lab, le bon point d'entrée est live/dev. C'est ce choix qui borne déjà une partie du blast radius.

Un pipeline trop large commence souvent par une erreur simple : lancer Terragrunt depuis un dossier plus haut que nécessaire.

Le deuxième principe : commencer cible

Dans cet exemple, la première commande exécutée est :

cd live/dev
terragrunt run --all --non-interactive --filter './service-a' -- apply

Le résultat attendu est observable :

service-a/service-a.txt existe ;
service-b/service-b.txt n'existe pas encore.

Cette etape est importante en CI/CD : elle prouve que le pipeline n'a touche que la partie du repo qu'il devait traiter.

Le troisième principe : elargir seulement quand c'est voulu

Une fois la cible validée, vous pouvez lancer une execution plus large :

cd live/dev
terragrunt run --all --non-interactive apply

Le résultat attendu est cette fois :

service-a/service-a.txt existe toujours ;
service-b/service-b.txt apparaît a son tour.

Autrement dit, vous passez d'un run a blast radius faible a un run a portée plus large, mais ce changement de périmètre reste volontaire et visible.

Le flux minimal a reproduire

Créer le projet et se placer dans live/dev

Verification : deux units service-a et service-b sont presentes.
Lancer un apply cible et non interactif
Fenêtre de terminal
```
terragrunt run --all --non-interactive --filter './service-a' -- apply
```
Verification : seul service-a/service-a.txt existe.
Elargir ensuite a tout l'environnement
Fenêtre de terminal
```
terragrunt run --all --non-interactive apply
```
Verification : service-b/service-b.txt apparaît aussi.
Nettoyer
Fenêtre de terminal
```
terragrunt run --all --non-interactive destroy
```
Verification : les deux fichiers ont disparu.

Ce qu'un pipeline doit retenir

Cas	Commande utile	Pourquoi
Un seul composant change	`terragrunt run --all --non-interactive --filter './service-a' -- apply`	Réduire le blast radius
Tout l'environnement doit être rejoue	`terragrunt run --all --non-interactive apply`	Appliquer l'ensemble du scope courant
Nettoyage d'un environnement éphémère	`terragrunt run --all --non-interactive destroy`	Nettoyer sans invites

Ou placer la promotion

Une promotion n'est pas une sous-commande speciale de Terragrunt. C'est un choix de dossier d'entrée et de pipeline.

Dans un repo réel, vous pourriez par exemple avoir :

live/dev/...
live/staging/...
live/prod/...

Le principe reste le même : vous rejouez la commande depuis l'environnement vise. Le mecanisme presente dans ce guide porte donc sur le contrôle du périmètre, pas sur un nom d'environnement particulier.

Erreurs fréquentes

Symptôme	Cause probable	Solution
Le pipeline attend une saisie	Oubli de `--non-interactive`	Ajouter l'option sur les commandes non lues par un humain
Trop de units sont touchees	Dossier courant trop haut ou absence de filtre	Repartir du bon dossier puis cibler avec `--filter`
Le mauvais environnement est modifie	Mauvais point d'entrée dans le repo	Vérifier le dossier avant d'exécuter Terragrunt
Un pipeline est trop lent et trop large	Tout est lance a chaque changement	Commencer par un run cible quand c'est possible

A retenir

En CI/CD, --non-interactive est la base.
Le dossier depuis lequel vous lancez Terragrunt fait déjà partie du contrôle.
--filter sert a réduire le blast radius.
Une promotion est une reexecution contrôlée depuis un autre environnement.
Un bon pipeline Terragrunt commence petit, puis elargit son périmètre seulement si nécessaire.

Prochaines étapes

Run queue et filtres Approfondir d'abord la mécanique locale de run --all et la lecture de la queue avant de la transposer dans un pipeline.

Dependances et mock_outputs Ajouter ensuite de vraies dépendances entre units pour comprendre comment la queue change dans un scenario plus réaliste.

Structurer un live repo Revenir a la structure du repo si votre difficulté vient surtout du choix du bon point d'entrée par environnement.