Gestion des espaces de travail (workspaces). Chaque workspace a son propre state isolé dans le même backend.


Sous-commandes

CommandeDescription
workspace listListe tous les workspaces
workspace showAffiche le workspace actif
workspace new NOMCrée et sélectionne un nouveau workspace
workspace select NOMSélectionne un workspace existant
workspace delete NOMSupprime un workspace (doit être vide)

Exemples

# Lister les workspaces
terraform workspace list
# * default       ← le workspace actif est marqué *
#   dev
#   staging
#   prod
 
# Voir le workspace courant
terraform workspace show
# dev
 
# Créer un workspace
terraform workspace new staging
 
# Sélectionner un workspace existant
terraform workspace select prod
 
# Créer et utiliser dans un plan
terraform workspace new dev
terraform plan -var-file=dev.tfvars
 
# Supprimer un workspace (doit être vide / sans state actif)
terraform workspace select default
terraform workspace delete staging

Utiliser le workspace dans le code HCL

# main.tf
locals {
  env = terraform.workspace   # "dev", "staging", "prod"
}
 
resource "aws_instance" "web" {
  ami           = var.ami
  instance_type = local.env == "prod" ? "t3.large" : "t3.micro"
 
  tags = {
    Environment = terraform.workspace
    Name        = "web-${terraform.workspace}"
  }
}
 
# Adapter la taille du state selon l'environnement
resource "aws_autoscaling_group" "web" {
  min_size = terraform.workspace == "prod" ? 3 : 1
  max_size = terraform.workspace == "prod" ? 10 : 3
}

Workspaces vs Git + Backends — quand utiliser quoi ?

CritèreGit + Backends séparésWorkspaces
Isolation du stateMaximale (buckets/comptes séparés)Partielle (même backend)
CredentialsDifférents par environnementIdentiques pour tous
Versions différentesPossible (branches Git)Non (même code obligatoire)
CI/CDNaturel avec branchesNécessite logique custom
VisibilitéClair dans GitCaché dans workspaces
ComplexitéPlus de fichiers de configSimple
Cas d’usage idéalProduction multi-environnementsDéveloppement/tests temporaires

Recommandation : Pour des environnements long terme (dev/staging/prod), préférer des backends séparés. Les workspaces sont utiles pour des environnements éphémères (feature branches, tests).


Organiser les backends par workspace

# backend.tf
terraform {
  backend "s3" {
    bucket = "mon-terraform-state"
    key    = "${terraform.workspace}/terraform.tfstate"
    region = "eu-west-1"
  }
}
S3 bucket structure:
  mon-terraform-state/
    default/terraform.tfstate
    dev/terraform.tfstate
    staging/terraform.tfstate
    prod/terraform.tfstate

En relation avec