Premiers pas avec Ansible : du lab vide au premier playbook

Cette section transforme la théorie de Découvrir en pratique. En une à deux heures, vous montez un lab Ansible reproductible (1 control node + 3 managed nodes sur KVM/libvirt), écrivez votre premier inventaire, distribuez vos clés SSH, lancez des commandes ad-hoc, écrivez votre premier playbook et apprenez à décoder les erreurs typiques. À la fin, vous avez un environnement de travail fonctionnel pour toute la suite du parcours RHCE EX294 — chaque commande est exécutée sur des VMs réelles, jamais en théorie.

Aller droit au but

🚀 Préparer le lab KVM 4 VMs AlmaLinux 10 sur libvirt avec cloud-init et baux DHCP statiques

📚 Premier inventaire + ad-hoc INI minimal, ansible-inventory --graph, ping/setup/dnf en commande ad-hoc

🎯 Premier playbook Installer nginx + ouvrir port 80 + démarrer service — anatomie ligne par ligne

🔥 Debug des 10 erreurs typiques Permission denied, MODULE FAILURE, indentation YAML, Failed to connect…

Pressé ? Voici le chemin du premier playbook en 30 secondes

1. make bootstrap && make provision dans le lab ansible-training → 4 VMs prêtes.
2. Inventaire INI minimal : [webservers]\nweb1.lab\nweb2.lab dans inventory/hosts.
3. ansible all -m ansible.builtin.ping → 4 pong, validation de la chaîne SSH + Python.
4. Premier playbook : install nginx + service started + firewalld port 80.
5. Relancer le playbook : changed=0 au second run = idempotence vérifiée.

Ce que vous allez apprendre

• Provisionner 4 VMs AlmaLinux 10 sur KVM/libvirt avec virt-install + cloud-init en quelques minutes ;
• Préparer les managed nodes (compte sudoers, clé SSH, Python 3, firewall, NTP) — la base technique attendue par la RHCE ;
• Écrire votre tout premier inventaire en INI puis en YAML, et le valider avec ansible-inventory --graph ;
• Connecter Ansible à votre lab via SSH par clé, sans saisir de mot de passe à chaque commande ;
• Lancer des commandes ad-hoc (ansible all -m ping, ansible web -m service -a "...") sur les patterns d’hôtes ;
• Écrire votre premier playbook idempotent : installer nginx, ouvrir le port 80, démarrer le service, vérifier changed=0 au second run ;
• Décoder les 10 erreurs fréquentes (Permission denied (publickey), MODULE FAILURE, indentation YAML, Failed to connect…).

Prérequis

Avant d’attaquer cette section, vous devez avoir :

• Lu et compris la section Découvrir Ansible (idempotence, push SSH, ansible.cfg) ;
• Installé ansible-core sur votre poste de contrôle (cf. Installer Ansible) ;
• Une distribution Linux récente (Fedora 42+, Ubuntu 24.04+) avec KVM/libvirt opérationnel et virt-install disponible ;
• Au moins 8 Go de RAM libre et 40 Go d’espace disque pour héberger 4 VMs AlmaLinux ;
• Une paire de clés SSH (Ed25519 recommandé). Si ce n’est pas fait, suivez d’abord Créer et gérer des clés SSH.

Pas de KVM disponible ?

Si votre poste ne supporte pas KVM (Mac M1/M2, Windows sans WSL2-KVM), vous pouvez adapter le lab à Vagrant + VirtualBox, multipass, Docker (avec un docker-compose qui simule des hôtes SSH) ou des VMs cloud (Hetzner, OVH). Les commandes Ansible ne changent pas — seule l’infrastructure d’hébergement diffère.

Pas de lab = pas de progression

J’ai vu plusieurs candidats RHCE rater l’examen parce qu’ils avaient « lu la doc » sans jamais provisionner un lab. Lire un playbook ne le fait pas tourner. Lancer ansible-playbook 50 fois, débugger 20 erreurs SSH, voir changed=0 apparaître pour la première fois — c’est ça qui construit la compétence. Si vous lisez cette section sans monter votre lab, vous perdez votre temps.

---

Mon retour d’expérience — pour ceux qui veulent comprendre

Si l’une des cartes en haut de page vous a déjà orienté, vous êtes parti sur le bon pied. La suite de cette page s’adresse à ceux qui veulent comprendre la philosophie de cette section : pourquoi je pousse le lab KVM/libvirt plutôt que Docker, pourquoi l’inventaire INI avant YAML, et pourquoi ansible all -m ping est le rite de passage obligatoire.

J’ai animé plusieurs formations Ansible où la moitié de la première journée se passait à dépatouiller des labs cassés : Vagrant qui plante, Docker SSH qui refuse les clés, VMs cloud qui timeout. Tout ce temps perdu n’apprend pas Ansible — il enseigne juste que l’outil de virtualisation choisi était mauvais. Le lab KVM/libvirt que je propose ici est testé, reproductible, et tient en 5 minutes — vous attaquez le vrai sujet (Ansible) immédiatement.

Le parcours en 7 étapes

Le parcours est séquentiel : chaque page suppose acquis ce qui précède. Comptez environ 30 minutes par page la première fois, moins lors des révisions.

1. Préparer le lab KVM Créer 4 VMs AlmaLinux 10 (control-node, web1, web2, db1) sur libvirt avec cloud-init et baux DHCP statiques

2. Sous le capot — managed nodes (optionnel) Ce que make provision fait pour vous : 5 prérequis Python/SSH/sudo/firewall/NTP, playbook décortiqué, module raw

3. Premier inventaire INI minimal puis YAML équivalent, vérification avec ansible-inventory --graph et --list

4. Première connexion SSH ssh-keygen, ssh-copy-id, ansible all -m ping — la première chaîne fonctionnelle bout en bout

5. Commandes ad-hoc Maîtriser ansible -m sur des patterns d'hôtes : ping, setup, dnf, service, copy, file — objectif RHCE explicite

6. Premier playbook Installer nginx + ouvrir port 80 + démarrer le service. Anatomie ligne par ligne, ré-exécution idempotente

7. Debug des premières erreurs Tableau erreur → cause → fix sur les 10 messages les plus fréquents (Permission denied, MODULE FAILURE…)

La topologie cible du lab

Le lab utilisé tout au long de cette section et de la suite du parcours est la topologie RHCE de référence :

Hôte	IP	Rôle	Ressources
control-node.lab	10.10.20.10	Poste Ansible (push SSH)	2 GiB RAM / 2 vCPU / 20 GiB disque
web1.lab	10.10.20.21	Serveur web (groupe webservers)	1 GiB RAM / 1 vCPU / 10 GiB disque
web2.lab	10.10.20.22	Serveur web (groupe webservers)	1 GiB RAM / 1 vCPU / 10 GiB disque
db1.lab	10.10.20.31	Base de données (groupe dbservers)	1.5 GiB RAM / 1 vCPU / 15 GiB disque

Glissez pour voir

Les 4 VMs sont sur un réseau libvirt isolé lab-ansible en 10.10.20.0/24, avec NAT sortant et baux DHCP statiques (les MACs sont fixées dans le réseau libvirt pour garantir des IPs stables sans toucher à NetworkManager).

Pourquoi cette topologie ?

Trois groupes (webservers, dbservers, rhce_lab), un control node externe, deux hôtes dans le même groupe (web1 et web2) pour exercer les patterns d’hôtes et la délégation. C’est la topologie minimale qui couvre 80 % des objectifs RHCE EX294 sans sur-dimensionner le lab.

Ce que je défends pour vos premiers pas

Cinq positions tranchées que cette section assume :

• Lab KVM/libvirt natif, pas Docker, pas Vagrant, pas multipass. KVM est le plus proche d’un environnement de production RHEL — même réseau libvirt, même cloud-init, même init systemd. Vous apprenez l’outil avec lequel vous travaillerez vraiment, pas un succédané.
• Inventaire INI avant YAML. L’INI est plus simple, lisible en deux secondes, suffit pour 90 % des cas. Le YAML viendra naturellement quand vous aurez besoin de variables structurées. Démarrer en YAML pour « faire propre » est un piège qui ralentit.
• Tester le ping AVANT le premier playbook. ansible all -m ansible.builtin.ping vérifie la chaîne SSH + Python + sudo. Si le ping échoue, votre playbook échouera aussi — autant le diagnostiquer maintenant avec une seule commande qu’au milieu d’un playbook de 30 lignes.
• Idempotence vérifiée à chaque run. Un playbook se relance deux fois : changed=N au premier, changed=0 au second. Si vous voyez changed=N au second run, votre playbook a un bug — command: sans creates:, ou module mal utilisé.
• make provision versionné dans Git. Le lab doit pouvoir être détruit et recréé en 5 minutes. Aucun setup manuel non documenté : tout dans Makefile + cloud-init.yaml. Sinon vous perdez votre lab le jour où vous changez de poste, et avec lui 3 mois de mémoire musculaire.

Ce que je vous interdis

Cinq erreurs typiques de démarrage — chacune coûteuse en temps perdu :

• Lire la doc sans monter le lab. Lire un playbook ne le fait pas tourner. Vous devez écrire 50 playbooks ratés pour comprendre Ansible, pas en lire 50 sur le web.
• ansible -m shell -a 'dnf install -y nginx' comme premier réflexe. shell: rejoue à chaque exécution. Toujours chercher le module dédié : ansible.builtin.dnf est idempotent par construction.
• Ignorer le PLAY RECAP. Les colonnes ok, changed, failed, unreachable, skipped racontent tout ce qui s’est passé. Lire le RECAP est non négociable — sinon vous croyez que ça marche alors que des hôtes ont été silencieusement skippés.
• Continuer après un Permission denied. Permission denied (publickey) au ping = chaîne cassée. Réparer avant d’avancer, sinon chaque playbook suivant vous coûtera 30 minutes de debug. La page Debug couvre les 10 erreurs typiques avec leur fix.
• Sauter le quiz de fin de section. 25 questions vérifient le lab, l’inventaire, les ad-hoc et le premier playbook. Si vous séchez sur 5/25, retournez sur les pages concernées avant d’attaquer Écrire du code — sinon vous accumulez la dette technique cognitive.

Êtes-vous prêt à passer à l’écriture de code

Vous pouvez basculer sur la section Écrire du code Ansible (variables, facts, conditions, boucles, templates Jinja2) quand vous savez :

• Provisionner votre lab de zéro en moins de 10 minutes (make provision) ;
• Lancer ansible all -m ping et obtenir 4 pong sans saisir de mot de passe ;
• Écrire un playbook idempotent qui installe + configure + démarre un service ;
• Lire un PLAY RECAP et expliquer chaque colonne (ok, changed, failed, unreachable, skipped) ;
• Décoder une erreur SSH ou Python sans Google.

Le quiz Premiers pas ci-dessous (25 questions) vérifie ces capacités.

Quiz de la section

Quiz Premiers pas Ansible 25 questions sur le lab, l'inventaire, les commandes ad-hoc et le premier playbook — durée 25 min, seuil 70 %

Prochaines étapes

Une fois le quiz validé, vous attaquez l’écriture systématique de code Ansible : variables, facts, conditions, boucles, handlers, templates Jinja2. C’est la couche la plus volumineuse du parcours, mais aussi celle qui occupe la plus grosse part de la RHCE EX294.

Section Écrire du code en cours de rédaction

La section Écrire du code Ansible est en construction (Phase 3 de la refonte). En attendant, l’index Ansible donne la vue d’ensemble du parcours et liste les pages déjà publiées.

Retour à Découvrir Ansible Revenir aux fondamentaux si certaines réponses du quiz vous ont surpris

Index Ansible (vue d'ensemble du parcours) Toutes les sections : découvrir, premiers pas, écrire du code, modules, rôles, collections, Vault

×

📖 Voir la documentation →