Atelier : automatiser un provisioning récurrent
Construire une chaîne d'automatisation sécurisée de bout en bout, de la définition du besoin au test avant mise en production.
À retenir
- Découper l'automatisation en couches infrastructure / configuration / secrets facilite la maintenance.
- Les secrets ne doivent jamais être commités en clair ; ansible-vault et un coffre-fort dédié sont la norme.
- Les modes dry-run (--check, terraform plan) sont une étape obligatoire avant application réelle.
- Un déploiement progressif (sandbox → pilote → généralisation) limite l'impact des erreurs.
Cadrer le besoin avant d'écrire du code
L'atelier part d'un cas concret fréquent : le provisioning récurrent d'un environnement applicatif (VM + configuration + secrets) pour de nouveaux clients ou de nouvelles équipes. Avant d'écrire la moindre ligne de code, il faut documenter la procédure manuelle actuelle, étape par étape, avec ses cas particuliers.
Étape 1 — Découper en couches
- Couche infrastructure (Terraform) : réseau, VM, groupes de sécurité, base de données managée.
- Couche configuration (Ansible) : paquets, utilisateurs système, services applicatifs.
- Couche secrets : jamais en clair dans le dépôt Git, gérés via un coffre-fort dédié.
# variables.tf — paramétrage du provisioning
variable "client_name" {
type = string
description = "Nom du client, utilisé pour le nommage des ressources"
}
variable "environment" {
type = string
default = "production"
}
Étape 2 — Sécuriser les secrets
Attention
un secret en clair dans un fichier .tfvars ou une variable Ansible non chiffrée committée par erreur reste dans l'historique Git même après suppression du fichier ; la rotation immédiate du secret est alors la seule réponse fiable.
# group_vars/all/vault.yml — chiffré avec ansible-vault
$ANSIBLE_VAULT;1.1;AES256
66386439653...
ansible-vault encrypt group_vars/all/vault.yml
ansible-playbook site.yml --vault-password-file ~/.vault_pass.txt
Pour Terraform, privilégier un backend distant chiffré (S3 + chiffrement côté serveur, ou Terraform Cloud) et récupérer les secrets applicatifs depuis un gestionnaire dédié (HashiCorp Vault, AWS Secrets Manager) plutôt que de les stocker dans le state.
Étape 3 — Rendre la chaîne idempotente et testable
# Pipeline minimal d'automatisation, exécutable localement ou en CI
set -euo pipefail
terraform init -input=false
terraform validate
terraform plan -out=tfplan -var="client_name=${1:?nom client requis}"
terraform apply -auto-approve tfplan
ansible-playbook -i inventory/production site.yml \
--extra-vars "client_name=$1" \
--vault-password-file ~/.vault_pass.txt \
--check # étape dry-run avant application réelle
Point clé
l'option --check d'Ansible (mode dry-run) et terraform plan jouent le même rôle : montrer le changement avant de l'appliquer. Aucune automatisation critique ne devrait pouvoir sauter cette étape.
Étape 4 — Revue et déploiement progressif
Toute automatisation nouvelle doit d'abord être exécutée sur un environnement de test représentatif, puis en canari sur un seul client réel avant généralisation. Un système de revue (pull request obligatoire, deux approbateurs pour les changements touchant la production) réduit le risque d'erreur silencieuse.
| Étape | Environnement | Validation requise |
|---|---|---|
| 1 | Sandbox isolé | Tests automatisés (lint, plan, dry-run) |
| 2 | Client pilote | Revue manuelle + surveillance renforcée 48h |
| 3 | Généralisation | Rollout progressif avec possibilité de rollback |
Sur le terrain
une automatisation de provisioning mal testée qui échoue à mi-parcours (ex. VM créée mais configuration Ansible interrompue) laisse souvent l'environnement dans un état incohérent difficile à nettoyer manuellement ; prévoir systématiquement une étape de vérification post-exécution (health check automatisé) qui confirme l'état final avant de considérer la tâche terminée.
Astuce
conservez un journal d'exécution horodaté (sortie complète de Terraform et Ansible) pour chaque provisioning, stocké de façon centralisée ; c'est souvent la première chose demandée lors d'un post-mortem sur un incident de provisioning.