Retour au cours

infra / terraform

Gestion multi-environnements : workspaces et tfvars

Leçon 91 exercice

Explication

Ce que vous allez apprendre

  • Créer et basculer entre plusieurs Terraform Workspaces
  • Adapter le dimensionnement des ressources selon terraform.workspace
  • Comprendre les limites des workspaces en grande équipe
  • Structurer une approche alternative à base de répertoires et backends séparés
  • Choisir la bonne approche selon le niveau de risque du projet

Dans quel contexte ?

Un module réutilisable existe désormais (leçons précédentes), mais l'équipe doit déployer trois versions de cette infrastructure : développement, staging et production, avec des tailles d'instances différentes et surtout, un state totalement isolé pour ne jamais mélanger accidentellement les deux mondes.

D'abord, la solution la plus simple à mettre en place : les Workspaces

Un Terraform Workspace permet de garder un seul et même code, mais de le déployer sous plusieurs états totalement séparés, sélectionnés par un simple nom. La variable spéciale terraform.workspace, disponible partout dans le code, renvoie le nom du workspace actuellement sélectionné, ce qui permet d'adapter dynamiquement le dimensionnement des ressources.

Cette approche reste très simple à mettre en oeuvre : terraform workspace new production crée un nouvel espace isolé, et terraform workspace select bascule de l'un à l'autre en une seule commande.

ApprocheComplexité de mise en placeIsolation des statesRisque d'erreur humaine
WorkspacesFaiblePartielle (même backend)Oubli de workspace select
Répertoires + backends séparésPlus élevéeTotaleRéduit (chemin explicite)

Prérequis

Il faut avoir déjà compris ce qu'est un backend distant et un state (voir la leçon dédiée) pour saisir pourquoi l'isolation des states est un enjeu aussi important dans cette leçon.

Une fois les workspaces en main, il reste une limite importante à connaître

Tous les workspaces d'un même projet partagent le MÊME backend, avec seulement une clé de state différente en interne. Cela convient très bien pour des variations légères d'une même infrastructure, mais devient risqué dès qu'une grande équipe travaille sur des environnements aux permissions très différentes.

Piège fréquent

Il est facile d'oublier sur quel workspace on se trouve avant de lancer un applyterraform workspace show affiche le workspace actif, mais rien n'empêche de lancer une commande en pensant être sur "dev" alors qu'on est resté sur "production" depuis la session précédente. C'est précisément ce risque que l'approche par répertoires séparés élimine.

Voici l'approche alternative, recommandée en production

Plutôt que de partager un seul backend, chaque environnement obtient son propre dossier (environments/production/), son propre fichier backend.tf, et donc un state complètement isolé, avec potentiellement des permissions IAM distinctes. Se tromper d'environnement devient alors beaucoup plus difficile, puisqu'il faut explicitement se déplacer dans le mauvais dossier pour lancer la mauvaise commande.

Bonne pratique

Réserve les Workspaces à des cas où l'équipe est unique, le risque limité, et les environnements réellement quasi identiques (par exemple, des environnements de test éphémères créés en CI). Pour tout ce qui touche à la production avec un vrai impact business, préfère systématiquement des répertoires et des backends séparés.

Cette question de structuration en tête, la prochaine leçon s'attaque à un cas très différent : comment reprendre sous Terraform une ressource qui a déjà été créée manuellement, sans la recréer depuis zéro.

Commandes & code

Gestion multi-environnements : workspaces et tfvars

bash
# --- Approche 1 : Terraform Workspaces ---
# Un même code, plusieurs états isolés (dev/staging/prod) via un nom de workspace
terraform workspace list                  # liste les workspaces (default existe toujours)
terraform workspace new dev
terraform workspace new staging
terraform workspace new production
terraform workspace select production      # bascule sur le workspace "production"
terraform workspace show                    # workspace actif actuellement
hcl
# Utiliser le workspace courant dans la config pour adapter le dimensionnement
locals {
  instance_type = {
    default    = "t3.micro"
    dev        = "t3.micro"
    staging    = "t3.small"
    production = "t3.large"
  }
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = local.instance_type[terraform.workspace]   # terraform.workspace = nom du workspace actif
  tags = {
    Environment = terraform.workspace
  }
}
bash
# Limite des workspaces : même backend, même clé de state de base -> risque de confusion en grande équipe
# Convient bien pour des variations LÉGÈRES (dimensionnement) d'une même infra
bash
# --- Approche 2 (recommandée en pratique) : répertoires séparés + fichiers .tfvars ---
# environments/
# ├── dev/
# │   ├── main.tf          -> appelle les modules communs
# │   └── terraform.tfvars
# ├── staging/
# │   ├── main.tf
# │   └── terraform.tfvars
# └── production/
#     ├── main.tf
#     └── terraform.tfvars

# environments/production/terraform.tfvars
instance_type = "t3.large"
environment   = "production"
min_size      = 3
max_size      = 10
bash
# Chaque environnement a son PROPRE backend (state totalement isolé, pas de risque de collision)
# environments/production/backend.tf
terraform {
  backend "s3" {
    bucket = "mon-org-terraform-state"
    key    = "production/terraform.tfstate"
    region = "eu-west-3"
  }
}

# Appliquer un environnement précis
cd environments/production
terraform init
terraform plan -var-file="terraform.tfvars"
terraform apply -var-file="terraform.tfvars"
bash
# Recommandation niveau expert :
# - Workspaces : OK pour des environnements quasi identiques, équipe unique, faible risque
# - Répertoires séparés + backends séparés : PLUS SÛR en production (isolation totale des states,
#   permissions IAM différentes possibles par environnement, pas de "terraform workspace select" oublié)

Résumé

  • Les workspaces isolent plusieurs états sous un même backend, sélectionnables via terraform.workspace.
  • Des répertoires séparés avec des backends distincts isolent totalement les états et permissions par environnement.
  • En production, l'isolation complète (backends séparés) réduit le risque d'erreur humaine (apply sur le mauvais environnement).

Exercices pratiques

1 disponible
1

Mission : éviter un apply sur le mauvais environnement

Objectif : Diagnostiquer un risque de confusion entre workspaces et choisir la bonne structuration pour un environnement critique.

Contexte

Un ingénieur pense être sur le workspace dev et lance terraform apply, mais il est en réalité resté sur production depuis la veille, sans avoir relancé terraform workspace select dev. Le code utilise local.instance_type[terraform.workspace] pour dimensionner les instances selon l'environnement actif.

Résoudre l’exercice →