The Operations Loop : l’installation du serveur comme point de départ de son exploitation

AI_Manager

Installer un seul serveur ne représente qu’une partie de la préparation à l’exploitation. Un serveur ne devient exploitable que lorsqu’on sait qui l’a déployé et dans quel environnement, quel logiciel y tourne, comment s’y connecter, et comment détecter et résoudre les pannes.

Ce projet est un exercice pratique d’infrastructure qui relie l’installation d’un serveur Rocky Linux à sa configuration de base, à l’enregistrement détaillé des actifs, à la mise à jour de l’inventaire automatisé et à la réception des métriques de surveillance réelles. Sur Oracle VirtualBox, un réseau d’exploitation central a été séparé des environnements PROD, DEV et STG, et Zabbix, NetBox, AWX, Git et PXE ont été configurés au sein d’un même flux d’exploitation.

L’environnement de TP utilise des VM sur un seul PC personnel. C’est un environnement pour tester les pannes de services et de VM, et non un système de production avec une redondance au niveau de l’hôte physique ou du stockage. Les résultats de validation sont distingués selon l’ID de tâche, l’heure et les valeurs observées d’un projet de validation distinct.

• 1. Aperçu du projet
• 2. Problèmes opérationnels à résoudre
• 3. Configuration des serveurs et réseau
• 4. Processus par lequel un serveur rejoint l’exploitation
• 5. Comment les YAML de collecte d’actifs joints ont été appliqués
• 6. Pourquoi cette conception a été choisie
• 7. Scénarios de panne et limites de la haute disponibilité
• 8. Exploitation tenant compte à la fois des réseaux connectés et fermés
• 9. Compétences démontrées dans ce projet
• 10. Lectures complémentaires et fondements techniques
• Lectures associées et documents de configuration

1. Aperçu du projet

Plutôt que l’achèvement de l’installation par outil, le critère d’achèvement retenu est de savoir si l’identifiant et l’IP de gestion d’un serveur restent cohérents tout au long de l’installation, de la gestion des actifs, de l’automatisation et de la supervision. Même si l’API renvoie 200, l’onboarding n’est pas validé si la cible est absente de l’inventaire ou si les dernières données de Zabbix ne remontent pas.

L’onboarding effectif des trois environnements PROD, DEV et STG a été finalisé. Les workflows AWX 22, 30 et 38 ont permis de réussir l’enregistrement des actifs, la mise à jour des inventaires et la vérification des dernières valeurs de supervision. Nous avons également testé la coupure d’alimentation des deux nœuds centraux l’un après l’autre, la coupure de transmission du proxy avec récupération des données en retard, le rejet des conflits d’actifs et la restauration d’une base de données séparée. Les conditions de réussite et le périmètre non vérifié pour chaque cas sont détaillés dans l’article de vérification.

2. Problématiques opérationnelles à résoudre

L’exécution séparée de l’installation de l’OS, de la mise à jour du registre d’actifs Excel, de l’ajout d’hôtes Ansible et de l’enregistrement de la surveillance entraîne des omissions et des incohérences. Des situations peuvent se produire où un serveur réinstallé écrase un actif précédent, où une adresse NAT est enregistrée comme IP de supervision, ou où la supervision ne contient qu’un hôte sans données.

Pour limiter ces risques, le nom d’hôte, l’environnement et l’IP de gestion approuvés servent de base de saisie et sont comparés au nom d’hôte, au machine ID et aux interfaces lus sur le système invité réel. Dans NetBox, les relations entre VM/Device, Interface, IPAddress et primary_ip4 sont établies en plus des adresses IP textuelles, et AWX récupère son inventaire à partir de ces relations. Lors de la réexécution d’un enregistrement, l’identifiant existant et le responsable de la gestion sont vérifiés.

Le second défi consiste à expliciter le périmètre des pannes. La simple présence de deux serveurs Zabbix ne garantit pas la haute disponibilité (HA) jusqu’à la base de données. De même, la présence de deux instances Web NetBox n’a de sens que si PostgreSQL, Redis, le stockage partagé et les adresses de connexion fonctionnent de concert. Les conditions de basculement de chaque couche ainsi que les points de défaillance unique (SPOF) restants ont été explicités séparément.

Architecture interactive — Structure globale et flux opérationnel

3. Configuration des serveurs et réseau

Le PC hôte physique est équipé de Windows 11 Pro, d’un processeur Intel Core Ultra 9 185H (16 cœurs / 22 processeurs logiques), d’environ 31,4 Gio de mémoire disponible et d’un SSD de 2 Tio. La mémoire est allouée aux machines virtuelles selon les strictes nécessités et les cibles d’installation PXE sont exécutées séquentiellement. Les cibles nécessitant 4 Gio pendant l’installation voient leur allocation réduite à 1 Gio une fois l’installation terminée.

Dans le nom d’hôte, ops désigne le service de production, quorum le diagnostic des pannes, edge le point d’entrée de l’environnement et provision la base d’installation. Le FQDN reconnu par le système d’exploitation est 호스트명.fullmoon.test. Une distinction a été faite entre le domaine du site public et le DNS de TP.

Aucune carte réseau NAT ou pont n’est attachée aux cibles PXE par environnement. Le trafic SSH central allant vers le serveur cible passe par le Bastion de cet environnement. La communication entre les environnements est bloquée par défaut, et les sources, destinations et ports nécessaires doivent être spécifiés. Le NAT de la machine virtuelle d’administration utilisé pour l’importation initiale des paquets et le chemin des services internes sont distingués dans l’article de déploiement.

4. Processus d’intégration d’un serveur en production

Ne stockez pas le mot de passe administrateur NetBox sur le serveur distant. La collecte à distance est exécutée avec des privilèges administratifs dans la mesure du nécessaire, et les requêtes API sont exécutées avec des identifiants injectés par l’environnement d’exécution AWX. La clé privée SSH n’est pas copiée sur le Bastion.

L’ajout automatique d’inventaire dans AWX est une fonctionnalité réalisable. Le plugin d’inventaire Ansible officiel de NetBox a été connecté en tant que source d’inventaire SCM, et configuré pour qu’une fois la tâche d’enregistrement réussie, le Workflow exécute consécutivement la synchronisation d’inventaire et les tâches de validation. Le jeton NetBox a été séparé en un usage d’écriture d’actifs et un usage de lecture d’inventaire.

La connexion après le PXE est prise en charge par le contrôleur d’installation terminée central. Après avoir vérifié la clé d’hôte SSH approuvée, le témoin de fin d’installation, le hostname et le machine ID, le Workflow du serveur concerné est lancé. L’approbation initiale de l’identité du serveur reste une étape de vérification pour l’administrateur, et après approbation, l’enregistrement des actifs, de l’inventaire et de la supervision est exécuté de manière consécutive. Si le machine ID change en raison d’une réinstallation, il est laissé en tant qu’élément à examiner au lieu d’être écrasé automatiquement.

5. Comment le YAML de collecte des actifs joints a-t-il été appliqué ?

Le YAML joint n’est pas un simple enregistreur de hostname. C’est un registre d’actifs qui collecte les traces du système d’exploitation, du processeur, du disque, du réseau, du produit, de la virtualisation et de l’agent de sauvegarde, en prenant comme point de départ les processus Linux en cours d’exécution et les informations /proc. Tout en maintenant cette intention, quatre éléments (état de collecte, heure, erreur et machine ID) ont été ajoutés aux 34 champs personnalisés d’origine.

Les règles d’adresse de site, de site et de jugement d’environnement d’origine ont été remplacées par les variables d’inventaire explicites PROD/DEV/STG de cet exercice. Une relation IPAM native NetBox a été ajoutée à la partie qui ne stockait que la chaîne de caractères primary_ipv4. Les balises de site, de rôle, de plateforme et d’utilisateur approuvées existantes ne sont pas remplacées aveuglément par les résultats de la collecte.

La détection de version de toutes les bases de données et WAS commerciaux n’a pas été validée par l’installation. Vérifiez la propriété des fichiers exécutables, la liste blanche et l’espace de noms, et n’exécutez pas de scripts de démarrage incertains en tant que root. Les versions non vérifiées sont laissées comme non confirmées. La collecte de produits à l’intérieur des conteneurs est également traitée comme une tâche distincte de la collecte des actifs de l’hôte.

6. Pourquoi cette conception

Raisons du placement de plusieurs services sur les deux VM centrales

En environnement de production, il est préférable de diviser les serveurs en tenant compte des ressources par rôle, de la sécurité et de l’isolation des pannes. Ce TP devant valider l’interconnexion entre services et le basculement en cas de panne dans un PC de 32 Go, nous avons regroupé les rôles sur les deux VM centrales. NetBox, Zabbix et les services de données sont séparés par projets Compose, volumes et comptes, tandis qu’AWX est déployé sur K3s pour suivre la structure d’installation et de gestion de l’opérateur officiel.

Cependant, la division des conteneurs n’isole pas les pannes de VM. De nombreux services utilisent le réseau hôte et partagent les impacts liés au CPU, à la mémoire, aux E/S disque, au noyau et au redémarrage de la VM. La limitation de la mémoire et la limitation de la concurrence des tâches constituent les moyens de gestion des ressources dans cette condition.

Raisons de la séparation entre le serveur HA Zabbix et le proxy

Les deux serveurs centraux partagent des rôles Actif/Veille via une haute disponibilité native (Native HA) et utilisent une base de données commune. Le proxy actif de chaque environnement collecte les données des agents locaux et les transmet au centre. En cas de coupure de la connexion centrale, le tampon disque du proxy peut continuer la collecte, mais si la VM proxy elle-même s’arrête, cette fonction disparaît également. Agent→Proxy et Proxy→Server sont authentifiés par PSK respectivement.

Raisons de la séparation de NetBox HA jusqu’à la couche de données

NetBox App et Worker sont placés sur les deux nœuds centraux, PostgreSQL est configuré avec Patroni, Redis avec Sentinel, et l’adresse de connexion avec Keepalived/HAProxy. Les deux nœuds NetBox utilisent les mêmes SECRET_KEY et jeton pepper, et les médias font référence à un NFS commun. Le troisième etcd/Sentinel garantit la majorité en cas de perte de l’un des deux nœuds centraux.

NFS en soi est un nœud unique. Par conséquent, la portée de NetBox HA dans cette configuration est définie autour de la panne d’un nœud central. On ne peut pas qualifier cela d’une haute disponibilité de stockage complète résistant à une panne de stockage multimédia. PostgreSQL utilise le mode synchrone mais pas le mode strict, ce qui ne garantit pas un RPO de 0 dans toutes les pannes.

Raisons de regrouper le proxy et le bastion

Le regroupement des points de collecte de surveillance et des points d’entrée d’automatisation de chaque environnement sur une seule VM a permis de réduire l’utilisation des ressources pour ce petit TP. Le Bastion ne fait que transférer (forwarding) vers les ports SSH des cibles autorisées et limite le shell interactif ainsi que le transfert d’agent (agent forwarding). Ce déploiement a pour contrepartie qu’une panne unique de Proxy/Bastion affecte à la fois la surveillance et la nouvelle automatisation. En exploitation réelle, ils peuvent être séparés selon l’échelle et les périmètres de sécurité.

Raisons de l’inclusion de Git et AWX

Avoir des fichiers de playbook et pouvoir reproduire la même configuration sont deux choses différentes. En reliant les commits Git, la synchronisation du projet AWX, l’ID de job, l’inventaire cible et la version de l’environnement d’exécution, il est possible de tracer quel code a modifié quoi. Tout en utilisant NetBox comme source de vérité pour les actifs réels, la liste d’approbation de l’installation initiale est maintenue dans un inventaire d’amorçage (bootstrap inventory) séparé.

7. Scénarios de panne et limites de la disponibilité

Ce tableau représente la portée prévue de la conception. Les pannes réellement exécutées, les lacunes de collecte, les heures de récupération et la conservation des données sont évaluées séparément dans l’article de validation. L’animation de panne à l’écran n’interroge pas l’état réel des serveurs et n’exécute pas de commandes.

8. Exploitation tenant compte à la fois des réseaux en ligne et isolés

Sur le réseau en ligne, les versions vérifiées sont téléchargées depuis le dépôt officiel et le condensé d’image, la signature RPM ainsi que le commit Git sont enregistrés. Sur le réseau isolé, les mêmes versions de RPM et leurs dépendances, les images de conteneurs, les images K3s, l’AWX EE, les collections Ansible, le bundle Git et l’arborescence d’installation de l’OS sont importés. L’autorité de certification (CA), le DNS et le NTP doivent également être fournis en interne.

Pour les serveurs cible sans accès à Internet, les RPM signés sont fournis via un dépôt HTTP interne, et l’API utilise le HTTPS vérifié par le CA du TP. Il convient de bien distinguer le transport HTTP du dépôt RPM interne et l’authentification HTTPS de l’API. Les connexions internes en clair de la couche de données constituent une limite du TP actuel et nécessitent de renforcer le TLS, la gestion des secrets et l’audit des accès lors du passage en production.

9. Compétences mises en valeur dans ce projet

L’essence de ce TP ne réside pas dans le nombre d’outils, mais dans la capacité à relier les résultats opérationnels. Les identifiants de la phase d’installation sont suivis jusqu’à NetBox et Zabbix, en tenant compte des réexécutions et des échecs partiels, pour vérifier non seulement l’état normal, mais aussi ce qui persiste et ce qui s’arrête après une panne.

Les problèmes de chemin de dépôt, de schéma d’API, de méthode de jeton, d’environnement d’exécution AWX et de contrôle de santé HAProxy découverts lors de la mise en place sont consignés avec leurs conditions de reproduction et les bases de leur correction. Les problèmes liés au micrologiciel VirtualBox, aux vCPU et à la mémoire d’installation sont traités séparément dans un article de blog, indépendamment de la conception du service.

Lors de l’extension vers un environnement de production futur, la priorité sera donnée à la redondance des hôtes physiques et du stockage, à la haute disponibilité d’AWX/Git, au chiffrement de bout en bout, à un gestionnaire de secrets externe, ainsi qu’à une politique de sauvegarde et à des tests de restauration réguliers. L’association de l’UEFI PXE, des pilotes NIC, du RAID et du BMC sur des serveurs physiques réels doit être validée indépendamment de ces tests sur VM.

10. Lectures complémentaires et bases techniques

Les procédures de mise en place et les résultats de validation sont reliés en une série de projets au sein du même portfolio. L’état et la portée de chaque article sont mis à jour sur la base des enregistrements de tests réels.

Zabbix Native HA, Cycle de vie des versions de Zabbix, Paramètres requis de NetBox et Redis Sentinel, Installation d’AWX Operator, Plugin d’inventaire NetBox pour Ansible, Cycle de support de Rocky Linux.

Lectures complémentaires et documents de configuration

Article original du portfolio · Guide de mise en place des réseaux en ligne et isolés · Scénarios de pannes et journal de validation · Journal de résolution des problèmes de configuration VirtualBox

ZIP des sources d’automatisation et de configuration du TP · ZIP SHA-256

Le ZIP public contient les modèles de configuration et les sources d’automatisation. Il n’inclut ni l’OS, ni les RPM, ni les images de conteneurs, ni les informations d’identification. À configurer avec votre propre adresse, votre CA publique, vos clés SSH autorisées et votre gestionnaire de secrets avant de l’appliquer.