Terragrunt, simplifiez votre Infrastructure en tant que Code (IaC)

Qu’est-ce que Terragrunt ?

Terragrunt est un outil (open-source) de gestion de configurations qui agit comme une enveloppe autour de Terraform. Il fournit des fonctionnalités supplémentaires pour appréhender plusieurs environnements, réutiliser du code et gérer les dépendances. Terragrunt facilite également le déploiement et la maintenance de l’infrastructure en tant que code (IaC).

Les fonctionnalités de Terragrunt

Terragrunt nous propose un large éventail de fonctionnalités :

• Gestion de la configuration : permet de définir des variables communes pour plusieurs modules Terraform.
• Dépendances : gère les dépendances entre différents modules Terraform.
• DRY (Don’t Repeat Yourself) : permet de réutiliser du code grâce à des configurations partagées.
• Verrouillage des états : fournit un mécanisme de verrouillage pour éviter les conflits dans les états Terraform.
• Automatisation du workflow : automatise des tâches comme l’initialisation, la planification et l’application de modules.
• Gestion des environnements : facilite la gestion de plusieurs environnements (dev, staging, prod).
• Gestion des backends : simplifie la configuration des backends Terraform pour le stockage d’état.
• Gestion des secrets : permet l’intégration avec des gestionnaires de secrets comme AWS Secrets Manager.
• Validation avancée : permet des validations personnalisées avant l’application des changements.
• Hooks : permet d’exécuter des scripts avant ou après certaines commandes Terraform.
• Gestion des comptes AWS : permet de manager plusieurs comptes.

Installation de Terragrunt

Tout d’abord, vous devrez installer Terraform ainsi que Terragrunt. À noter que Terragrunt est encore en version beta, car il n’existe toujours pas de version 1. Récapitulons l’installation de ces différents framework suivant les OS :

Linux

Pour pouvoir continuer, il sera nécessaire d’être un super-utilisateur.

Ubuntu / Debian

apt-get update && apt-get install -y gnupg software-properties-common

wget -O- https://apt.releases.hashicorp.com/gpg | \
gpg --dearmor | \
tee /usr/share/keyrings/hashicorp-archive-keyring.gpg

gpg --no-default-keyring \
--keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \
--fingerprint


echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/hashicorp.list

apt update -y
apt-get install terraform -y


terraform -help


terraform [global options] <subcommand> [args]

The available commands for execution are listed below.
The primary workflow commands are given first, followed by
less common or more advanced commands.

Main commands:
  init          Prepare your working directory for other commands
  validate      Check whether the configuration is valid
  plan          Show changes required by the current configuration
  apply         Create or update infrastructure
  destroy       Destroy previously-created infrastructure

All other commands:
  console       Try Terraform expressions at an interactive command prompt
  fmt           Reformat your configuration in the standard style
  force-unlock  Release a stuck lock on the current workspace
  get           Install or upgrade remote Terraform modules
  graph         Generate a Graphviz graph of the steps in an operation
  import        Associate existing infrastructure with a Terraform resource
  login         Obtain and save credentials for a remote host
  logout        Remove locally-stored credentials for a remote host
  metadata      Metadata related commands
  output        Show output values from your root module
  providers     Show the providers required for this configuration
  refresh       Update the state to match remote systems
  show          Show the current state or a saved plan
  state         Advanced state management
  taint         Mark a resource instance as not fully functional
  test          Experimental support for module integration testing
  untaint       Remove the 'tainted' state from a resource instance
  version       Show the current Terraform version
  workspace     Workspace management

Global options (use these before the subcommand, if any):
  -chdir=DIR    Switch to a different working directory before executing the
                given subcommand.
  -help         Show this help output, or the help for a specified subcommand.
  -version      An alias for the "version" subcommand.

Installer Terragrunt :

wget https://github.com/gruntwork-io/terragrunt/releases/download/v0.48.0/terragrunt_linux_amd64

mv terragrunt_linux_amd64 terragrunt
mv terragrunt /usr/local/bin/
chmod +x /usr/local/bin/terragrunt

terragrunt --version
terragrunt version v0.48.0

CentOS

yum install -y yum-utils
yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
yum -y install terraform

terraform -help

Installer Terragrunt :

wget https://github.com/gruntwork-io/terragrunt/releases/download/v0.48.0/terragrunt_linux_amd64

mv terragrunt_linux_amd64 terragrunt
mv terragrunt /usr/local/bin/
chmod +x /usr/local/bin/terragrunt

terragrunt --version
terragrunt version v0.48.0

Fedora

dnf upgrade

dnf update

dnf install dnf-plugins-core

dnf config-manager --add-repo ``https://rpm.releases.hashicorp.com/fedora/hashicorp.repo

dnf update

dnf install terraform

MacOS

Installer Terraform :

brew tap hashicorp/tap
brew install hashicorp/tap/terraform
brew update
brew upgrade hashicorp/tap/terraform

Vérifier l'installation de Terraform :

terraform -help

Installer Terragrunt :

brew install terragrunt

Windows

choco install terraform

terraform -help

choco install terragrunt

Configurer AWS pour débuter avec Terragrunt

Pour continuer notre découverte de Terragrunt, nous utiliserons une machine Linux (Debian 11) ainsi qu’AWS comme provider.

Pour cela, vous devrez installer aws cli sur votre machine.

Puis, configurer votre utilisateur IAM et enfin générer une clef d’accès.

L’utilisateur IAM aura besoin de droits spécifiques pour la suite de notre article :

• AmazonS3FullAccess
• AmazonDynamoDBFullAccess
• AmazonVPCFullAccess
• AmazonRDSFullAccess
• AmazonEC2FullAccess

Maintenant que tous ces prérequis ont été faits, configurons un profil par défaut sur notre machine :

Editer le fichier ~/.aws/config, on choisira par défaut la région eu-west-3 (Paris) :

[profile default]
output = json
region = eu-west-3

Puis, le fichier ~/.aws/credentials :

[default]
aws_access_key_id = REPLACE_ME
aws_secret_access_key = REPLACE_ME

Vous pouvez protéger le fichier de la manière suivante :

chmod 700 ~/.aws/credentials

Exporter votre profil précédemment créé :

export AWS_PROFILE=default
export AWS_REGION=`aws configure get region`

Passer en revue vos variables d’environnement :

env | grep "AWS"

Puis, tester la configuration :

aws sts get-caller-identity

Garder précieusement la sortie de la commande précédente, elle nous sera utile plus tard.

{
    "UserId": "REPLACE_ME",
    "Account": "REPLACE_ME",
    "Arn": "REPLACE_ME"
}

Premiers pas avec Terragrunt

Définissons notre premier projet, l’objectif sera de pouvoir utiliser le registry VPC développé et mis à disposition par HashiCorp pour pouvoir déployer nos ressources.

Procéder à la création d’un nouveau répertoire de travail et positionnez-vous dedans :

mkdir premier_projet
cd premier_projet

Définissons le fichier terragrunt.hcl suivant :

terraform {
  source = "tfr:///terraform-aws-modules/vpc/aws?version=5.0.0"
}

# Indicate what region to deploy the resources into
generate "provider" {
  path = "provider.tf"
  if_exists = "overwrite_terragrunt"
  contents = <<EOF
provider "aws" {
  region = "us-east-1"
}
EOF
}

# Indicate the input values to use for the variables of the module.
inputs = {
  name = "my-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1b", "us-east-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  enable_vpn_gateway = false

  tags = {
    Terraform = "true"
    Environment = "dev"
  }
}

Le block terraform est configuré pour que Terragrunt puisse interagir avec Terraform. Ici, nous l’utilisons pour indiquer à Terragrunt où se trouve le code Terraform en utilisant l’attribut source, dans notre cas, le module VPC et la version 5.0.0, dernière en date.

Le block generate est utilisé pour introduire la configuration de notre provider, nous pourrons y retrouver des éléments comme la région utilisée, les api ou le mécanisme d’authentification.

Le block inputs nous sert à définir les valeurs de notre attribut. Dans notre exemple, nous avons décidé de définir les éléments suivants :

• nom de notre **vpc**
• notre **cidr**
• nos **zones de disponibilité**
• nos sous réseaux **privés** et **publics**
• d’autoriser **nat_gateway**
• de ne pas utiliser **vpn_gateway**

Vous pouvez bien sûr le configurer selon vos besoins en vous référant à la documentation de ce module.

De la même manière qu’avec Terraform, vous devez utiliser le plan pour obtenir un premier aperçu des changements qui seront apportés à notre infrastructure :

terragrunt plan -out <path_file.tfplan>

Puis, l’appliquer :

terragrunt apply <path_file.tfplan>

Une fois que vous n’avez plus besoin de vos ressources, vous pouvez les détruire de la manière suivante. N’oubliez pas de consulter la console AWS :

terragrunt destroy -auto-approve

Use cases

Keep your Terraform code DRY

Au préalable, vous devrez avoir installé la version 1.1.4 de Terraform pour exécuter ce module. Si vous possédez une autre version, vous pouvez utiliser les commandes suivantes :

apt remove terraform
rm /usr/local/bin/terraform
wget https://releases.hashicorp.com/terraform/1.1.4/terraform_1.1.4_linux_amd64.zip
unzip terraform_1.1.4_linux_amd64.zip
rm terraform_1.1.4_linux_amd64.zip
mv terraform /usr/local/bin/

Puis vérifier :

terraform version

L’objectif de ce cas d’usage sera de pouvoir déployer des ressources (MySQL on RDS, ASF with ELB) sur AWS pour deux environnements :

• prod
• non-prod

Dans l’environnement non-prod, on retrouvera deux autres environnnements que sont qa et stage.

Terragrunt fournit un Git pour notre exemple. Clonez le sur votre machine :

git clone https://github.com/gruntwork-io/terragrunt-infrastructure-live-example.git

Puis, placez-vous dans le répertoire :

cd terragrunt-infrastructure-live-example/

Vous obtenez l’arborescence suivante :

.
├── CODEOWNERS
├── _envcommon
│   ├── mysql.hcl
│   ├── README.md
│   └── webserver-cluster.hcl
├── LICENSE.txt
├── non-prod
│   ├── account.hcl
│   └── us-east-1
│       ├── qa
│       │   ├── env.hcl
│       │   ├── mysql
│       │   │   └── terragrunt.hcl
│       │   └── webserver-cluster
│       │       └── terragrunt.hcl
│       ├── region.hcl
│       └── stage
│           ├── env.hcl
│           ├── mysql
│           │   └── terragrunt.hcl
│           └── webserver-cluster
│               └── terragrunt.hcl
├── prod
│   ├── account.hcl
│   └── us-east-1
│       ├── prod
│       │   ├── env.hcl
│       │   ├── mysql
│       │   │   └── terragrunt.hcl
│       │   └── webserver-cluster
│       │       └── terragrunt.hcl
│       └── region.hcl
├── README.md
└── terragrunt.hcl

Pour créer la base de données et notre groupe d’Auto Scaling, les fichiers de configuration sont regroupés dans le répertoire env_common. Vous pouvez les trouver dans ce repo.

`_envcommon/mysql.hcl` :

# ---------------------------------------------------------------------------------------------------------------------
# COMMON TERRAGRUNT CONFIGURATION
# This is the common component configuration for mysql. The common variables for each environment to
# deploy mysql are defined here. This configuration will be merged into the environment configuration
# via an include block.
# ---------------------------------------------------------------------------------------------------------------------

# Terragrunt will copy the Terraform configurations specified by the source parameter, along with any files in the
# working directory, into a temporary folder, and execute your Terraform commands in that folder. If any environment
# needs to deploy a different module version, it should redefine this block with a different ref to override the
# deployed version.
terraform {
  source = "${local.base_source_url}?ref=v0.7.0"
}


# ---------------------------------------------------------------------------------------------------------------------
# Locals are named constants that are reusable within the configuration.
# ---------------------------------------------------------------------------------------------------------------------
locals {
  # Automatically load environment-level variables
  environment_vars = read_terragrunt_config(find_in_parent_folders("env.hcl"))

  # Extract out common variables for reuse
  env = local.environment_vars.locals.environment

  # Expose the base source URL so different versions of the module can be deployed in different environments. This will
  # be used to construct the terraform block in the child terragrunt configurations.
  base_source_url = "git::git@github.com:gruntwork-io/terragrunt-infrastructure-modules-example.git//mysql"
}


# ---------------------------------------------------------------------------------------------------------------------
# MODULE PARAMETERS
# These are the variables we have to pass in to use the module. This defines the parameters that are common across all
# environments.
# ---------------------------------------------------------------------------------------------------------------------
inputs = {
  name              = "mysql_${local.env}"
  instance_class    = "db.t2.micro"
  allocated_storage = 20
  storage_type      = "standard"
  master_username   = "admin"

  # TODO: To avoid storing your DB password in the code, set it as the environment variable TF_VAR_master_password
}

`_envcommon/mysql.hcl`

# ---------------------------------------------------------------------------------------------------------------------
# COMMON TERRAGRUNT CONFIGURATION
# This is the common component configuration for webserver-cluster. The common variables for each environment to
# deploy webserver-cluster are defined here. This configuration will be merged into the environment configuration
# via an include block.
# ---------------------------------------------------------------------------------------------------------------------

# ---------------------------------------------------------------------------------------------------------------------
# Locals are named constants that are reusable within the configuration.
# ---------------------------------------------------------------------------------------------------------------------
locals {
  # Automatically load environment-level variables
  environment_vars = read_terragrunt_config(find_in_parent_folders("env.hcl"))

  # Extract out common variables for reuse
  env = local.environment_vars.locals.environment

  # Expose the base source URL so different versions of the module can be deployed in different environments.
  base_source_url = "git::git@github.com:gruntwork-io/terragrunt-infrastructure-modules-example.git//asg-elb-service"
}

# ---------------------------------------------------------------------------------------------------------------------
# MODULE PARAMETERS
# These are the variables we have to pass in to use the module. This defines the parameters that are common across all
# environments.
# ---------------------------------------------------------------------------------------------------------------------
inputs = {
  name          = "webserver-example-${local.env}"
  instance_type = "t2.micro"

  min_size = 2
  max_size = 2

  server_port = 8080
  elb_port    = 80
}

Le fichier account.hcl est utilisé pour configurer notre compte AWS dans chaque environnement, qu’il s’agisse de production ou de non-production. Nous examinerons la possibilité de configurer un compte pour chaque environnement plus tard.

`prod\us-east-1\account.hcl` :

locals {
  account_name   = "REPLACE ME"
  aws_account_id = "REPLACE ME" # TODO: replace me with your AWS account ID!
  aws_profile    = "non-prod"
}

Vous pouvez retrouver les informations nécessaires comme vu précédemment :

aws sts get-caller-identity

Ensuite, nous définissons notre variable d’environnement dans le fichier env.hcl :

`prod\us-east-1\prod\env.hcl` :

locals {
  environment = "REPLACE ME" # qa, stage, prod  Ici, ce sera prod
}

Puis enfin, les fichiers de configurations mysql et asg. Les variables changeront suivant les besoins et l’environnement de configuration.
Les variables pouvant être changées dans ce cas d’usage :

• instance_class
• allocated_storage
• instance_type
• min_size
• max_size

• la variable d’environnement
• le nom de votre compte
• la région spécifiée pour AWS

`prod\us-east-1\prod\web-server-cluster\terragrunt.hcl` :

# ---------------------------------------------------------------------------------------------------------------------
# TERRAGRUNT CONFIGURATION
# This is the configuration for Terragrunt, a thin wrapper for Terraform that helps keep your code DRY and
# maintainable: https://github.com/gruntwork-io/terragrunt
# ---------------------------------------------------------------------------------------------------------------------

# ---------------------------------------------------------------------------------------------------------------------
# Include configurations that are common used across multiple environments.
# ---------------------------------------------------------------------------------------------------------------------

# Include the root `terragrunt.hcl` configuration. The root configuration contains settings that are common across all
# components and environments, such as how to configure remote state.
include "root" {
  path = find_in_parent_folders()
}

# Include the envcommon configuration for the component. The envcommon configuration contains settings that are common
# for the component across all environments.
include "envcommon" {
  path = "${dirname(find_in_parent_folders())}/_envcommon/webserver-cluster.hcl"
}


# ---------------------------------------------------------------------------------------------------------------------
# Override parameters for this environment
# ---------------------------------------------------------------------------------------------------------------------

# For production, we want to specify bigger instance classes and cluster, so we specify override parameters here. These
# inputs get merged with the common inputs from the root and the envcommon terragrunt.hcl
inputs = {
  instance_type = "t2.medium"

  min_size = 3
  max_size = 3
}

`prod\us-east-1\prod\mysql\terragrunt.hcl` :

# ---------------------------------------------------------------------------------------------------------------------
# TERRAGRUNT CONFIGURATION
# This is the configuration for Terragrunt, a thin wrapper for Terraform that helps keep your code DRY and
# maintainable: https://github.com/gruntwork-io/terragrunt
# ---------------------------------------------------------------------------------------------------------------------

# ---------------------------------------------------------------------------------------------------------------------
# Include configurations that are common used across multiple environments.
# ---------------------------------------------------------------------------------------------------------------------

# Include the root `terragrunt.hcl` configuration. The root configuration contains settings that are common across all
# components and environments, such as how to configure remote state.
include "root" {
  path = find_in_parent_folders()
}

# Include the envcommon configuration for the component. The envcommon configuration contains settings that are common
# for the component across all environments.
include "envcommon" {
  path = "${dirname(find_in_parent_folders())}/_envcommon/mysql.hcl"
}


# ---------------------------------------------------------------------------------------------------------------------
# Override parameters for this environment
# ---------------------------------------------------------------------------------------------------------------------

# For production, we want to specify bigger instance classes and storage, so we specify override parameters here. These
# inputs get merged with the common inputs from the root and the envcommon terragrunt.hcl
inputs = {
  instance_class    = "db.t2.medium"
  allocated_storage = 100
}

Une fois tous ces fichiers configurés, placez-vous dans le répertoire suivant :

cd non-prod/us-east-1/prod/mysql

Assurez-vous de configurer un mot de passe pour accéder à votre base de données :

export TF_VAR_master_password=("REPLACE ME")

Puis :

terragrunt plan

À noter que lorsque vous exécutez la commande terragrunt plan, cela crée le bucket S3 en amont, mais sans le fichier de configuration backend.tf.

Et enfin :

terragrunt apply

N’oubliez pas de supprimer vos ressources une fois terminé :

terragrunt destroy

Keep your remote state configuration DRY

Terragrunt offre la possibilité de stocker le fichier d’état dans un bucket S3, ce qui permet de s’assurer de la cohérence de l’état de l’infrastructure que l’on souhaite déployer ou redéployer. Lorsqu’on crée un Bucket s3, nous faisons référence à une table dynamo du nom de terraform-locks car c’est dans cette table dynamodb qu’est stocké le lock afin de verrouiller le déploiement de notre infrastructure pour éviter les double lancements.

`terragrunt-infrastructure-live-example/terragrunt.hcl`

# ---------------------------------------------------------------------------------------------------------------------
# TERRAGRUNT CONFIGURATION
# Terragrunt is a thin wrapper for Terraform that provides extra tools for working with multiple Terraform modules,
# remote state, and locking: https://github.com/gruntwork-io/terragrunt
# ---------------------------------------------------------------------------------------------------------------------

locals {
  # Automatically load account-level variables
  account_vars = read_terragrunt_config(find_in_parent_folders("account.hcl"))

  # Automatically load region-level variables
  region_vars = read_terragrunt_config(find_in_parent_folders("region.hcl"))

  # Automatically load environment-level variables
  environment_vars = read_terragrunt_config(find_in_parent_folders("env.hcl"))

  # Extract the variables we need for easy access
  account_name = local.account_vars.locals.account_name
  account_id   = local.account_vars.locals.aws_account_id
  aws_region   = local.region_vars.locals.aws_region
}

# Generate an AWS provider block
generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
provider "aws" {
  region = "${local.aws_region}"

  # Only these AWS Account IDs may be operated on by this template
  allowed_account_ids = ["${local.account_id}"]
}
EOF
}

# Configure Terragrunt to automatically store tfstate files in an S3 bucket
remote_state {
  backend = "s3"
  config = {
    encrypt        = true
    bucket         = "${get_env("TG_BUCKET_PREFIX", "")}terragrunt-example-terraform-
state-${local.account_name}-${local.aws_region}"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = local.aws_region
    dynamodb_table = "terraform-locks"
  }
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite_terragrunt"
  }
}


# ---------------------------------------------------------------------------------------------------------------------
# GLOBAL PARAMETERS
# These variables apply to all configurations in this subfolder. These are automatically merged into the child
# `terragrunt.hcl` config via the include block.
# ---------------------------------------------------------------------------------------------------------------------

# Configure root level variables that all resources can inherit. This is especially helpful with multi-account configs
# where terraform_remote_state data sources are placed directly into the modules.
inputs = merge(
  local.account_vars.locals,
  local.region_vars.locals,
  local.environment_vars.locals,
)

Lors du déploiement de vos ressources, le nom de votre bucket sera construit en prenant en compte :

• la variable d’environnement
• le nom de votre compte
• la région spécifiée pour AWS

Terragrunt s’assurera aussi qu’un fichier de configuration n’existe pas déjà. Maintenant, prenons l’exemple d’un déploiement de ressources sur la région us-east-1 avec comme variable d’environnement prod et comme compte terragrunt-prod. Votre bucket portera le nom suivant prod-terragrunt-example-terraform-state-terragrunt-prod-prod.

Execute Terraform commands on multiple modules at once

En utilisant Terragrunt, vous pouvez effectuer l’exécution simultanée de plusieurs modules. Nous allons réaliser un test en utilisant l’arborescence de dossiers fournie par Terragrunt.

Ici, nous cherchons à déployer les environnements qa et stage contenus dans l’environnement non-prod. Pour ce faire, placez-vous dans le répertoire suivant :

cd non-prod/us-east-1

N’oubliez pas d’exporter le mot de passe de votre base de données :

export TF_VAR_master_password=("REPLACE ME")

Ensuite, il vous suffira simplement de faire :

terragrunt plan-all

Puis :

terragrunt apply-all

N’oubliez pas de détruire vos instances à la fin :

terragrunt destroy-all

Depuis le répertoire racine, vous pouvez également choisir d’exécuter le module de votre choix :

terragrunt plan -target=<path_to_the_module>

Ou directement le fichier terragrunt.hcl :

terragrunt plan -var-file=<path_to_the_filename>

Work with multiple AWS accounts

Nous avons vu qu’il était possible de déployer plusieurs environnements, mais ce qui est aussi intéressant avec Terragrunt, c’est de pouvoir déployer un compte pour chaque environnement.

Comme déjà mentionné, nous personnalisons le fichier account.hcl pour chaque environnement, ce qui signifie qu’il faut créer un compte pour chacun et changer les variables en conséquence.

Ci-joint la ressource pour créer un utilisateur IAM sur AWS et une clef de sécurité.

Mais vous pouvez aussi le faire en ligne de commande :

terragrunt apply --terragrunt-iam-role "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME"

Une autre alternative est d’exporter la variable TERRAGRUNT_IAM_ROLE :

export TERRAGRUNT_IAM_ROLE="arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME"
terragrunt apply

Si vous avez besoin de récupérer les informations de votre compte, il faut avoir installé aws cli sur votre ordinateur et configurer votre compte comme énoncé au début.

Conclusion

En résumé, Terragrunt se révèle être un framework robuste dédié à la gestion d’infrastructure en tant que Code (IaC). Il présente de nombreuses fonctionnalités comme l’opportunité de réutiliser du code déjà écrit (DRY), d’utiliser plusieurs comptes pour la gestion des environnements, déployer plusieurs modules en même temps, mais aussi de pouvoir sauvegarder plusieurs fichiers de configurations à la fois.

Néanmoins, Terragrunt présente quelques inconvénients, tels que des documentations non mises à jour depuis un certain temps et une complexité liée à la compréhension de l’arborescence des fichiers et du langage en lui-même.

Bien que ce framework demande un certain temps pour maîtriser pleinement la solution et en exploiter tout son potentiel, Terragrunt demeure un choix excellent pour la gestion d’infrastructure en tant que code (IaC). D’autres frameworks pour la gestion de code Terraform, tels que Terraspace, Ansible et Pulumi, sont également disponibles.