Vagrant : Le duel Ansible vs Ansible_Local (et la vérité sur Windows)
Par Nicolas DELAHAYE | v.1974 | Architecte & Automation
STATUS: ARCHITECTURE_DECISION_REQUIRED
Dans un Vagrantfile, la différence tient à six lettres et un underscore : _local.
Pourtant, choisir entre config.vm.provision "ansible" et config.vm.provision "ansible_local" n'est pas une question de goût. C'est une décision d'architecture qui définit qui peut (ou ne peut pas) exécuter votre code.
1. Le mode Classique : config.vm.provision "ansible"
C'est l'approche puriste. Ici, l'Hôte est le Maître, la VM est l'Esclave.
[ VOTRE MAC/LINUX ] --(SSH)--> [ VM CIBLE ]
Vagrant va chercher l'exécutable ansible-playbook installé sur votre machine physique et lui demande de se connecter à la VM pour la configurer.
- ✅ Les avantages : C'est propre. Vous utilisez votre Ansible centralisé, vos secrets (Vault), vos clés SSH et vous ne polluez pas la VM avec l'installation d'Ansible.
- ❌ Le problème : Cela exige qu'Ansible soit installé sur la machine hôte. Et si votre collègue est sous Windows... vous êtes dans une impasse.
2. Le mode Pragmatique : config.vm.provision "ansible_local"
C'est l'approche "Contained". Ici, la VM est à la fois Maître et Esclave.
1. Vagrant démarre la VM.
2. Vagrant installe Ansible DANS la VM (Guest).
3. Vagrant monte vos playbooks dans
/vagrant.4. La VM exécute Ansible sur elle-même (
localhost).
- ✅ Les avantages : Zéro dépendance. Que vous soyez sur Mac, Linux ou Windows, ça marche. Le lab est 100% autonome et reproductible.
- ❌ Le problème : Le premier démarrage est plus lent (il faut installer Ansible) et c'est conceptuellement étrange pour un puriste de voir un serveur se configurer lui-même.
3. Le Mur de la Réalité : Pourquoi Ansible ne tourne pas sur Windows
J'entends souvent : "Mais pourquoi on n'installe pas juste Ansible sur Windows pour utiliser le mode classique ?".
La réponse est brutale : C'est impossible. Ce n'est pas un bug, c'est une conception.
Pourquoi ? (Le point technique)
Ansible est écrit en Python, mais son cœur repose sur des primitives système POSIX : le fork() de processus, la gestion des descripteurs de fichiers, les pseudo-terminaux (pty) et un modèle de permissions SSH spécifique.
L'API Win32 de Windows fonctionne différemment. Elle ne possède pas ces concepts nativement. Résultat : Ansible ne peut pas fonctionner en tant que Control Node (le cerveau) sur Windows. Il peut seulement gérer des cibles Windows.
Ce que dit la documentation officielle
"Running Ansible from a Windows control machine is not a goal of the project."
"Ansible cannot run on Windows as the control node due to API limitations on the platform."
-- Docs officielles Ansible & FAQ
// Note : Oui, WSL (Windows Subsystem for Linux) existe. Mais cela ajoute une couche de complexité réseau avec Vagrant et n'est pas "supporté officiellement" pour la production par Red Hat.
4. Le Verdict de l'Architecte
Dans mon contexte de préparation aux certifications CKA/CKS, je dois pouvoir casser et reconstruire mon environnement en 5 minutes, que je sois sur mon MacBook Pro M3 ou que je partage le code avec un collègue sous Windows.
Mon choix est donc sans appel : ansible_local.
| Scénario | Recommandation |
|---|---|
| Équipe 100% Linux/Mac | ansible (plus rapide) |
| Équipe mixte (Win/Lin/Mac) | ansible_local (obligatoire) |
| Lab pédagogique / Formation | ansible_local (zéro pré-requis) |
| CI/CD Pipeline | ansible (l'agent CI est sous Linux) |
// SYNTHÈSE :
Utiliser
ansible_localn'est pas un "hack" ou une "verrue". C'est un pattern de portabilité. En DevSecOps, la reproductibilité de l'environnement prime sur la pureté de l'implémentation. Mieux vaut un script qui tourne partout qu'un script "parfait" qui ne tourne que sur ma machine.