Qu'est-ce qu'Ansible ? Définition, positionnement et cas d'usage

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. Pour le parcours complet (du premier playbook à la RHCE), voir la formation Ansible.

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

Ansible est un outil de gestion de configuration : vous décrivez l'état dans lequel vos serveurs doivent se trouver, et il se charge de les y amener. Vous n'écrivez pas la suite des commandes à exécuter, vous écrivez le résultat attendu. « Le paquet nginx est installé, le service tourne, le port 80 est ouvert. » La différence paraît mince, elle change tout.

Trois notions suffisent à comprendre le mécanisme.

L'inventaire est la liste de vos machines, souvent rangées par groupes : les serveurs web d'un côté, les bases de données de l'autre. C'est ce qui permet de dire « applique ceci à tous les serveurs web » sans les nommer un par un.

Le playbook est un fichier YAML où vous décrivez l'état voulu. Il contient un ou plusieurs plays, et un play associe une cible à une liste de tâches. Chaque tâche appelle un module, une petite unité qui sait faire une chose et une seule : installer un paquet, poser un fichier, démarrer un service, ouvrir un port.

L'idempotence est la propriété qui découle des deux premières. Un module bien écrit commence par regarder l'état actuel de la machine. Si nginx est déjà installé, il ne fait rien et le signale par un ok. Sinon il l'installe et signale un changed. Vous pouvez donc rejouer le même playbook autant de fois que vous voulez : le premier passage corrige, les suivants ne touchent à rien.

C'est ce trio qui distingue Ansible d'un script. Un script décrit un chemin et le rejoue aveuglément. Un playbook décrit une destination, et seul l'écart entre l'état réel et cette destination déclenche une action.

Le YAML, la langue dans laquelle vous écrirez tout

Un playbook s'écrit en YAML, un format de description de données conçu pour être lu par un humain autant que par une machine. Vous n'y trouverez ni accolades ni point-virgule : la structure est portée par des listes, introduites par un tiret, et des paires clé-valeur, séparées par deux-points.

Une seule règle demande de la vigilance, et elle explique la majorité des erreurs des premiers jours : en YAML, l'indentation est significative. Ce sont les espaces en début de ligne qui disent ce qui appartient à quoi, exactement comme en Python. Deux espaces de trop et la tâche change de propriétaire, ou le fichier devient illisible pour Ansible. Deux conséquences pratiques : on indente à l'espace, jamais à la tabulation, que YAML refuse, et on garde un nombre d'espaces constant dans tout le fichier.

Le reste du format s'apprend vite, et la page YAML pour Ansible le couvre en détail, y compris les pièges de typage, comme le fameux 0644 qui ne vaut pas ce qu'on croit.

À quoi ressemble un playbook

Voici le plus court des playbooks utiles. Il ne sert pas encore à le rejouer chez vous, mais à mettre un nom sur chaque élément, car ce vocabulaire revient dans toutes les pages suivantes.

---
- name: Installer et démarrer nginx     # le nom du play, affiché à l'exécution
  hosts: webservers                     # la cible : un groupe de l'inventaire
  become: true                          # exécuter en root, via sudo

  tasks:
    - name: Installer le paquet nginx   # le nom de la tâche, libre mais obligatoire
      ansible.builtin.dnf:              # le module appelé, en nom complet
        name: nginx
        state: present                  # l'état voulu, pas l'action à faire

    - name: Démarrer le service et l'activer au boot
      ansible.builtin.systemd_service:
        name: nginx
        state: started
        enabled: true

Quatre mots-clés structurent ce fichier. hosts désigne la cible, ici le groupe webservers défini dans votre inventaire. become: true demande l'élévation de privilèges, l'équivalent d'un sudo : installer un paquet l'exige, lire un fichier public non. tasks ouvre la liste des tâches, jouées dans l'ordre, du haut vers le bas. Et name donne un intitulé lisible à chaque play et chaque tâche, ce qui rend la sortie d'exécution compréhensible.

Deux détails méritent l'attention dès maintenant.

Le module s'écrit ansible.builtin.dnf et non dnf. Ce nom complet, appelé FQCN (Fully Qualified Collection Name), se lit de gauche à droite : la collection ansible.builtin, puis le module dnf. Il lève toute ambiguïté, deux collections pouvant proposer un module de même nom. Cette forme complète est la seule à utiliser, y compris à l'examen RHCE.

Le paramètre state est la traduction directe de l'approche déclarative. state: present signifie « je veux que ce paquet soit installé », pas « installe ce paquet ». La nuance porte tout : si le paquet est déjà là, le module n'a rien à faire. Vous rencontrerez surtout present, absent, started et stopped.

Vous croiserez aussi des variables, écrites entre doubles accolades, comme {{ nginx_port }}. Elles évitent d'écrire les valeurs en dur et rendent un playbook réutilisable d'un environnement à l'autre. Le sujet a sa propre section dans la formation.

Lire le résultat d'une exécution

À la fin de chaque exécution, Ansible affiche un PLAY RECAP, une ligne par machine. C'est le tableau de bord que vous regarderez en premier, à chaque fois.

PLAY RECAP *********************************************************************
web1.lab : ok=3    changed=2    unreachable=0    failed=0

Quatre compteurs à savoir lire. ok compte les tâches exécutées sans erreur, qu'elles aient modifié quelque chose ou non. changed compte celles qui ont réellement modifié la machine. unreachable signale les serveurs injoignables, presque toujours un problème de SSH ou de nom d'hôte. failed compte les tâches en échec.

Le compteur décisif est changed. Au premier passage, il est normal qu'il soit élevé : Ansible met la machine en conformité. Relancez le même playbook sans rien modifier, et il doit tomber à changed=0. Cette convergence est la preuve que votre playbook est idempotent, et le guide suivant la démontre sur un cas complet.

De quoi Ansible se compose

Le nom « Ansible » recouvre en réalité plusieurs briques, et la confusion entre elles est une source d'erreur fréquente au moment de l'installation.

ansible-core est le moteur. C'est lui qui lit l'inventaire, interprète le playbook, se connecte aux machines et exécute les modules. Il pèse quelques mégaoctets et n'exige que Python, sur votre poste comme sur les serveurs gérés.

Les collections sont des paquets de modules, de rôles et de plugins distribués séparément du moteur. ansible.builtin est livrée avec ansible-core et couvre l'essentiel, community.general ajoute des centaines de modules tiers, ansible.posix traite les sujets système comme les montages, sysctl, firewalld ou SELinux. Le paquet nommé simplement ansible, lui, est un metapackage : le moteur accompagné de plusieurs centaines de collections préinstallées.

ansible-navigator et les Execution Environments forment le mode d'exécution moderne, arrivé avec Ansible Automation Platform 2.0. L'idée est d'enfermer le moteur, les collections et leurs dépendances Python dans une image de conteneur, l'Execution Environment, puis de jouer les playbooks dedans. Le « ça marche sur mon poste mais pas en CI » disparaît, puisque l'image embarque exactement les mêmes versions partout.

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

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

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

Ansible est un outil de gestion de configuration : vous décrivez l'état voulu, il amène vos serveurs à cet état, en SSH et sans agent à installer.
Trois notions suffisent : l'inventaire liste les machines, le playbook décrit l'état voulu, les modules le réalisent.
Trois briques à ne pas confondre : ansible-core (le moteur), les collections (les modules distribués à part), ansible-navigator et les Execution Environments (l'exécution en conteneur). Le paquet ansible est un metapackage qui réunit le moteur et des centaines de collections.
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, dnf est idempotent, command ne l'est pas. À vous de choisir.
Cas d'usage typiques : durcissement OS, déploiement applicatif, mise en conformité, automatisation RHCSA.

Pour aller plus loin

Déclaratif vs impératif : Le même déploiement écrit en Bash puis en playbook, pour voir ce que change vraiment la notion d'état voulu.
Ansible vs Terraform vs Puppet : Prolonge le tableau comparatif de cette page avec des critères de décision détaillés.
Installer Ansible : Pour passer de la définition au poste de contrôle équipé, avec la méthode adaptée à votre système.