Automatisation post-déploiement avec Ansible : des postes réellement prêts à l’emploi

Compétences du Bloc B1 : B1.1 — Gérer le patrimoine informatique · B1.5 — Mettre à disposition des utilisateurs un service informatique

L’organisation et le contexte

À ce stade du projet de masterisation mené à l’IP2I (Institut de Physique des 2 Infinis de Lyon), la chaîne Foreman + Clonezilla permet de déployer un système complet sur n’importe quel poste du parc en un démarrage réseau. Mais un poste cloné n’est pas encore un poste prêt : selon le service et le profil de l’utilisateur final — chercheur, doctorant, personnel administratif — les besoins applicatifs diffèrent. L’un aura besoin d’outils de calcul scientifique, l’autre d’une suite de visioconférence, un troisième d’un environnement de rédaction complet.

Le besoin technique

Maintenir un master par combinaison d’applications aurait été ingérable : chaque nouvelle demande aurait imposé de recréer et de restocker une image de plusieurs gigaoctets. À l’inverse, installer les applications à la main après chaque déploiement aurait réintroduit exactement le travail manuel que le projet visait à éliminer. Le besoin était donc clair : conserver un petit nombre de masters génériques, et personnaliser automatiquement chaque poste après son déploiement, en fonction d’une simple liste d’applications choisie au moment de la demande.

La solution retenue : Ansible déclenché au premier démarrage

L’outil retenu est Ansible, la référence open source de l’automatisation de configuration, explicitement adaptée à ce besoin : on décrit dans des « playbooks » l’état souhaité d’une machine (tel paquet installé, tel fichier présent), et Ansible se charge de l’atteindre de manière fiable et rejouable. Il fonctionne sans agent : seule une connexion SSH est nécessaire, ce qui allège les masters.

L’architecture mise en place fonctionne ainsi : les images masters embarquent un petit service système qui s’exécute une seule fois, au tout premier démarrage du poste fraîchement déployé. Ce service lit un fichier listant les applications demandées pour ce poste, puis déclenche depuis le serveur Foreman l’exécution des playbooks correspondants sur la machine. Une bibliothèque de playbooks a été constituée et testée pour couvrir les demandes courantes du laboratoire : outils de tracé scientifique, visioconférence, messagerie, distribution scientifique Python, environnement de composition de documents, synchronisation de fichiers. Ajouter une application au catalogue revient désormais à écrire et tester un playbook une seule fois — il devient ensuite disponible pour tous les déploiements futurs.

Le résultat concret pour le service : la préparation d’un poste, du déploiement de l’image à l’installation du dernier logiciel, ne demande plus aucune intervention manuelle. Le technicien déclare la machine, choisit un master et une liste d’applications, démarre le poste en réseau — et le récupère prêt à être remis à l’utilisateur.

La dimension sécurité

Toutes les communications entre le serveur et les postes reposent sur des clés SSH dédiées, sans aucun mot de passe stocké ni transmis. Le service de premier démarrage est conçu pour ne s’exécuter qu’une seule fois : un poste en production ne conserve pas de mécanisme d’exécution automatique dormant. Le caractère déclaratif d’Ansible est lui-même un atout de sécurité et de qualité : les playbooks sont relisibles, versionnables et rejouables à l’identique, ce qui élimine les écarts de configuration entre postes — un poste installé aujourd’hui est strictement identique à un poste installé dans six mois avec la même liste.

Ma plus-value personnelle

Ce volet est celui où j’ai le plus conçu « sur mesure ». Le mécanisme de personnalisation au premier démarrage n’existe pas clé en main : il a fallu articuler trois briques (le service embarqué dans le master, le fichier de description des applications, le déclenchement des playbooks via SSH) et les faire fonctionner ensemble de manière fiable, y compris dans le cas d’un poste sans liste d’applications, qui doit simplement démarrer sans erreur. J’ai construit et testé chaque playbook du catalogue individuellement avant de valider la chaîne complète de bout en bout : déploiement d’un master vierge, premier démarrage, installation automatique, vérification applicative. Cette approche par petites briques validées puis assemblées — que j’applique aussi dans mes projets personnels — s’est révélée précieuse pour isoler rapidement les problèmes. Enfin, ce travail m’a fait pratiquer un outil central du métier d’administrateur systèmes : Ansible est aujourd’hui un standard de l’industrie, et savoir concevoir des playbooks propres et idempotents est une compétence directement réutilisable.


La procédure technique détaillée pas à pas, avec captures d’écran et commandes complètes, est disponible en téléchargement au format PDF ci-dessous.