Aller au contenu
Tous les projets

Projet BTS SIO SISR

Les services qui font tourner un site

Annuaire, adressage, gestion de parc, supervision. Quatre services sur le cluster.

Contexte

Dernière réalisation du cas LGI2A. Le réseau et le cluster sont en place : il reste à installer les services de base du site de Brest. J’ai déployé chacun d’eux dans une VM ou un conteneur du cluster Proxmox, avec une adresse fixe dans le VLAN serveurs. Active Directory, GLPI et Uptime Kuma font partie du groupe HA du cluster.

Cluster Proxmox · réseau en VLANAnnuaireParcSupervisionRien n’est encore déployé dans le VLAN serveursLes demandes arrivent, aucun service ne répond
Avant : réseau et cluster en place, mais aucun service pour faire vivre le site.
Cluster Proxmox · réseau en VLANAnnuaireParcSupervisionRien n’est encore déployé dans le VLAN serveursLes demandes arrivent, aucun service ne répond

Annuaire et adressage : Windows Server 2022

  • Active Directory : création du domaine, des unités d’organisation et des stratégies de groupe (GPO) pour sécuriser le parc.
  • DNS pour la résolution interne du domaine.
  • DHCP avec douze étendues, une par VLAN. J’exclus de chaque plage l’adresse du switch et l’adresse virtuelle de la passerelle, pour éviter tout conflit avec la redondance réseau. Ce serveur reçoit les demandes que les relais DHCP des switchs de cœur lui renvoient.
  • Serveur de fichiers pour les partages des utilisateurs.

Gestion de parc : GLPI sur Debian 13

  • Pile LAMP installée à la main : Apache, MariaDB, PHP.
  • MariaDB n’écoute que sur la machine elle-même. La base contient l’inventaire et les tickets, elle n’a rien à faire sur le réseau.
  • Module d’assistance configuré pour suivre les demandes des utilisateurs.

Supervision : Uptime Kuma

  • Déployé avec Docker dans un conteneur LXC non privilégié. L’option d’imbrication autorise Docker sans donner les droits root de l’hôte.
  • Surveille la disponibilité des équipements et des services du site.
  • Alertes par mail via un Postfix qui n’écoute qu’en local.

Accès à distance : Tailscale

  • Déployé dans un conteneur LXC.
  • Sert uniquement à la prise en main à distance du site.
Windows Server 2022AD DS · DNS · DHCPGLPIDebian 13 · Apache · MariaDBsnapshot de la VMUptime KumaDocker dans un LXCalertes par mail (local)VLAN serveurs · adresses fixesTailscaleLXC · accès à distance
Après : trois services dans le VLAN serveurs, chacun avec son rôle. Tailscale, dans un conteneur LXC, sert à la prise en main à distance.
Windows Server 2022AD DS · DNS · DHCPGLPIDebian 13 · Apache · MariaDBsnapshot de la VMUptime KumaDocker dans un LXCalertes par mail (local)VLAN serveurs · adresses fixesTailscaleLXC · accès à distance

Comment j’ai vérifié

  1. Get-DhcpServerv4Scope : les douze étendues correspondent aux douze VLAN.
  2. Get-ADDomain et Resolve-DnsName : le domaine répond et se résout en interne.
  3. ss -tulpn sur GLPI : la base de données n’est visible qu’en local.
  4. docker ps et un test HTTP sur Uptime Kuma : le conteneur tourne et l’interface répond.
  5. Coupure volontaire d’un service : Uptime Kuma lève l’alerte.

Tests réalisés

  • Je coupe volontairement un service

    Uptime Kuma lève l'alerte

Ce que je ferais mieux

Un seul contrôleur de domaine porte tout l’annuaire. Un second contrôleur sur un autre nœud du cluster supprimerait ce point de panne.