Le premier déploiement Ansible était élégant : un rôle webstack, trois groupes staging, prod, bastion. Un an plus tard, l'inventaire contient prod-legacy, douze blocs host_vars/prod-03.yml « temporaires », et un when: inventory_hostname == 'prod-03' dans le rôle nginx. Le playbook passe — mais personne ne sait plus quelle config est la norme et quelle config est la rustine.
Ansible scale mal quand chaque exception reste locale au lieu de remonter en variable ou en rôle optionnel documenté. Le piège classique : un playbook qui passe en CI mais documente douze rustines host_vars. Un nouvel ingénieur ne sait plus quelle config est norme. L'objectif n'est pas un run vert — c'est qu'un second ansible-playbook ne change rien si la machine n'a pas dérivé. Sans cette discipline, vous automatisez la confusion plutôt que la configuration désirée — et chaque déploiement ajoute une rustine de plus.
Inventaire, group_vars et hiérarchie claire
Structure recommandée : inventaires par environnement, group_vars/all.yml, group_vars/web.yml, rôles découplés. group_vars pour tout ce qu'un groupe partage. host_vars réservé aux vraies exceptions (adresse IP dédiée, certificat client) — avec commentaire et ticket. Pas de when sur hostname dans les rôles — préférez nginx_extra_vhosts en variable.
Chaque
when: inventory_hostname ==est une dette qui crie.
Rôles, tags et surface de changement
Découpez par responsabilité : common, web, db_client. Les tags limitent le rayon d'impact en production. Documentez defaults dans roles/x/defaults/main.yml — overrides dans group_vars seulement. Un rôle qui mélange nginx, PHP et firewall devient impossible à tester isolément.
Vault, SSH et accès bastion
Chiffrez secrets avec ansible-vault encrypt. Clés SSH via agent — pas de clé root partagée. Bastion unique, ProxyJump, sudo limité. Alignez avec ce que votre hébergeur VPS permet — certains bloquent l'accès root direct, d'autres imposent une clé par environnement.
Idempotence cassée : symptômes
shell: curl ... | bash à chaque run. copy sans checksum. service: state=restarted systématique. Corrigez en modules déclaratifs. Dérive manuelle → importez en code ou bloquez SSH direct. Une machine modifiée à la main contredit l'automatisation — et personne ne sait quelle source fait foi.
CI, Molecule et parité staging
Pipeline : ansible-lint, yamllint, Molecule converge deux fois — second run doit rapporter 0 changed. Staging doit ressembler à prod (mêmes rôles, vars différentes). Sans parité, vous testez une config qui n'existe pas en production. Versionnez l'inventaire dans le même dépôt que les rôles — un inventaire local non versionné est la source la plus fréquente de « ça marchait sur ma machine » en prod.
Refactoriser sans paralyser l'équipe
Comptez les host_vars et les when: hostname — si ça monte, planifiez une pause refactor. Remontez les exceptions en variables groupées documentées, une par sprint. Ansible exécute vite une collection d'exceptions — il ne les corrige pas.
Sur un VPS ou bare metal, la configuration diverge aussi par dérive manuelle : un correctif SSH oublié, un paquet installé à la main. Bloquer l'accès direct en production — sauf urgence documentée — force le retour vers le code. Croisez avec TLS et durcissement : les mêmes principes de configuration déclarative s'appliquent au-delà d'Ansible seul.
Le sommet : l'automatisation qui cache l'incohérence
Décider et avancer sans angle mort
Refactorisez les exceptions en variables groupées documentées, une par une, avec ticket de suivi. Ajoutez Molecule en intégration continue et exigez zéro changement au second run. Chiffrez tous les secrets avec ansible-vault et révoquez tout secret déjà commité en clair. Documentez le bastion et les clés SSH par environnement — qui a accès, quelle clé, quelle rotation. Comptez les host_vars et les when: hostname : si ça monte, pause refactor. Comparez les VPS adaptés à Ansible via l'annuaire et le comparateur.
Questions fréquentes
Rôles ou playbook monolithique ?
Rôles réutilisables plus group_vars ; éviter le playbook fourre-tout. Un playbook monolithique devient une collection d'exceptions non testées dès qu'il dépasse quelques rôles.
Comment tester Ansible avant prod ?
Molecule avec second run à zéro changement, staging paritaire, lint en CI. --check seul ne suffit pas — il ignore certains effets de bord.
Ansible gère-t-il bien le secret ?
ansible-vault obligatoire ; pas de secrets clairs dans git. Révoquez tout secret déjà exposé dans l'historique — le chiffrement ultérieur n'efface pas le passé.
Pourquoi mon playbook n'est-il pas idempotent ?
Modules shell/command non déclaratifs, redémarrages forcés, exceptions par hôte. Chaque when: inventory_hostname == dans un rôle est un signal d'alarme.
Un inventaire sain se lit en groupes — pas en anecdotes par serveur.