MariaDB Enterprise Manager : guide d’installation standard et air‑gapped

Table des matières :

MariaDB Enterprise Manager : périmètre réel, architecture, angles morts

MariaDB Enterprise Manager (MEM) se positionne comme une brique de supervision/gestion pour des parcs MariaDB (souvent MariaDB Enterprise Server, mais pas uniquement). Techniquement, on est sur un triptyque classique : un composant “server” (UI + API), des “agents” au plus près des instances MariaDB (collecte, exécution d’actions), et un stockage (métriques/états/config) qui peut être interne au produit ou externalisé selon les déploiements. Ne partez pas du principe que MEM remplace vos outils existants : il ajoute une couche “opérations base de données”, pas une plateforme d’observabilité complète.

Pour bien cadrer le périmètre, posez-vous trois questions simples avant d’installer quoi que ce soit :

Qu’est-ce que je veux décider plus vite ? (capacité disque, dérive de latence, réplication en retard, saturation InnoDB…)
Qu’est-ce que je veux automatiser sans risque ? (redémarrage d’un agent, collecte de diagnostics, rotation de credentials…)
Qu’est-ce qui reste hors-champ ? (traces applicatives, erreurs PHP, latence réseau inter-services, goulots côté cache, CDN…)

Les angles morts typiques quand on déploie un outil “DB ops” comme MEM :

Corrélation applicative : MEM peut vous dire “la base souffre”, mais pas pourquoi côté code (N+1, requêtes non indexées, lock storms déclenchés par un batch).
Données de requêtes sensibles : selon votre configuration (ex. capture de requêtes lentes, exemples de SQL, usernames/hosts), vous pouvez manipuler des données pouvant être considérées comme sensibles. En contexte France/UE, pensez minimisation et durées de conservation (RGPD) : conserver l’utile, purger le reste.
Chaîne d’alerte : un dashboard non relié à des runbooks/tickets n’améliore pas le MTTR. L’outil ne remplace pas le processus.

Le point clé pour des stacks e-commerce (PrestaShop, API, back-office) : MEM vous évite de piloter MariaDB “à l’aveugle” via des scripts ad-hoc, mais il ne corrige pas les anti-patterns applicatifs. Si vous êtes en souffrance sur la latence checkout ou des pages produit, vous aurez toujours besoin de relier métriques DB et requêtes applicatives (profiling, slow logs, corrélation). Pour la partie diagnostic requêtes, le bon ordre est souvent : d’abord un audit (et des quick wins), puis instrumentation et alerting. Voir : Audit MySQL/MariaDB : optimiser les requêtes lentes e‑commerce.

Mini-scenario (réaliste) en prod : à 11h58, montée de trafic “midi” → Threads_running grimpe, InnoDB_row_lock_time augmente, et les timeouts PHP-FPM explosent. MEM vous aide à objectiver : est-ce un problème de saturation (CPU/IO), de contention (locks), de connexions (thread pool/pool applicatif), ou une réplication en retard qui amplifie les lectures sur le primaire ? Ensuite seulement, vous basculez côté applicatif pour retrouver quelles requêtes ont changé (déploiement, import, bot).

Enfin, gardez une idée simple : la supervision est une chaîne, pas un écran. Comme le résume Prometheus (outil souvent utilisé en parallèle ou en “source d’inspiration” pour les modèles de collecte) : “Prometheus is an open-source systems monitoring and alerting toolkit.” (Voir : Prometheus Docs). MEM doit s’intégrer à votre chaîne (alerting, tickets, runbooks, SSO), sinon il restera un dashboard consulté trop tard.

Pré-requis techniques (standard vs air‑gapped) et choix d’implémentation

Sur un déploiement standard (connecté), vous cherchez la friction minimale : DNS propre, TLS, accès aux dépôts (packages ou registry), et une VM/instance dédiée au composant server. Sur un déploiement air‑gapped (réseau isolé, sans egress Internet), vous cherchez l’inverse : reproductibilité, artefacts signés, miroirs contrôlés, et procédures d’upgrade/break-glass documentées. Les deux mondes partagent le même socle : système, stockage, réseau et comptes.

Une grille de lecture utile (pour éviter les “oui mais…” au moment de l’upgrade) :

Sujet	Standard (connecté)	Air‑gapped (isolé)
Dépendances OS	“On installe à la volée”	Miroir OS (DEB/RPM) + dépendances figées
Images conteneurs	Pull direct depuis registry éditeur	Registry interne + transfert contrôlé
Correctifs sécurité	Patchs continus	Fenêtres de patch planifiées + stock d’artefacts validés
Secrets (tokens, DB users)	Vault/SSO “facile”	Gestion offline + rotation processée
Observabilité globale	Intégrations SaaS possibles	Collecte on-prem uniquement (SIEM/monitoring internes)

Côté plateformes, partez sur du banal et supportable : Debian 12 / Ubuntu 24.04 LTS / RHEL 9, kernel récent, et si vous passez par des conteneurs, Docker Engine 26+ ou Podman 5+. Rappelez-vous ce que dit la doc Docker (et ce que ça implique en termes de cycle de vie) : “Docker is an open platform for developing, shipping, and running applications.” (Voir : Docker Docs). “Open platform” ne veut pas dire “zéro maintenance” : mises à jour, CVE, rotation de secrets, et compatibilité kernel/cgroups restent votre problème.

Pré-requis “souvent oubliés” (et qui cassent des installs autrement “propres”) :

NTP/chrony cohérent partout (server MEM, nœuds DB, bastions). Sans ça, vous aurez des graphes incohérents et des erreurs TLS (validité des certificats).
Résolution DNS fiable (A/AAAA, reverse si vous faites du contrôle d’accès par hostname).
TLS interne : même si tout est “dans le LAN”, ne laissez pas les credentials circuler en clair.
Politique de rétention : décidez avant de collecter (sinon votre disque décidera pour vous).

Pour dimensionner proprement, évitez les estimations “à l’œil”. La charge MEM dépend surtout du nombre d’instances surveillées, de la rétention des métriques et de la granularité de collecte. En pratique :

CPU : 2–4 vCPU suffisent souvent pour un petit parc, mais montez si vous activez des collectes fréquentes et des historiques longs.
RAM : 4–8 Go minimum côté server, plus si la stack embarque un moteur de métriques gourmand.
Disque : SSD obligatoire ; surveillez l’IOPS et la croissance (rétention × cardinalité).

Repère simple (à ajuster après une semaine de mesures) : si vous collectez “fin” (toutes les 5–10s) et gardez 30–90 jours, votre facteur limitant sera généralement le stockage (et la compaction) plus que le CPU. En air‑gapped, anticipez aussi l’espace nécessaire aux artefacts (images, paquets, signatures, manifests) : ce n’est pas énorme, mais c’est critique pour les upgrades.

Installation standard (connectée) : chemin “propre” et reproductible

La méthode la plus robuste en 2026 est généralement une installation conteneurisée (ou à défaut une installation par packages) déclarée : compose.yaml versionné, variables dans un vault, et déploiement automatisé. L’objectif n’est pas d’“installer” MEM une fois, mais de pouvoir reconstruire l’environnement en 30 minutes après incident. Si vous êtes déjà dans une logique IaC, alignez-vous avec votre pratique Terraform/containers : DevOps : Infrastructure as Code avec Terraform et conteneurs.

Avant le déploiement, verrouillez le minimum “exploitation” :

FQDN dédié (ex. mem.exemple.tld) + certificat (AC interne ou publique selon exposition).
Journalisation : où vont les logs ? combien de temps ? qui y accède ?
Sauvegardes : quels volumes/dossiers ? quelle fréquence ? test de restore programmé.
Accès admin : uniquement via VPN/bastion, pas d’ouverture “temporaire” d’IP publiques.

Sur le serveur MEM, commencez par la base non négociable : un compte système dédié, un répertoire de données, des limites systemd, et un pare-feu restrictif. Exemple (Debian 12) :

sudo adduser --system --group --home /var/lib/mem mem
sudo mkdir -p /var/lib/mem /etc/mem
sudo chown -R mem:mem /var/lib/mem /etc/mem

# Exemple de pare-feu : n’ouvrez que l’UI/API et les flux internes nécessaires
sudo ufw allow 443/tcp
sudo ufw allow from 10.0.0.0/8 to any port 443 proto tcp
sudo ufw enable

Deux bonnes pratiques qui évitent des incidents “bêtes” :

Reverse proxy (Nginx/Apache/Traefik) en frontal pour normaliser TLS, timeouts, headers, et éventuellement poser une couche SSO (selon votre stack). Même si MEM a son propre TLS, avoir une entrée unique simplifie la rotation des certificats.
Secrets hors Git : tout ce qui est token, mot de passe, clé privée doit être injecté via un mécanisme de secrets (vault, fichiers chiffrés, variables d’environnement sécurisées), jamais “en dur” dans compose.yaml.

Ensuite, vous verrouillez les prérequis d’accès MariaDB côté agents : TLS, utilisateur de collecte en moindre privilège, et timeouts cohérents. Exemple de base (à adapter selon ce que l’agent requiert réellement) :

-- MariaDB 11.4+ (adapter host et plugin auth)
CREATE USER 'mem_agent'@'10.%' IDENTIFIED BY 'CHANGE_ME_STRONG';

-- Droits typiques de lecture/inspection ; à réduire après validation fonctionnelle
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'mem_agent'@'10.%';
GRANT SELECT ON performance_schema.* TO 'mem_agent'@'10.%';
GRANT SELECT ON information_schema.* TO 'mem_agent'@'10.%';
FLUSH PRIVILEGES;

Astuce “qualité” : créez un profil de privilèges (documenté) par type de nœud (primaire, replica, instance de dev) pour éviter les dérives. Et consignez dès le début : qui gère la rotation du mot de passe mem_agent, à quelle fréquence, et comment les agents sont mis à jour sans interruption.

Déployer les agents sur les nœuds MariaDB : collecte, latence, et “blast radius”

Déployer des agents sur des serveurs de base en prod n’est pas anodin. Votre contrainte, c’est le blast radius : un agent instable ne doit pas pouvoir impacter mysqld (CPU, IO, locks, saturation réseau) ni dégrader les temps de réponse applicatifs. Appliquez trois règles : limites de ressources (cgroups), collecte espacée (éviter le “scrape” toutes les secondes), et chemins de rollback (désinstallation/arrêt en 1 commande).

Concrètement, visez une posture “l’agent est un invité” :

CPU/RAM plafonnés (surtout sur des VM petites où mysqld est déjà proche de la limite).
IO évité : pas de dumps intempestifs, pas d’écriture de fichiers volumineux en local.
Réseau maîtrisé : compression si disponible, collecte groupée plutôt que bavarde.

Un pattern opérationnel efficace : commencer par un seul nœud non critique (replica si vous en avez), puis élargir. Vous comparez les métriques système avant/après et vous validez que l’agent ne modifie pas la charge de manière significative pendant une heure “chaude” (pic trafic, batch, indexation).

Sur des workloads PrestaShop à pics (campagnes, soldes), la corrélation utile est rarement “CPU élevé”. Elle ressemble plutôt à : augmentation du Threads_running, files d’attente InnoDB, hausse de latence côté pool de connexions PHP-FPM, ou taux de deadlocks. Les nouveautés et correctifs DB influencent directement ce que vous observez : si vous migrez en MariaDB 11.4, relisez les impacts optimiseur/InnoDB pour interpréter les métriques (plan changes, stats, etc.). Référence : MariaDB 11.4 : nouveautés, correctifs InnoDB et optimiseur.

Deux points concrets à surveiller au moment où vous activez l’agent :

Surcoût des lectures performance_schema : en général maîtrisé, mais si vous avez des settings agressifs ou un serveur déjà borderline, certaines collectes peuvent devenir visibles.
Effet “multi-agents” : le vrai risque arrive quand vous déployez 20–100 agents d’un coup avec une granularité trop fine, et que le server MEM devient lui-même un point de saturation (rafales de collecte, pics d’écriture métriques).

Dernier point : les droits SQL de l’agent doivent être testés comme un contrat. Mettez en place un test d’intégration simple (CI ou runbook) qui exécute les requêtes utilisées par l’agent (SHOW STATUS/VARIABLES, lectures performance_schema) et échoue si un privilège manque. Ça vous évite l’anti-pattern “on met GRANT ALL parce que ça marche”. Pour durcir l’accès MariaDB (TLS, privilèges minimaux, audit), vous pouvez croiser avec : Renforcer MySQL/MariaDB : pare-feu, TLS, privilèges minimaux et audit.

Installation air‑gapped : stratégie d’artefacts, dépôts miroirs et registry privé

Un déploiement air‑gapped ne se résume pas à “copier un tar.gz”. Vous devez traiter l’installation comme une supply chain : d’où viennent les binaires/images, comment vous vérifiez leur intégrité, comment vous les promouvez d’un environnement à l’autre, et comment vous tracez exactement quelle version tourne en prod. Sans ça, vous aurez une prod “isolée” mais impossible à maintenir.

Le schéma le plus réaliste :

Une zone connectée (bastion build) qui télécharge packages/images depuis l’éditeur.
Un stockage d’artefacts interne (Nexus/Artifactory/S3 on-prem) + registry OCI privé.
Un transfert contrôlé (support amovible chiffré ou lien unidirectionnel) vers la zone isolée.
Une installation dans la zone isolée en pointant exclusivement sur vos miroirs internes.

En air‑gapped, ce qui fait la différence le jour où “ça casse” :

Un manifest d’artefacts : liste des images/paquets, versions, hashes (SHA256), date de récupération, source. C’est votre “vérité” quand vous devez reconstituer une base logicielle.
Un process de promotion : vous ne copiez pas “prod” directement. Vous validez d’abord en dev, puis préprod, puis prod avec les mêmes artefacts.
Une stratégie de scan (si votre politique sécurité l’exige) dans la zone connectée, avant transfert : c’est là que vous avez les outils et les signatures à jour.

Si MEM est déployé en conteneurs, vous pouvez “aspirer” les images vers votre registry offline via skopeo (ou équivalent) depuis la zone connectée, puis les répliquer. Exemple (conceptuel) :

# Zone connectée : copie depuis registry éditeur -> registry interne
skopeo copy \
  docker://REGISTRY_EDITEUR/mem/server:VERSION \
  docker://registry.interne.local/mem/server:VERSION

# Export pour transfert (si pas de réplication réseau)
podman save -o mem-server-VERSION.tar registry.interne.local/mem/server:VERSION
sha256sum mem-server-VERSION.tar > mem-server-VERSION.tar.sha256

Bon réflexe : dans la zone isolée, refaites la vérification du hash après transfert (erreurs de copie, support défectueux, manipulation). Conservez aussi l’historique des manifests : ce n’est pas “du confort”, c’est ce qui permet un rollback propre.

Côté packages (DEB/RPM), la mécanique est similaire : vous construisez un miroir (apt repo / yum repo) signé, et vous bloquez toute résolution vers l’Internet. Le point le plus souvent négligé : la gestion des dépendances transverses (OpenSSL, libstdc++, ca-certificates). Une upgrade “mineure” du produit peut exiger une dépendance système plus récente ; en air‑gapped, ça devient une panne si vous n’avez pas anticipé le miroir OS.

Enfin, pensez à un point très opérationnel : les certificats (AC interne, CRL/OCSP éventuels) et l’heure système. En air‑gapped, vous n’avez pas “la correction automatique” via Internet, donc la rotation et la distribution des CA doivent être un processus documenté, pas une action manuelle en panique.

TLS, SSO, RBAC, sauvegardes : le durcissement qui évite les incidents idiots

Par défaut, un outil de management DB devient rapidement un point de pivot. Vous devez donc traiter MEM comme un composant sensible : TLS partout, authentification centralisée si possible (SSO), RBAC strict, et isolation réseau (aucun accès depuis Internet, accès admin depuis VPN/bastion). Pour les flux TLS côté MariaDB, n’oubliez pas que vous sécurisez à la fois la confidentialité et l’intégrité, mais aussi la résilience : un mauvais paramétrage TLS peut casser la collecte (CA expirée, rotation oubliée).

Un durcissement pragmatique (et généralement compatible avec des contraintes d’exploitation en France/UE) :

Segmentation réseau : MEM server accessible depuis un sous-réseau d’admin, agents autorisés uniquement à parler au server MEM, et agents autorisés à parler au port MariaDB sur les nœuds DB (et rien d’autre).
RBAC minimal : un rôle “lecture” pour la majorité (exploitation/produit) et un rôle “admin” rare, nominatif, journalisé. Évitez les comptes partagés.
Journal d’audit : qui s’est connecté, quand, et quelles actions sensibles ont été lancées (au minimum). Conservez-le selon votre politique interne.
Gestion des secrets : rotation planifiée des comptes agents et des tokens d’API ; révocation testée (le jour où un compte fuit, vous ne voulez pas “découvrir” la procédure).

Sur la partie stockage de MEM (métriques/config), mettez en place une sauvegarde cohérente dès J1. Ça implique : répertoire de données (si conteneur), base interne (si le produit stocke dans une DB), et secrets/config (variables d’environnement, fichiers). Objectif : restauration testée, RTO/RPO réalistes. Si vous avez déjà des procédures de sauvegarde DB pour vos boutiques, alignez-les avec le même niveau d’exigence (rotation, chiffrement, tests). Vous pouvez aussi comparer l’approche “outil dédié” vs “observabilité générique” avec : Netdata : intégrer Prometheus, SNMP et StatsD pour tout surveiller.

Enfin, définissez des règles d’alerte exploitables, pas du bruit. Si votre organisation a déjà un stack Prometheus/Alertmanager, vous avez intérêt à harmoniser : labels, severity, et runbooks. Pour des exemples concrets de PromQL/alerting (et éviter les alertes inutiles), voir : Prometheus : configuration des alertes, métriques et requêtes PromQL.

Point “terrain” : une bonne alerte doit répondre à quoi faire maintenant. Exemple de formulation utile : “Réplication en retard > 300s sur shop-db-replica-2 depuis 10 min — runbook : vérifier IO, état SQL thread, saturation réseau, puis bascule lecture si nécessaire”. Une mauvaise alerte : “CPU > 80%” sans contexte, sans durée, sans action.

Checklist de validation post‑installation (standard et air‑gapped)

Valider une installation MEM ne se limite pas à “l’UI s’ouvre”. Vous voulez un protocole de validation court, répétable, qui couvre réseau, sécurité et utilité. Premier lot : connectivité (server ↔ agents ↔ MariaDB), latence acceptable, et absence d’erreurs récurrentes dans les logs. En pratique : testez la collecte sur un nœud, puis sur un replica, puis sur le primaire, et comparez le coût (CPU/IO) pendant un pic applicatif.

Checklist “connectivité & sécurité” (10–15 minutes) :

[ ] Accès UI/API en TLS (certificat valide, chaîne complète, redirections OK).
[ ] Accès restreint : pas d’ouverture inutile (IP publiques, ports non requis).
[ ] Agent(s) visibles et “healthy”.
[ ] Compte SQL mem_agent actif, pas de privilèges excessifs, et authentification compatible avec votre politique (rotation, stockage secret).
[ ] Horloges synchronisées (pas d’écarts évidents dans les timestamps logs/métriques).
[ ] En air‑gapped : toutes les images/paquets proviennent exclusivement du registry/miroir interne, et le manifest d’artefacts est archivé.

Deuxième lot : données exploitables. Assurez-vous que les métriques critiques sont bien présentes (connexions, requêtes, temps de réponse, InnoDB, réplication), que les dashboards ne sont pas vides, et que la granularité correspond à vos cas d’usage (incident = minutes, capacity planning = semaines/mois). Si votre problématique est la performance front/back PrestaShop, ne confondez pas “métriques DB” et “causes applicatives” : vous devrez souvent relier MEM à vos logs PHP/Nginx et à un audit SQL. Une lecture utile en parallèle : PrestaShop lent : diagnostic TTFB, bots et optimisation serveur.

Checklist “utilité opérationnelle” (30–60 minutes) :

[ ] Un dashboard “incident” lisible (sur 1h) et un dashboard “tendance” (sur 30j).
[ ] Au moins 3 alertes actionnables activées (ex. disque, réplication, erreurs InnoDB), avec seuils réalistes.
[ ] Un runbook court par alerte critique (même 5 lignes) : symptôme → vérifs → actions → escalade.
[ ] Une corrélation “boutique” : pendant un pic, vous savez relier une dégradation TTFB à un signal DB (threads, locks, IO) et revenir aux requêtes. Pour accélérer cette étape, gardez sous la main un diagnostic orienté requêtes lentes : optimisation des requêtes lentes côté e‑commerce.

Troisième lot : opérations. Documentez (et testez) : ajout d’un nouveau nœud, rotation CA/certificats, révocation d’un compte agent, upgrade de version, et procédure d’arrêt propre. En air‑gapped, ajoutez deux items obligatoires : inventaire exact des artefacts (hash, signature, provenance) et procédure de promotion (dev → preprod → prod) sans accès Internet. Si vous ne pouvez pas exécuter cette checklist sans “improviser”, votre installation n’est pas prête.