infra / terraform
Gestion multi-environnements : workspaces et tfvars
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.
| Approche | Complexité de mise en place | Isolation des states | Risque d'erreur humaine |
|---|---|---|---|
| Workspaces | Faible | Partielle (même backend) | Oubli de workspace select |
| Répertoires + backends séparés | Plus élevée | Totale | Ré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 apply — terraform 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
# --- 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# 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
}
}# 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# --- 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# 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"# 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 (
applysur le mauvais environnement).
Exercices pratiques
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.