Les Workspaces permettent aux utilisateurs de Terraform de gérer plusieurs états d'infrastructure distincts au sein d'un même ensemble de fichiers de configuration. Cette approche est particulièrement utile pour séparer les environnements.
Un Workspace dans Terraform est en fait une instance d'état, permettant de gérer différentes configurations à partir d'un même ensemble de fichiers. Cette segmentation offre une grande flexibilité pour manipuler divers environnements tels que le développement, le test et la production.
La gestion des Workspaces se fait avec la commande terraform workspace.
Pour créer un nouveau Workspace, utilisez terraform workspace new suivi du nom du Workspace. Par exemple, pour créer un Workspace nommé development :
terraform workspace new prod
Created and switched to workspace "prod"!
You're now on a new, empty workspace. Workspaces isolate their state,
so if you run "terraform plan" Terraform will not see any existing state
for this configuration.
Ce code crée un Workspace séparé où vous pouvez appliquer des configurations spécifiques sans affecter d'autres Workspaces.
terraform workspace list
default
* prod
Le workspace actif est celui possédant une étoile devant son nom.
terraform workspace select default
Switched to workspace "default".
Cette commande est utile pour changer l'environnement sur lequel vous travaillez.
terraform workspace delete development
Voici un exemple simple montrant comment utiliser une variable de Workspace dans du code Terraform :
variable "environment" {
description = "L'environnement de déploiement"
default = "development"
}
provider "aws" {
region = "us-west-2"
}
resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
tags = {
Name = "Serveur-${terraform.workspace}"
}
}
Dans cet exemple, le tag Name de la ressource AWS sera différente selon le Workspace sélectionné, reflétant ainsi l'environnement sur lequel la ressource est déployée.
Vous pouvez aussi tester contenu pour créer d'autres variables :
high_availability = (terraform.workspace == "prod") ? true : false
module "network" {
source = "./modules/network"
environment = terraform.workspace
}
Ici, le module network recevra l'information de l'environnement actuel du Workspace.
Une séparation claire des environnements (développement, test, production) est fondamentale. Chaque Workspace doit être traité comme un domaine isolé, avec des droits d'accès distincts. Cette séparation réduit les risques d'erreurs humaines et d'effets indésirables entre les environnements.
Il est également important de mettre en œuvre le principe de moindre privilège, en s'assurant que les utilisateurs et les processus automatisés n'ont que les permissions strictement nécessaires pour leurs tâches.
Le chiffrage des données sensibles, tant au repos qu'en transit, est essentiel. Pour les secrets tels que les mots de passe ou les clés API, l'utilisation de gestionnaires de secrets comme Vault, AWS Secrets Manager, Infisical ou PassBolt est conseillée. Ces outils permettent de centraliser et de sécuriser la gestion des secrets, tout en les rendant accessibles de manière contrôlée aux Workspaces appropriés.
Les outils comme Jenkins, GitLab CI ou GitHub Actions peuvent être configurés pour exécuter les commandes Terraform plan et apply lors de l'engagement de code ou selon d'autres déclencheurs.
Dans les pipelines CI/CD, il est possible de sélectionner ou de changer de Workspace Terraform automatiquement en fonction de la branche ou de l'environnement ciblé. Par exemple, un commit sur la branche develop peut déclencher des actions Terraform dans le Workspace dev, tandis qu'un merge sur la branche master pourrait cibler le Workspace prod.
Cela permet de s'assurer que les bonnes configurations sont appliquées au bon environnement.
La gestion des dépendances, avec un outil comme Renovate et des versions est également importante dans l'automatisation.