Patcher 21 serveurs hybrides chaque semaine sans y penser : Ansible, tiering et supervision de bout en bout

La demarche

1. 01

   Inventaire raisonne du parc, exclusions comprises

   J'ai recense l'ensemble des serveurs repartis sur plusieurs sous-reseaux Azure, avec ouverture NSG au strict necessaire : SSH et WinRM uniquement depuis le controleur Ansible, vers les seuls sous-reseaux concernes. J'ai exclu explicitement du perimetre : les equipements de securite reseau du constructeur (firmware gere via leur console dediee), la CA racine de la PKI interne — qui doit rester hors ligne, un patching automatise la demarrerait — et une VM metier via --limit. Savoir ce qu'on ne patche pas est aussi important que ce qu'on patche.

2. 02

   Installation non intrusive du controleur

   Ansible installe dans un virtualenv Python isole sur un serveur mutualise qui heberge deja la pile de supervision (Prometheus, Grafana, InfluxDB, Nginx, PostgreSQL) — sans toucher au Python systeme ni aux services existants. Wrappers dans le PATH, arborescence propre : inventaire, group_vars, playbooks, scripts, logs, backups.

3. 03

   Modele de securite avant le premier playbook

   Application du modele de tiering Microsoft : compte de service Tier 0 reserve aux controleurs de domaine et serveurs sensibles, compte Tier 1 pour le reste, comptes locaux dedies pour les serveurs hors domaine — chacun avec sa politique de mot de passe (PSO) dediee. Tous les secrets chiffres dans un vault Ansible AES256, un mot de passe become individuel par serveur Linux, gestion des caracteres speciaux via le tag YAML !unsafe. Cle SSH Ed25519, controleur sans IP publique.

4. 04

   Orchestration phasee avec garde-fous

   Un playbook maitre execute cinq phases dans un ordre impose : Linux d'abord (par moities), puis les controleurs de domaine strictement un par un (serial: 1) avec verification de la replication AD, des roles FSMO et des services NTDS/DNS avant et apres chaque patch, puis l'infrastructure Windows, puis le couple metier dans l'ordre BDD-avant-App, et enfin les serveurs de supervision et de sauvegarde en dernier — pour qu'ils observent tout le reste. Chaque phase verifie l'espace disque et les services critiques avant et apres, avec reboot conditionnel uniquement si le systeme le demande.

5. 05

   Culture du dry-run

   Aucune execution reelle sans --check prealable. Le mode check a d'ailleurs revele un piege documente : les taches shell y sont skippees, ce qui rendait certaines assertions dependantes indefinies — corrige par des gardes when: variable is defined. Les problemes rencontres sont consignes dans la documentation d'exploitation avec leur solution : doublon de vault et sa regle de precedence, serveur au nom trompeur qui n'est pas un controleur de domaine malgre les apparences, procedure de deverrouillage de compte.

6. 06

   Automatisation planifiee via Semaphore UI

   Interface web au-dessus d'Ansible (Semaphore, adosse a PostgreSQL, derriere Nginx) avec des templates de taches distincts dry-run / execution reelle, et une planification cron hebdomadaire : Linux puis Windows chaque lundi soir, hors fenetres de sauvegarde. Subtilite de production documentee : le planificateur fonctionne en UTC, d'ou un decalage a anticiper au passage a l'heure d'ete.

7. 07

   Chaine de supervision de bout en bout

   Un script Python (stdlib uniquement, zero dependance) interroge l'API de Semaphore apres chaque campagne, nettoie les codes couleur ANSI de la sortie Ansible, parse le PLAY RECAP par serveur et pousse les metriques dans InfluxDB v2 au format line protocol : statut, taches ok/changed/failed, paquets de securite disponibles, reboots, plus un resume global par execution (retention 365 jours). Un dashboard Grafana restitue le tout : statut global de la derniere campagne, serveurs en erreur avec seuils de couleur, detail par serveur, historique temporel.

8. 08

   Alerting automatique en boucle fermee

   Regle d'alerte Grafana sur la metrique « serveurs en echec » : au moindre echec de patching, un email part automatiquement vers la boite de l'equipe exploitation via le relais SMTP de l'organisation, avec resolution automatique quand la metrique revient a zero. Personne n'a besoin d'aller verifier que le patching du lundi s'est bien passe — le systeme ne se manifeste que quand quelque chose ne va pas.