Cette formation Ansible vous emmène du premier playbook jusqu'à la certification RHCE EX294, avec des labs reproductibles sur KVM/libvirt et un parcours pédagogique progressif. Public visé : sysadmins et DevOps qui veulent une compétence Ansible solide, pas un mémo généré par IA. Le socle est ansible-core 2.16+ (compatibilité Red Hat AU294 actuel — RHEL 10, AAP 2.5/2.6), testé jusqu'à ansible-core 2.18 pour les pratiques modernes. FQCN obligatoire, ansible-lint --profile production mandatory, idempotence non négociable.
Aller droit au but
Section intitulée « Aller droit au but »Au terme de ce parcours, vous saurez
Section intitulée « Au terme de ce parcours, vous saurez »- Provisionner et préparer un lab Ansible (4 VMs AlmaLinux 10) sur KVM/libvirt en moins de 5 minutes.
- Écrire des playbooks déclaratifs, idempotents et lisibles, conformes aux conventions 2026 (FQCN,
ansible-lint --strict). - Structurer du code réutilisable avec des rôles et des collections, versionnés sur Galaxy ou un dépôt Git interne.
- Gérer les secrets avec Ansible Vault et l'intégration HashiCorp Vault / OpenBao.
- Industrialiser avec ansible-navigator, Execution Environments, Molecule et CI/CD GitLab/GitHub Actions.
- Préparer et passer la certification RHCE EX294 (RHEL 9/10).
Mon retour d'expérience — pour ceux qui veulent comprendre
Section intitulée « Mon retour d'expérience — pour ceux qui veulent comprendre »Si l'une des cartes ci-dessus vous a déjà orienté, c'est parfait — vous êtes parti sur le bon pied. La suite de cette page s'adresse à ceux qui veulent comprendre la philosophie de la formation avant de plonger : pourquoi ces choix techniques, qu'est-ce que je défends, qu'est-ce que je vous interdis.
Je pratique Ansible depuis 2015. J'ai vu passer la version 1.x avant le rachat par Red Hat, l'arrivée des collections en 2.10, la bascule push → pull → containerisé avec les Execution Environments, et la disparition progressive des rôles standalone Galaxy v1. Cette formation condense ce que j'ai appris sur le terrain — pas ce que vous trouvez en compilant 30 articles Stack Overflow. Vous y trouverez des avis tranchés, des anti-patterns que je vous interdis, des récits d'incidents qui m'ont coûté des nuits, et le parcours exact que je recommande à un sysadmin qui veut viser la RHCE en 2026.
Analogie pour démarrer : un script Bash, c'est un employé qui suit les instructions sans rien retenir — relancez-le et il refait tout, ou il échoue parce que le paquet existe déjà. Ansible, c'est le contremaître expérimenté qui regarde l'état actuel, compare à l'état désiré, et n'agit que sur ce qui doit changer. C'est ça, l'idempotence — la propriété qui sépare un sysadmin junior d'un opérateur sérieux. Et c'est elle qui dicte 80 % des choix de cette formation.
Pourquoi Ansible reste un choix stratégique en 2026
Section intitulée « Pourquoi Ansible reste un choix stratégique en 2026 »Configurer 50 serveurs à la main ne passe pas l'échelle. Les scripts Bash idempotents sont un mythe — la moindre branche conditionnelle se transforme en piège, et le mainteneur d'origine quitte l'équipe avant la fin du semestre. Ansible résout le problème avec une promesse simple que personne d'autre n'a réussi à délivrer aussi proprement : vous décrivez l'état désiré dans des fichiers YAML versionnés, Ansible converge vos serveurs vers cet état en SSH, sans agent à maintenir, sans certificat à pousser, sans port à ouvrir.
| Sans Ansible | Avec Ansible |
|---|---|
| Cliquer/SSH dans 50 serveurs un par un | Un playbook, une commande, 50 serveurs |
| Espérer que prod = staging | Même playbook = même résultat |
| Documenter manuellement (et oublier) | Le code est la documentation |
| Passer 1 h à diagnostiquer une dérive | ansible-playbook --check --diff montre l'écart |
| Réécrire à chaque nouveau serveur | Inventory dynamique, rôles, collections |
Trois raisons pour lesquelles je continue de miser sur Ansible en 2026, malgré l'arrivée de Pulumi, le retour de Salt et les promesses de Crossplane :
- L'écosystème Red Hat est inégalé sur Linux d'entreprise. Quand vous administrez 200 RHEL/AlmaLinux, l'alignement avec la RHCE et avec Automation Platform vous fait gagner des mois sur l'industrialisation.
- L'agentless reste un argument décisif. Auditer une fleet sans installer 12 daemons supplémentaires, sans nouvelle PKI à maintenir, sans port à ouvrir au-delà de SSH — la dette opérationnelle est minimale, et c'est ce qui compte sur 5 ans.
- La courbe d'apprentissage tient ses promesses. Un sysadmin Linux compétent produit son premier playbook utile en une journée. C'est aussi pourquoi Ansible résiste à la mode : la pédagogie n'est pas verrouillée par la complexité.
Mais Ansible n'est pas la bonne réponse à tout. Pour provisionner du Cloud, restez sur Terraform. Pour orchestrer des conteneurs, restez sur Kubernetes. Ansible commence là où Terraform s'arrête : une fois la VM existe, c'est Ansible qui la configure proprement, idempotemment, en tenant compte de l'état réel. Mélanger les rôles est une erreur que je vois trop souvent — un playbook qui crée des VMs EC2 avec ec2_instance finit toujours par dériver parce qu'Ansible n'a pas de state à comparer.
Ce que cette formation défend
Section intitulée « Ce que cette formation défend »Cette formation a des opinions assumées. Voici ce que je défends et ce que vous trouverez ici, contrairement à 80 % des tutoriels Ansible que j'ai lus :
L'idempotence n'est pas négociable. Un playbook qui affiche changed=N à chaque run est un playbook cassé — peu importe qu'il « fonctionne ». Vous y reviendrez dans 6 mois, vous le relancerez, il redémarrera des services, il invalidera des caches CDN, il fera perdre confiance à votre équipe. La règle est simple : ansible-playbook site.yml; ansible-playbook site.yml | grep changed= doit rendre la deuxième fois changed=0. Sinon, on corrige.
Le FQCN est obligatoire partout. Pas de copy:, pas de dnf:, pas de service:. Toujours ansible.builtin.copy, ansible.builtin.dnf, ansible.builtin.systemd_service. C'est ce qu'attend ansible-lint --profile production, c'est ce qu'attend la RHCE 2026, et c'est ce qui empêche les conflits de noms quand vous installez community.general. Un guide Ansible qui en 2026 vous montre encore copy: src=… dest=… (ancienne syntaxe inline) vous tire vers le bas.
ansible-lint --profile production est mandatory dès le premier playbook. Pas en CI seulement, dès le pre-commit hook local. La règle de base : un playbook qui ne passe pas le profile production ne sort pas de la machine du dev. C'est ce qui transforme un playbook « ça compile chez moi » en code maintenable.
Le push SSH classique est la voie royale pour 95 % des cas. Le mode pull (ansible-pull) est sexy, mais il est niche : Edge, IoT, fleet >1000 nœuds. Pour un datacenter classique de moins de 500 serveurs, restez sur push. Vous gagnerez en visibilité (logs centralisés), en compatibilité AAP, et en simplicité d'audit.
Les Execution Environments ne sont pas optionnels en 2026. Si vous visez AAP ou la RHCE moderne, vous devez maîtriser ansible-navigator + creator-ee. Le venv local Python reste valide pour itérer en dev, mais shipper sans EE en 2026 vous met en dette technique immédiate.
Ce que je vous interdis
Section intitulée « Ce que je vous interdis »Voici ce que je refuse de voir dans le code de mes apprenants — et ce que je vous interdis dès le premier playbook :
host_key_checking = False en production. « Mais c'est juste pour le lab… » Non. Ce paramètre se transforme en habitude, vous le copiez dans ansible.cfg du projet prod, et le jour où un attaquant fait du man-in-the-middle, vous l'avez laissé entrer. Solution : provisionnez les known_hosts proprement via cloud-init ou un playbook bootstrap. Ça prend 5 minutes, ça vaut une nuit de sommeil.
become_method: su sauf cas exceptionnel. sudo est plus auditable, mieux logué, plus restreint. J'ai vu un playbook utiliser su parce que « ça marchait sur le poste du dev » — résultat, en prod le mot de passe root passait dans l'env Ansible, illisible aux logs sudo. Solution : become_method: sudo + become_user ciblé + NOPASSWD limité aux commandes nécessaires.
shell: sans creates: ni changed_when:. C'est l'antipattern n°1 chez les débutants. Un shell: "echo lab > /tmp/marker" qui retourne changed=1 à chaque run ment sur l'état du système. Solution : creates: /tmp/marker rend la tâche idempotente. Sans alternative possible (commande purement informationnelle), changed_when: false documente que la tâche est de lecture.
lineinfile: sans regexp:. Premier run : ajout de max_connections = 100. Six mois plus tard, vous changez en 200. Le fichier contient maintenant les deux lignes. J'ai vu cet incident en prod chez un client — la base PostgreSQL prenait la valeur de la dernière ligne, mais celle d'avant restait dans le fichier en train de pourrir le diff Git. Solution systématique : regexp: '^max_connections\s*=', toujours, sans exception.
Un secret en clair dans Git, même dans un commit revert. git revert ne supprime pas l'historique. Le secret reste accessible via git log -p, et GitHub indexe ce contenu pour quiconque a accès lecture au repo. Solution : Ansible Vault dès le premier secret, .vault_password en mode 0600 et gitignored dès la création du dépôt. Si le secret est déjà fuité, rotater le secret — ne pas se contenter de revert.
Pousser en prod sans --check --diff au préalable. --check simule sans appliquer, --diff montre l'écart précis. C'est gratuit, c'est rapide, ça évite 90 % des incidents que j'ai vus en intervention. Aucune excuse valable pour pousser un playbook directement en prod sans avoir relu le diff sur 1-2 hôtes pilotes.
Sécurité non négociable
Section intitulée « Sécurité non négociable »La sécurité Ansible n'est pas une option à activer plus tard. Elle se décide au premier commit du repo. Voici la chaîne complète que je défends :
.vault_password mode 0600, gitignored, sauvegardé hors Git. Mode 0644 = autres users du système peuvent voler le mot de passe. Mode 0700 sur le dossier parent = même protection. .gitignore racine dès git init : .vault_password*, *.vault, .env. Si un dev ouvre une PR avec un de ces fichiers staged, le pre-commit hook bloque.
no_log: true sur toute tâche manipulant un secret en argument shell. Un command: 'curl -H "Authorization: Bearer $TOKEN"' sans no_log affiche le token en -v, dans les logs CI, dans journalctl du runner. J'ai vu un token Slack fuiter exactement comme ça en 2023 — recovery via rotation immédiate, mais 30 minutes de panique. Pattern : no_log: true au niveau task (pas dans le module), systématique sur toute task command/shell/uri/copy: content: qui touche à un credential.
FQCN obligatoire pour bloquer le typosquatting. En 2026, des attaques supply chain visent les noms de modules courts (copy: détourné par un module pirate dans une collection malveillante). Le FQCN explicite (ansible.builtin.copy) verrouille la collection source. Combiné avec requirements.yml pinné par version semver et idéalement par signature GPG, vous limitez votre surface d'attaque.
Secrets externalisés dès que vous dépassez l'équipe. Ansible Vault est parfait pour les configs versionnées d'un projet. Mais dès que plusieurs équipes consomment les mêmes secrets, ou que la rotation devient régulière, basculez sur HashiCorp Vault / OpenBao avec lookup community.hashi_vault.vault_kv2_get. La règle : Ansible Vault pour les fichiers, HashiCorp Vault pour les secrets dynamiques (DB credentials éphémères, certificats PKI, tokens AWS STS).
Audit log en CI/CD systématique. Chaque exécution ansible-playbook en prod doit produire un artifact JSON (via ansible-navigator run --pae true) horodaté, signé, archivé 90 jours minimum. C'est ce qui permet de répondre « qui a déployé quoi sur quel host à quelle heure » lors d'un incident, sans deviner.
Productivité au quotidien
Section intitulée « Productivité au quotidien »Ce que j'ai mis 2 ans à automatiser et que je recommande dès le premier projet :
Un ansible.cfg projet à la racine du repo. forks=20, pipelining=True, ssh_args = -o ControlMaster=auto -o ControlPersist=60s, stdout_callback = yaml, callbacks_enabled = ansible.posix.profile_tasks, ansible.posix.timer. Gain typique : -50 % sur le temps de run sur une fleet de 30 hosts. Pas optionnel — c'est de la productivité brute.
ansible-lint --profile production en pre-commit hook. Le hook tourne 3 secondes en local, bloque les régressions FQCN, mode quoté, changed_when manquant, modules dépréciés. Coût d'install : 30 secondes. Bénéfice : zéro PR rejetée pour un bug évitable. Configuration recommandée : pre-commit-config.yaml avec ansible-lint, yamllint, detect-secrets.
--check --diff en premier réflexe sur chaque modification. Avant de pousser, je lance toujours ansible-playbook site.yml --check --diff --limit web1.lab pour voir ce qui changerait sur un seul host pilote. Ça prend 30 secondes, ça révèle 90 % des bugs avant qu'ils touchent prod.
Le débogueur Ansible (debugger: on_failed) en local. Quand une tâche plante au milieu d'un playbook de 200 lignes, rejouer tout depuis le début est une perte de temps. debugger: on_failed ouvre un REPL au moment de l'échec, vous modifiez la variable à la volée, vous tapez redo, ça passe. Gain typique : 15 minutes par bug complexe. Mais jamais en CI — le REPL freeze indéfiniment sans stdin.
Tests Molecule sur les rôles dès qu'ils ont 3+ utilisateurs. Un rôle utilisé seulement par vous peut survivre sans tests. Un rôle consommé par 3 équipes différentes doit avoir Molecule + scénarios multi-distros + tests d'idempotence. Sans ça, le premier breaking change casse silencieusement les downstream.
Quiz interactif (633 questions) régulièrement. C'est ce qui me garde frais sur les pièges de précédence des variables, les filtres Jinja2 rares, et les options nouvelles d'ansible-test sanity. 15 minutes de quiz par semaine valent une demi-journée de relecture passive.
Ansible vs alternatives
Section intitulée « Ansible vs alternatives »J'évite religieusement les guerres de chapelles, mais voici ma position assumée sur les outils concurrents :
Salt : techniquement excellent (architecture push et pull, états compilables, ZeroMQ rapide), mais l'écosystème s'est rétréci depuis 2020. Si vous démarrez en 2026, je ne recommande pas Salt — la communauté est plus petite, les modules tiers se font rares, et le rachat par VMware puis Broadcom n'a pas aidé.
Chef : DSL Ruby puissant, mais j'évite sur les nouveaux projets. La courbe d'apprentissage Ruby est un coût caché énorme pour des sysadmins Linux qui n'écrivent pas Ruby au quotidien. Ansible YAML reste plus accessible et la productivité est meilleure pour 90 % des cas usuels.
Puppet : encore très utilisé en prod historique, mais je ne le recommande pas pour un nouveau projet en 2026. Le modèle agent + serveur + certificat ajoute une dette opérationnelle qu'Ansible évite. Si vous héritez de Puppet, gardez-le ; si vous démarrez, choisissez Ansible.
Pulumi / SDK Cloud : excellent pour le provisioning (équivalent Terraform en mieux pour certains), mais ce n'est pas un concurrent d'Ansible. Les deux outils se complètent : Pulumi/Terraform crée la VM, Ansible la configure.
Crossplane : K8s-native, intéressant si votre stack est 100 % Kubernetes. Hors de ce cas, trop d'overhead pour un gain limité par rapport à la combo Terraform + Ansible classique.
Ce que je vous interdis : utiliser deux outils qui se marchent dessus. Ansible OU Salt, pas les deux. Terraform OU Pulumi, pas les deux. La cohérence d'outillage vaut bien plus que la « meilleure techno » sur chaque maillon.
Ce parcours prépare à quoi
Section intitulée « Ce parcours prépare à quoi »| Objectif | Compétence développée | Preuve |
|---|---|---|
| Faire tourner un premier playbook | Lab KVM, inventaire, ad-hoc, premier playbook | Premiers pas |
| Écrire du code propre | YAML, plays, variables, facts, conditions, templates Jinja2 | Écrire du code |
| Réutiliser et partager | Rôles, collections, Galaxy, Automation Hub | Sections roles/ et collections/ |
| Sécuriser les secrets | Vault, multi vault-id, intégration HashiCorp Vault / OpenBao | Section secrets-vault/ |
| Industrialiser | ansible-navigator, EE, Molecule, CI/CD | Sections execution-environments/, troubleshooting/ |
| Valider officiellement | RHCE EX294 (RHEL 9/10) — examen Red Hat | Préparation RHCE |
Compatibilité : ansible-core, AAP, Execution Environments
Section intitulée « Compatibilité : ansible-core, AAP, Execution Environments »Cette formation utilise ansible-core 2.18+ (le moteur open source) sur AlmaLinux 10 (équivalent RHEL 10). Tous les exemples fonctionnent à l'identique sur Rocky Linux 10, RHEL 10, Fedora ou Ubuntu 24.04 — les rares différences sont signalées par un encadré dédié.
Ansible Automation Platform (AAP) 2.6+ est l'offre payante de Red Hat qui ajoute par-dessus ansible-core un orchestrateur web (AWX/Controller), un dépôt de contenus certifié (Automation Hub), un service de mesh (Automation Mesh) et de la gouvernance (RBAC, audit). La formation couvre AAP en section dédiée, mais l'essentiel — playbooks, rôles, collections, Vault — fonctionne pareillement avec ansible-core seul. Mon avis : ne payez pas AAP avant d'avoir une fleet de 500+ hosts ou un besoin réel de RBAC fin. Pour une équipe DevOps de 10 personnes sur 50 serveurs, ansible-core + GitLab CI couvre tout.
Les Execution Environments sont des images conteneur OCI qui packagent ansible-core + collections + dépendances Python. C'est l'évolution moderne du « lance-Ansible » et le mode d'exécution par défaut depuis AAP 2.0. Je les rends obligatoires dès qu'on shippe — pour le dev local, le venv reste plus rapide à itérer.
Mode pull alternatif : par défaut, Ansible fonctionne en push SSH (control node → cibles). Pour les architectures Edge / IoT / GitOps strict (nœuds derrière NAT, fleet >1000 nœuds, bootstrap immuable cloud-init), il existe un mode pull où la cible récupère son playbook depuis Git et s'auto-configure — voir ansible-pull (GitOps Edge — hors EX294). Pattern niche, non testé à la RHCE.
Validation et entraînement
Section intitulée « Validation et entraînement »- Quiz Ansible interactif : 633 questions catégorisées par chapitre, alignées sur le programme RHCE 2026. Niveau adaptable (débutant → expert). Mon conseil : 15 min/jour pour rester frais.
- Lab reproductible : le dépôt
ansible-trainingcontient l'infrastructure KVM + 103 labs progressifs structurés par section, avec tests pytest+testinfra et CLIdsoxlabqui suit votre progression dans une SQLite locale. Vous clonez, lancezmake bootstrap && make provision && make hosts-add, vérifiez avecmake verify-conn, etdsoxlab nextvous indique le prochain lab à attaquer. - Mock RHCE complet : 12 tâches en 4h chrono couvrant les 12 catégories EX294 — à passer deux fois minimum avant de réserver l'examen réel.
Prochaines étapes
Section intitulée « Prochaines étapes »FAQ : Questions Fréquentes
Section intitulée « FAQ : Questions Fréquentes »sudo dnf install pipx && pipx ensurepath && pipx install --include-deps ansible. Évitez sudo pip install (pollution Python système) et apt install ansible (souvent dépassé). pipx isole, les mises à jour sont atomiques.&nom) permettent de marquer un nœud, et les alias (*nom) de le réutiliser ailleurs. L'opérateur merge << fusionne les valeurs en autorisant l'override. Utile pour partager des options JVM, ports ou configurations entre plusieurs apps. Attention : tous les parsers YAML ne supportent pas les ancres complexes — vérifier la compatibilité Ansible.