Vous avez 50 serveurs Linux à configurer, vous voulez éviter de cliquer 50 fois dans une console et vous cherchez l’outil de référence. Ansible est un outil d’automatisation IT qui pilote vos serveurs en SSH, sans agent à installer côté cible, en lisant des fichiers YAML qu’on appelle des playbooks. Vous décrivez l’état désiré ; Ansible converge vos serveurs vers cet état. Ce guide pose ce qu’Ansible est concrètement, ce qu’il n’est pas (un piège fréquent), et ses cas d’usage typiques.
Analogie : un script Bash, c’est un employé sans mémoire — relancez-le, il refait tout (ou casse tout parce que le paquet existe déjà). Ansible, c’est le contremaître qui regarde l’état actuel de chaque serveur, le compare à votre cahier des charges, et n’agit que sur ce qui doit changer. Cette propriété s’appelle l’idempotence, et c’est le cœur d’Ansible.
Le problème qu’Ansible résout
Section intitulée « Le problème qu’Ansible résout »Vous administrez une fleet de serveurs. À 5 machines, vous configurez à la main : SSH, dnf install, vim un fichier, systemctl restart. À 10 machines, vous écrivez un script Bash. À 50 machines, le script Bash devient un cauchemar : la moindre branche conditionnelle pour gérer « est-ce que le paquet est déjà installé ? » se transforme en piège, le script échoue à mi-parcours et vous laisse 23 serveurs configurés et 27 dans un état indéterminé.
Le problème est connu et traité depuis 20 ans. Avant Ansible, CFEngine (1993), Puppet (2005) et Chef (2009) ont essayé d’y répondre avec une approche agent + master : un démon tourne en permanence sur chaque serveur, contacte un master à intervalle régulier, et applique la configuration. Ça marche mais ça impose d’installer et de maintenir l’agent partout, plus le master, plus une PKI pour authentifier les agents.
Ansible (2012) a pris le contre-pied : pas d’agent. Vous avez déjà SSH partout (sinon vous ne pouvez pas vous y connecter), Ansible utilise SSH. Vous lancez ansible-playbook sur votre poste, Ansible se connecte aux serveurs cibles, copie un module Python dans un répertoire temporaire, l’exécute, récupère le résultat, nettoie. C’est tout. Aucun service à activer, aucune base de données à dimensionner.
Ce qu’Ansible est
Section intitulée « Ce qu’Ansible est »Concrètement, Ansible est trois choses qui s’empilent :
ansible-core est le moteur Python qui exécute les playbooks. C’est le minimum vital. Vous l’installez avec pipx install --include-deps ansible ou via votre gestionnaire de paquets. Il pèse quelques mégaoctets, démarre instantanément, et n’a besoin que de Python sur le poste de contrôle et de Python 3 sur les serveurs cibles.
Les collections sont des paquets de modules, de rôles et de plugins distribués séparément. La collection ansible.builtin est livrée avec ansible-core et contient les modules essentiels (file, copy, dnf, systemd…). La collection community.general ajoute des centaines de modules tiers. La collection ansible.posix couvre les modules POSIX étendus (mount, sysctl, firewalld, selinux). Vous installez une collection avec ansible-galaxy collection install, ou vous figez les versions dans un fichier requirements.yml versionné.
ansible-navigator + Execution Environments sont l’évolution moderne, depuis Ansible Automation Platform 2.0. ansible-navigator est une interface texte qui exécute vos playbooks dans un conteneur OCI — l’Execution Environment — qui packagé ansible-core + collections + dépendances Python. Plus de surprises « ça marche sur mon poste mais pas en CI » : l’image porte exactement les mêmes binaires partout. C’est fortement recommandé pour la RHCE 2026 et pour la production.
Ce qu’Ansible n’est pas
Section intitulée « Ce qu’Ansible n’est pas »Beaucoup de débutants choisissent Ansible pour des cas où il n’est pas le bon outil. Voici les pièges classiques.
Ansible ne provisionne pas d’infrastructure cloud. Quand vous voulez créer une VM EC2, un Load Balancer Azure ou un cluster Kubernetes managé, c’est Terraform qu’il vous faut, pas Ansible. Le module amazon.aws.ec2_instance existe et fonctionne, mais utiliser Ansible pour la création d’infra cloud est une erreur stratégique : pas de plan, pas de state, pas de gestion fine des dépendances entre ressources. Ansible commence là où Terraform s’arrête : une fois la VM créée, Ansible la configure.
Ansible n’est pas un orchestrateur de conteneurs. Si vos workloads tournent dans Kubernetes, vous gérez les déploiements avec kubectl apply ou Helm ou ArgoCD, pas avec Ansible. Le module kubernetes.core.k8s existe pour des cas particuliers (bootstrap d’un cluster, intégration avec un workflow Ansible plus large) mais ce n’est pas le bon plan général.
Ansible n’est pas un outil temps réel. Un playbook prend de quelques secondes à quelques minutes selon la taille de la fleet. Ce n’est pas adapté à la réaction immédiate à un événement (déclencher une action quand un disque se remplit). Pour ça, vous combinez Ansible avec un système d’événements : Falco, Prometheus AlertManager, ou un EDA (Event-Driven Ansible — sujet avancé).
Ansible n’est pas idempotent par magie. C’est un mythe répandu. Les modules bien écrits (dnf, template, lineinfile) sont idempotents. Mais le module command ou shell ne l’est pas : il exécute la commande à chaque run, point. C’est à vous de rendre vos playbooks idempotents, en choisissant les bons modules, en posant creates:/removes: sur les commandes shell, et en validant que changed=0 au second passage.
Cas d’usage typiques
Section intitulée « Cas d’usage typiques »Ansible brille quand vous avez besoin de configurer des systèmes Linux de manière reproductible. Quatre familles de cas d’usage couvrent 90 % de l’utilisation réelle.
Le durcissement OS consiste à appliquer un référentiel de sécurité (ANSSI-BP-028, CIS Benchmark, STIG) à une fleet de serveurs : permissions sur les fichiers sensibles, paramètres sysctl, profils SELinux, règles firewalld, audit logs. Un rôle bien écrit applique le référentiel sur 50 serveurs en quelques minutes, et un playbook de vérification garantit qu’ils restent conformes.
Le déploiement applicatif couvre l’installation et la configuration d’applications sur des serveurs : nginx + certificats, base de données + utilisateurs + sauvegardes, application Python + service systemd + supervision. Vous écrivez un rôle par composant, vous les assemblez dans un playbook par environnement, et vous obtenez une infrastructure auto-documentée.
La mise en conformité s’applique sur une fleet existante. Vous écrivez un playbook qui vérifie l’état de chaque serveur (modules assert, check_mode: true) et reporte les écarts. Couplé à un système de ticketing, c’est un outil d’audit puissant : vous savez en 5 minutes que 12 serveurs sur 50 ne respectent pas la baseline.
L’automatisation des tâches RHCSA est le terrain d’entraînement officiel pour la RHCE. Création d’utilisateurs, ajustement de partitions LVM, ouverture de ports firewalld, configuration NTP, génération de cron jobs. Tout ce qu’un sysadmin Linux fait à la main passe à Ansible — et c’est exactement ce que l’examen EX294 évalue.
Comparaison rapide avec les autres outils
Section intitulée « Comparaison rapide avec les autres outils »Pour situer Ansible dans le paysage de la gestion de configuration, voici les concurrents directs et leurs différences principales. Le détail comparatif vit dans une page dédiée, ici on reste sur les grandes lignes pour orienter votre choix initial.
| Outil | Modèle | Agent | Langage | Force principale | Faiblesse |
|---|---|---|---|---|---|
| Ansible | Push, déclaratif | Non (SSH) | YAML + Jinja2 | Simple à démarrer, agentless | Performance limitée sur très grandes fleets |
| Puppet | Pull, déclaratif | Oui | Puppet DSL | Très mature en grande entreprise | Courbe d’apprentissage, gestion agent |
| Chef | Pull, impératif | Oui | Ruby DSL | Flexibilité du Ruby | Complexité, baisse d’usage |
| Salt | Push ou pull | Oui (minion) | YAML + Python | Performance sur très grandes fleets | Moins de communauté que les 2 premiers |
| PyInfra | Push, déclaratif | Non (SSH) | Python | Vrai code Python | Niche, écosystème limité |
La conclusion pratique : pour un sysadmin Linux qui démarre, Ansible est le bon premier outil de gestion de configuration. La courbe d’apprentissage est la plus douce, l’agentless réduit la friction d’adoption, l’écosystème (Galaxy, Automation Hub, RHCE) garantit la pérennité.
À retenir
Section intitulée « À retenir »- Ansible est un outil d’automatisation Linux sans agent, qui pilote vos serveurs en SSH.
- Trois composants à connaître :
ansible-core(le moteur), les collections (les modules),ansible-navigator+ Execution Environments (le mode moderne). - Ansible ne provisionne pas d’infrastructure cloud (c’est Terraform), n’orchestre pas les conteneurs (c’est Kubernetes), et n’est pas temps réel.
- L’idempotence est portée par les modules —
dnfest idempotent,commandne l’est pas. À vous de choisir. - Cas d’usage typiques : durcissement OS, déploiement applicatif, mise en conformité, automatisation RHCSA.