C'est quoi Ansible ? Infrastructure as code et idempotence

Ansible est un outil d'automatisation libre qui configure des serveurs, des postes et des équipements réseau à partir de fichiers texte écrits en YAML, sans installer de logiciel sur les machines gérées. Ce chapitre explique pourquoi on automatise, ce que recouvre l'infrastructure as code, ce qu'est l'idempotence, comment Ansible fonctionne et où il se situe face aux autres outils.

Pourquoi automatiser l'administration

Sorbier Logistique fait tourner une douzaine de serveurs : deux contrôleurs de domaine, un serveur de fichiers, un serveur de gestion, un serveur de journaux et de supervision, le serveur web de la DMZ, et bientôt un serveur de recette. Jusqu'ici, chaque installation suivait une procédure dans un document de traitement de texte de quinze pages. Antoine Mercier, le responsable informatique, a fait le compte des problèmes :

• Le temps. Préparer un serveur Debian (paquets, heure, comptes des administrateurs, durcissement SSH, pare-feu, agent de supervision) prend une demi-journée. Pour dix serveurs, une semaine.
• Les oublis. Sur srv-journaux, quelqu'un a sauté l'étape du pare-feu. Personne ne s'en est aperçu pendant six mois.
• La dérive de configuration. Chloé a corrigé un réglage SSH à la main sur un serveur, pas sur les autres. Deux serveurs installés avec la même procédure ne sont plus identiques : on parle de dérive (configuration drift).
• La traçabilité. Qui a changé quoi, quand, et pourquoi ? La procédure dit ce qu'il fallait faire, pas ce qui a été fait.
• La reconstruction. Si un serveur est perdu, le reconstruire à l'identique dépend de la mémoire de celui qui l'a installé.

Un script Bash ou PowerShell règle une partie du problème : il enchaîne les commandes sans en oublier. Mais un script écrit naïvement ne sait pas dans quel état il trouve la machine. Lancé deux fois, il peut ajouter deux fois la même ligne dans un fichier, échouer parce qu'un compte existe déjà, ou redémarrer un service pour rien.

C'est quoi l'infrastructure as code

L'infrastructure as code (IaC, « infrastructure sous forme de code ») consiste à décrire l'infrastructure (serveurs, configurations, réseaux, machines virtuelles) dans des fichiers texte lisibles par un outil, puis à laisser cet outil appliquer la description. Les fichiers deviennent la référence : pour savoir comment un serveur est configuré, on lit le dépôt, pas le serveur.

Ce que ça change concrètement :

• Reproductible. Le même fichier produit le même serveur, aujourd'hui comme dans un an, en recette comme en production.
• Versionné. Les fichiers vivent dans un dépôt Git : chaque modification a un auteur, une date, un message et peut être annulée (cours Git et GitHub).
• Relu et testé. Une modification passe par une revue et par des contrôles automatiques avant d'être appliquée (chapitre 15).
• Documenté. Le code est une documentation qui ne peut pas être fausse : c'est lui qui configure.
• Rapide. Préparer dix serveurs prend le même temps qu'en préparer un.

Deux styles d'écriture existent.

L'approche impérative décrit les étapes : « installe chrony, puis ajoute cette ligne au fichier, puis redémarre le service ». C'est le style d'un script.

L'approche déclarative décrit le résultat : « chrony doit être installé, le fichier doit contenir ces lignes, le service doit tourner ». L'outil compare l'état réel à l'état voulu et ne fait que ce qui manque.

Voici le même besoin écrit des deux façons. D'abord en Bash :

#!/bin/bash
# Impératif : une suite d'actions
apt-get install -y chrony
echo "server 192.168.10.177 iburst" >> /etc/chrony/chrony.conf
systemctl restart chrony

Puis en Ansible :

# Déclaratif : l'état attendu
- name: Chrony doit être installé
  ansible.builtin.apt:
    name: chrony
    state: present

- name: Le fichier doit déclarer le contrôleur de domaine comme source d'heure
  ansible.builtin.lineinfile:
    path: /etc/chrony/chrony.conf
    line: server 192.168.10.177 iburst

Lance le script Bash trois fois : le fichier contient trois fois la même ligne, et chrony a redémarré trois fois. Lance les tâches Ansible trois fois : la première exécution installe le paquet et ajoute la ligne, les deux suivantes constatent que tout est déjà en place et ne touchent à rien.

L'idempotence

Une opération est idempotente quand l'appliquer une fois ou plusieurs fois donne le même résultat. C'est la propriété centrale de la gestion de configuration : tu peux relancer un playbook autant de fois que tu veux, sur des serveurs neufs comme sur des serveurs déjà configurés, sans rien casser.

Pour chaque tâche, Ansible affiche l'un de ces statuts :

L'idempotence ne tombe pas du ciel : elle vient des modules. Le module apt vérifie si le paquet est installé avant d'agir, lineinfile cherche la ligne avant de l'ajouter, user regarde si le compte existe. Dès que tu remplaces un module par une commande brute (command, shell), tu perds cette garantie, et c'est à toi de la reconstruire (chapitre 4).

Comment fonctionne Ansible

Ansible repose sur une architecture sans agent (agentless) et en mode poussé (push) : rien n'est installé sur les machines gérées, c'est la machine d'administration qui se connecte à elles et leur pousse le travail.

• Le nœud de contrôle (control node) est la machine où Ansible est installé et d'où tu lances les commandes. Chez Sorbier, c'est le bastion d'administration, une VM Debian 13. Il doit tourner sous Linux ou macOS : Windows ne peut pas être nœud de contrôle, sauf à travers WSL.
• Les nœuds gérés (managed nodes) sont les machines qu'Ansible configure : serveurs Linux et Windows, switchs, pare-feu, hyperviseurs.
• L'inventaire est la liste des nœuds gérés, rangés en groupes (chapitre 3).
• Un playbook est un fichier YAML qui dit quelles tâches appliquer à quels groupes (chapitre 5).
• Un module est l'unité de travail : un petit programme qui sait faire une chose de façon idempotente (installer un paquet, déposer un fichier, créer un compte).

Ce qui se passe quand Ansible exécute une tâche sur un serveur Linux :

1. Ansible lit l'inventaire, résout les variables de l'hôte et prépare le module avec ses arguments.
2. Il ouvre une connexion SSH avec le compte prévu (OpenSSH du système, avec tes clés et ton fichier ~/.ssh/config).
3. Il dépose le module dans un dossier temporaire de l'hôte (~/.ansible/tmp), ou le passe directement à l'interpréteur si le pipelining est activé (chapitre 2).
4. Le Python du serveur exécute le module, qui compare l'état réel à l'état demandé, agit si besoin et renvoie un résultat en JSON (changed, failed, valeurs utiles).
5. Ansible supprime les fichiers temporaires, affiche le statut et passe à la tâche suivante.

Ansible traite plusieurs hôtes en parallèle : par défaut 5 à la fois (le réglage forks). Une tâche est exécutée sur tous les hôtes visés avant de passer à la suivante : c'est la stratégie linear, celle par défaut.

Ce qu'il faut sur chaque famille de machines :

Le vocabulaire d'Ansible

Le nom complet d'un module s'écrit espace.collection.module : c'est le FQCN (fully qualified collection name). ansible.builtin.copy est le module copy de la collection builtin, livrée avec ansible-core. Écris toujours le FQCN : c'est sans ambiguïté, et ansible-lint l'exige.

Ansible face aux autres outils

Ansible a été créé en 2012 par Michael DeHaan, racheté par Red Hat en 2015, et Red Hat appartient à IBM depuis 2019. Le moteur, ansible-core, est un logiciel libre sous licence GPL v3, gratuit. Red Hat vend une offre commerciale, Red Hat Ansible Automation Platform, qui ajoute une interface web, la planification, la gestion fine des droits et le support. Son projet amont libre s'appelle AWX (dernière version publiée en juillet 2024) ; d'autres interfaces libres existent, comme Semaphore UI.

Les outils à agent (Puppet, Chef, Salt) fonctionnent en mode tiré (pull) : chaque machine interroge régulièrement un serveur central et corrige elle-même sa dérive. Ansible, en mode poussé, n'agit que quand tu le lances : pour corriger la dérive en continu, on le planifie (tâche cron, AWX, pipeline).

Ansible et le BTS SIO

Au BTS SIO, l'automatisation appartient à l'option SISR, dans le bloc 2 évalué à l'épreuve E6.

• La compétence « Exploiter, dépanner et superviser une solution d'infrastructure réseau » comprend la sous-compétence automatiser des tâches d'administration, dont l'indicateur est que l'automatisation réponde au besoin exprimé.
• L'environnement technologique exigé pour l'E6 SISR comprend un logiciel de gestion des configurations : Ansible en est l'exemple type, à côté de l'inventaire GLPI.
• Parmi les solutions dont il faut au moins une, le référentiel cite une solution gérée à l'aide de procédures automatisées écrites avec un langage de scripting.

Une réalisation professionnelle qui déploie des serveurs avec un dépôt Ansible versionné coche ces cases et donne à la commission quelque chose de concret à regarder : tu modifies une variable, tu relances, le serveur change, et la deuxième exécution n'affiche aucun changed. Le cours sur l'épreuve E6 SISR détaille les attendus ; le chapitre 15 dit quoi mettre dans ton dossier.

Exercices