L'écosystème Ansible
Résumé : Ansible n'est pas un outil isolé. Autour de lui gravite un écosystème riche : Galaxy pour partager des rôles, AWX et Ansible Automation Platform pour l'interface d'entreprise, Collections pour organiser les modules, Molecule pour tester. Cette leçon pose la carte complète, puis compare honnêtement Ansible à Terraform, Puppet et Chef pour savoir quand choisir quoi.
1. Vue d'ensemble de l'écosystème
L'ordre d'apprentissage recommandé :
- Ansible Core (playbooks et modules de base)
- Galaxy (télécharger des rôles communautaires)
- Collections (comprendre l'organisation moderne)
- AWX ou AAP (interface et gestion multi-équipe)
- Molecule (tests professionnels)
Ce cours vous donne la compréhension conceptuelle de tous ces éléments. La maîtrise pratique est l'objet du Cours Premium Ansible.
2. Ansible Galaxy — le catalogue mondial
Ansible Galaxy est le registre public géré par Red Hat. C'est l'équivalent de Docker Hub ou npm pour Ansible.
Chiffres 2026 :
- Plus de 30 000 rôles publiés.
- Plusieurs centaines de collections officielles.
- Plusieurs dizaines de millions de téléchargements par mois.
Bonne pratique : privilégiez toujours les rôles avec beaucoup d'étoiles, une communauté active et une licence claire. Les collections officielles (Cisco, VMware, Amazon…) sont le choix le plus sûr pour les besoins spécialisés.
3. Collections — l'organisation moderne depuis 2020
Historiquement, tous les modules Ansible étaient regroupés dans Ansible Core — plusieurs milliers de modules maintenus dans un même dépôt. Le projet devenait ingérable.
En 2020, Red Hat a introduit les Collections : une nouvelle façon d'organiser modules, rôles et plugins.
Bénéfice majeur : chaque éditeur (Cisco, VMware, Red Hat, Amazon…) maintient sa collection à son propre rythme. Ansible Core reste léger, les cycles de sortie sont indépendants.
En 2026, 99 % des nouveaux développements Ansible passent par les Collections. Ansible Core lui-même se réduit à un moteur minimal et une poignée de modules essentiels.
4. AWX et Ansible Automation Platform — les interfaces web
Lancer un playbook depuis la ligne de commande fonctionne pour un dev seul. Pour une équipe, il faut :
- Une interface web pour lancer les playbooks.
- Une gestion des droits (qui peut lancer quoi sur quel serveur).
- Un historique des exécutions passées.
- Une planification (lancer un playbook toutes les nuits à 3h).
- Une intégration avec Git (récupérer automatiquement les playbooks depuis un dépôt).
C'est le rôle d'AWX et d'Ansible Automation Platform.
Fonctionnalités clés d'AWX et AAP :
Conseil pratique : pour apprendre, installez AWX sur une petite machine ou en cluster minikube. C'est gratuit, complet et représentatif de ce qu'utilisent les grandes équipes.
5. Molecule — tester ses rôles comme du vrai code
En 2016 est apparu Molecule, un outil qui teste automatiquement les rôles Ansible dans des environnements éphémères (conteneurs Docker, machines virtuelles, cloud).
Molecule intégré à un pipeline CI (GitHub Actions, GitLab CI) rend vos rôles aussi fiables qu'un vrai projet logiciel. C'est une pratique essentielle dans les équipes qui prennent Ansible au sérieux.
6. Ansible vs Terraform — la confusion qu'il faut lever
C'est LA question la plus fréquente en entretien. Ces deux outils sont souvent utilisés ensemble, mais font des choses différentes.
Tableau comparatif Ansible vs Terraform :
| Critère | Terraform | Ansible |
|---|---|---|
| Objectif principal | Provisionner l'infrastructure | Configurer et déployer |
| Langage | HCL (langage déclaratif propre) | YAML |
| Modèle de fonctionnement | Déclaratif pur (state file) | Impératif idempotent |
| Cas d'usage type | Créer 10 machines AWS, un load balancer, un DNS | Installer nginx sur ces 10 machines, configurer TLS |
| Support multi-cloud | Excellent (200+ providers) | Bon via collections cloud |
| Gestion des changements | Voit ce qui a changé via un state file | Applique l'état voulu à chaque run |
| Éditeur principal | HashiCorp (rachat IBM 2024) | Red Hat / IBM |
| Complémentarité | Souvent utilisé AVANT Ansible | Souvent utilisé APRÈS Terraform |
Le pattern 2026 dominant :
- Terraform crée le socle : réseaux, machines virtuelles, DNS, load balancers.
- Ansible configure ce qui tourne : paquets, services, applications, secrets.
Peut-on faire du provisioning avec Ansible ? Oui, mais moins bien que Terraform. Ansible a des modules AWS/GCP/Azure, mais Terraform reste beaucoup plus complet et robuste pour cette tâche.
Peut-on faire de la configuration avec Terraform ? Oui via remote-exec ou cloud-init, mais très limité. Ansible est infiniment plus puissant pour la configuration détaillée.
Verdict : chacun sur son terrain, les deux ensemble.
7. Ansible vs Puppet, Chef, SaltStack
Reprenons brièvement le tableau de la leçon 4, cette fois avec l'angle écosystème.
Recommandation pour 2026 :
- Vous démarrez un projet → Ansible sans hésiter.
- Vous avez déjà du Puppet en place → maintenir tant que ça fonctionne, sans investir davantage.
- Vous avez du Chef → planifier une migration vers Ansible ou Puppet.
- Vous avez du SaltStack → évaluer selon les compétences internes ; sinon, migration vers Ansible.
8. Où trouver du contenu Ansible de qualité
Une fois qu'on comprend l'écosystème, savoir où chercher devient essentiel.
Conseil : le livre « Ansible for DevOps » de Jeff Geerling est le classique absolu — traduit dans plusieurs langues, mis à jour chaque année. Si vous devez lire un seul livre sur Ansible, c'est celui-là.
Retenir en 30 secondes
- Ansible Galaxy = catalogue mondial de rôles et collections partagés.
- Collections = organisation moderne des modules par éditeur, standard depuis 2020.
- AWX = interface web open source. Ansible Automation Platform = version commerciale Red Hat.
- Molecule = tester ses rôles automatiquement en conteneur ou VM éphémère.
- Ansible vs Terraform : Terraform provisionne, Ansible configure. Les deux ensemble dans le pattern moderne.
- Ansible est en croissance, Puppet stable, Chef en déclin, SaltStack en niche.
Suivant : Cas d'usage réels : provisioning, configuration, patch, sécurité →