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

Vous voulez integrer 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 meme logique a plusieurs environnements.

Ce que vous allez apprendre

Comprendre quelles commandes Terragrunt sont adaptees a un pipeline
Lancer un run cible et non interactif
Maitriser 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 dependances, afin de verifier qu’un pipeline cible bien une seule partie du repo avant d’elargir son perimetre.

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 reflexe. Sur ce lab, le bon point d’entree est live/dev. C’est ce choix qui borne deja une partie du blast radius.

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

Le deuxieme principe : commencer cible

Dans cet exemple, la premiere commande executee est :

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

Le resultat 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 troisieme principe : elargir seulement quand c’est voulu

Une fois la cible validee, vous pouvez lancer une execution plus large :

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

Le resultat attendu est cette fois :

service-a/service-a.txt existe toujours ;
service-b/service-b.txt apparait a son tour.

Autrement dit, vous passez d’un run a blast radius faible a un run a portee plus large, mais ce changement de perimetre reste volontaire et visible.

Le flux minimal a reproduire

Creer 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 apparait 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`	Reduire le blast radius
Tout l’environnement doit etre rejoue	`terragrunt run --all --non-interactive apply`	Appliquer l’ensemble du scope courant
Nettoyage d’un environnement ephemere	`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’entree et de pipeline.

Dans un repo reel, vous pourriez par exemple avoir :

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

Le principe reste le meme : vous rejouez la commande depuis l’environnement vise. Le mecanisme presente dans ce guide porte donc sur le controle du perimetre, pas sur un nom d’environnement particulier.

Erreurs frequentes

Symptome	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’entree dans le repo	Verifier le dossier avant d’executer 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 deja partie du controle.
--filter sert a reduire le blast radius.
Une promotion est une reexecution controlee depuis un autre environnement.
Un bon pipeline Terragrunt commence petit, puis elargit son perimetre seulement si necessaire.

Prochaines etapes

Run queue et filtres Approfondir d'abord la mecanique 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 dependances entre units pour comprendre comment la queue change dans un scenario plus realiste.

Structurer un live repo Revenir a la structure du repo si votre difficulte vient surtout du choix du bon point d'entree par environnement.