Installer trente postes à la main, c'est trente occasions de faire différemment. L'objectif de cette dernière brique est qu'un poste s'installe et se configure sans intervention humaine — et qu'un poste réinstallé revienne exactement au même état.
Le démarrage réseau installe le système, Ansible le rend exploitable : deux responsabilités clairement séparées.
Deux outils, deux rôles
La formule qui résume l'architecture : PXE installe, Ansible rend le poste exploitable.
- Le démarrage réseau — le poste amorce sur le réseau, le service d'adressage l'oriente vers le serveur de déploiement, et le système s'installe automatiquement avec un simple compte de prise en main ;
- Ansible — prend le relais : intégration à l'annuaire, montage des espaces de fichiers, nommage du poste, installation des logiciels, mises à jour, durcissement.
La décision qui structure tout : intégrer après, pas pendant
C'est le choix le plus intéressant de cette partie. L'intégration à l'annuaire pourrait être faite pendant l'installation du système — c'est techniquement possible. Le projet la reporte volontairement à l'étape suivante, pour deux raisons.
C'est rejouable. Un playbook peut être relancé sur un poste déjà installé : on corrige une configuration sans réinstaller. Intégrée dans l'installation, la même correction imposerait de repasser toutes les machines par une réinstallation complète.
C'est débogable. Un échec d'intégration se lit dans une sortie Ansible explicite, exécutée à la demande. Le même échec pendant une installation automatisée se traduit par une machine dans un état indéterminé et un journal difficile à récupérer.
Ce raisonnement dépasse le cadre du projet : tout ce qui peut être fait après l'installation, par convergence, gagne à l'être. L'installation doit rester minimale et fiable.
Les prérequis, vérifiés avant d'écrire un playbook
Résolution des noms, horloge synchronisée, puis une arborescence séparant inventaires, rôles et playbooks.
Trois contrôles, dont un souvent négligé :
- la résolution des noms des trois serveurs d'infrastructure — l'orchestrateur les nomme, il ne les adresse pas ;
- la route par défaut vers la passerelle ;
- l'horloge synchronisée — et la documentation le qualifie de critique, à juste titre. Une dérive d'horloge casse la validation des certificats, donc les connexions chiffrées à l'annuaire, et parfois l'authentification par clé. Le symptôme est incompréhensible ; la cause est un décalage de quelques minutes.
L'organisation du dépôt
La structure retenue est celle recommandée par l'outil, et elle mérite d'être respectée :
- des inventaires séparés — un pour le laboratoire, un pour la production. C'est ce qui empêche d'appliquer par mégarde à trente postes ce qu'on voulait tester sur un ;
- des variables par groupe et par machine, distinctes de la logique ;
- des rôles — prise en main, socle, intégration annuaire, montage des fichiers, configuration de poste : chacun autonome et réutilisable ;
- des playbooks qui assemblent ces rôles selon l'intention : prendre en main, faire converger, configurer un poste.
L'intérêt de ce découpage apparaît à la première évolution : ajouter un logiciel au parc consiste à modifier un rôle, pas à réécrire une procédure.
Le compte de prise en main
L'installation crée un compte minimal, utilisé uniquement par l'orchestrateur pour son premier contact. C'est un choix de sécurité autant que de méthode : ce compte n'a qu'un rôle transitoire, et la configuration d'accès de l'orchestrateur est réglée pour accepter automatiquement les nouvelles machines pendant cette phase seulement.
Ce détail est à assumer : accepter automatiquement l'empreinte d'une machine inconnue est une facilité de déploiement, pas une bonne pratique permanente. Sur un réseau pédagogique isolé, c'est acceptable ; il faut savoir que ça l'est parce que le réseau est isolé.
Valider sur un poste avant d'industrialiser
Avant tout déploiement en série, le projet monte un poste de test installé manuellement. Objectif : valider l'accès depuis l'orchestrateur, le mécanisme de prise en main et les rôles — sans mélanger deux sources de problèmes.
C'est une discipline qui paie. Déboguer simultanément une installation automatisée et une chaîne de configuration revient à chercher une panne dans deux systèmes qui échouent ensemble. Un poste installé à la main, puis configuré par l'orchestrateur, isole le second problème du premier.
Ce que ça donne au quotidien
- un poste neuf : on le démarre sur le réseau, on revient plus tard — il est prêt ;
- un poste cassé : on le réinstalle, il revient au même état ;
- une évolution du parc — nouveau logiciel, nouveau réglage : on modifie un rôle, on relance la convergence ;
- une dérive — quelqu'un a modifié un poste : la convergence suivante le remet en conformité.
Ce dernier point est le plus précieux dans un environnement scolaire, où les postes sont manipulés par beaucoup de monde : la configuration n'est plus un état atteint une fois, c'est un état maintenu.
La série EduLibre
De la décision à l'industrialisation du parc :
- 1. Pourquoi un socle libre pour un parc informatique
- 2. L'architecture globale, brique par brique
- 3. La passerelle : routage, NAT, DNS et DHCP
- 4. L'annuaire LDAP, brique de voûte
- 5. NFS : profils, classes et quotas
- 6. PXE et Ansible : le parc en zero-touch — vous y êtes