Pourquoi plusieurs environnements ?
Les environnements multiples permettent de valider les changements progressivement avant la production. Un pipeline typique traverse dev, staging puis production.
Terraform Workspaces
Les workspaces Terraform isolent les fichiers d'etat (state) par environnement tout en partageant la meme configuration.
# Creer et basculer entre les workspaces
terraform workspace new dev
terraform workspace new staging
terraform workspace new production
terraform workspace select staging
# Utiliser le workspace dans la configuration
resource "aws_instance" "web" {
ami = var.ami_id
instance_type = terraform.workspace == "production" ? "t3.large" : "t3.micro"
tags = {
Name = "web-${terraform.workspace}"
Environment = terraform.workspace
}
}
# Variables par environnement
locals {
env_config = {
dev = {
instance_count = 1
db_size = "db.t3.micro"
}
staging = {
instance_count = 2
db_size = "db.t3.small"
}
production = {
instance_count = 3
db_size = "db.t3.large"
}
}
config = local.env_config[terraform.workspace]
}
Ansible Inventories par environnement
Ansible utilise des inventaires separes pour cibler chaque environnement :
# Structure des inventaires
inventories/
dev/
hosts.yml
group_vars/
all.yml
staging/
hosts.yml
group_vars/
all.yml
production/
hosts.yml
group_vars/
all.yml
# inventories/staging/hosts.yml
all:
children:
webservers:
hosts:
staging-web-01:
ansible_host: 10.1.2.10
staging-web-02:
ansible_host: 10.1.2.11
databases:
hosts:
staging-db-01:
ansible_host: 10.1.3.10
# Execution ciblant un environnement
ansible-playbook -i inventories/staging site.yml
Kubernetes Namespaces
Les namespaces Kubernetes isolent les ressources par environnement sur un meme cluster :
# Creer les namespaces
kubectl create namespace dev
kubectl create namespace staging
kubectl create namespace production
# ResourceQuota par namespace
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota
namespace: dev
spec:
hard:
requests.cpu: "2"
requests.memory: 4Gi
limits.cpu: "4"
limits.memory: 8Gi
pods: "20"
# NetworkPolicy pour isoler les namespaces
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-cross-namespace
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- podSelector: {}
Best practice : Utilisez des clusters separes pour la production si la securite l'exige. Les namespaces conviennent pour dev/staging mais la production merite souvent son propre cluster.