MariaDB sur Debian - Guide DevOps complet pour la production

MariaDB sur Debian fonctionne très bien quand on veut une base SQL stable, facile à automatiser et simple à maintenir dans le temps. Le vrai sujet ne se limite pas à l’installation: il faut aussi choisir le bon mode d’authentification, décider si la base reste locale ou non, prévoir les sauvegardes et éviter les erreurs classiques de mise en production d’un backend web ou d’un outil interne. Dans cet article, je vais droit aux gestes utiles, avec une logique DevOps et des décisions qui tiennent la route sur un serveur réel.

Pourquoi MariaDB sur Debian reste un choix solide

Quand je déploie MariaDB sur Debian, j’aime surtout la prévisibilité de l’écosystème. Les paquets sont clairs, l’intégration à systemd est propre, et Debian garde une séparation utile entre le moteur, le client, la configuration commune et les outils de sauvegarde.

Le détail qui change la vie en exploitation, c’est le découpage des fichiers de configuration. Je préfère travailler avec des snippets sous /etc/mysql/mariadb.conf.d/ plutôt que de modifier un gros fichier à la main. C’est plus simple à versionner, plus simple à rejouer avec Ansible ou Salt, et plus lisible quand plusieurs personnes touchent au serveur.

Le démon réel derrière le service est mariadbd, mais au quotidien je pilote surtout le service mariadb via systemd. Pour un contexte DevOps, ce détail compte moins que la capacité à reproduire le même état sur plusieurs machines sans intervention manuelle.

• Installation reproductible avec apt, donc facile à intégrer à un playbook ou à une image de base.
• Service géré par systemd, ce qui facilite les vérifications d’état et les redémarrages contrôlés.
• Configuration modulaire, utile pour séparer les réglages de base, les options de performance et les exceptions locales.
• Outils alignés entre serveur et client, ce qui évite les surprises quand on passe de la machine de dev à la prod.

Ce socle est assez propre pour qu’on puisse passer ensuite à l’installation sans bricolage inutile.

Installer le serveur sans se compliquer

Je commence toujours par mettre l’index de paquets à jour, puis j’installe le serveur et le client. Sur un serveur Debian classique, le plus direct est souvent suffisant. J’installe aussi le client, parce qu’il sert tout de suite pour les vérifications locales et pour les scripts de déploiement.

sudo apt update
sudo apt install mariadb-server mariadb-client
sudo systemctl enable --now mariadb
sudo systemctl status mariadb

Le service démarre en général automatiquement, mais je vérifie quand même son état. Si je travaille sur une machine dédiée uniquement à la base, je garde cette séquence très courte. Si je prépare un socle plus complet pour un cluster, j’ajoute Galera seulement quand le besoin de haute disponibilité est réel, pas parce que cela fait plus sérieux sur le papier.

Pour valider rapidement que tout répond, j’utilise souvent un simple sudo mariadb. Sur beaucoup d’installations récentes, l’administration locale passe par le socket Unix, donc l’accès ne dépend pas forcément d’un mot de passe MariaDB. C’est précisément pour cela qu’il faut enchaîner avec la sécurité, pas la remettre à plus tard.

Une fois le service en place, le point suivant n’est pas la performance mais la réduction de surface d’attaque.

Verrouiller la sécurité dès le premier démarrage

Le script mariadb-secure-installation reste utile, même si certaines installations modernes utilisent déjà l’authentification par socket Unix pour root@localhost. Il permet de supprimer les comptes anonymes, retirer la base de test, bloquer l’accès root distant et, si besoin, poser un mot de passe pour les comptes d’administration.

Je le lance systématiquement sur les serveurs que je veux garder propres dans la durée. L’idée n’est pas de cocher une case, mais d’éviter de laisser traîner des réglages par défaut qui n’ont plus de raison d’exister une fois la base exposée à des données réelles.

Sur une installation neuve, le script peut demander le mot de passe root actuel. Quand rien n’a encore été défini, il suffit souvent d’appuyer sur Entrée puis de répondre avec pragmatisme aux questions proposées.

Pour une base applicative, je crée ensuite un utilisateur dédié avec des privilèges étroits, jamais le compte root. Je ne donne jamais root à une application, même en interne, parce que le jour où le code dérive ou qu’un secret fuit, l’impact est beaucoup trop large.

CREATE DATABASE appdb;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'mot_de_passe_fort';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;

Cette discipline évite la plupart des mauvaises surprises, et elle prépare directement la question suivante: qui peut se connecter, d’où, et avec quelles règles réseau.

Gérer les accès locaux et distants proprement

Sur Debian, beaucoup de configurations restent en écoute locale par défaut. C’est sain. Si le serveur ne doit servir qu’une application sur la même machine, je préfère laisser la base en local et garder bind-address sur 127.0.0.1. Si je dois vraiment accepter des connexions extérieures, je modifie ce point avec prudence, puis j’ajoute une règle de pare-feu et des privilèges SQL adaptés.

Dans un cas local-only, je garde souvent un réglage explicite comme celui-ci:

[mysqld]
bind-address = 127.0.0.1

Quand je dois ouvrir le service à un autre hôte, je pointe bind-address vers une adresse précise du réseau privé, pas vers toutes les interfaces. Le paramètre skip-networking est encore plus radical: il coupe complètement l’écoute TCP/IP. Je le garde en tête pour les serveurs qui ne doivent jamais recevoir de connexion réseau, uniquement des accès locaux via socket.

Quand une base doit être partagée dans un environnement de production ou de préproduction, je la mets d’abord derrière un réseau privé ou un VPN. Pour des données sensibles, je raisonne aussi en termes de conformité et de réduction d’exposition, pas seulement en termes de facilité d’accès. La meilleure base distante reste celle qu’on n’a pas besoin d’ouvrir plus que nécessaire.

Une fois le réseau cadré, il reste l’autre sujet qui décide de la qualité d’exploitation: la sauvegarde.

Choisir une stratégie de sauvegarde réaliste

Je distingue toujours deux besoins: la sauvegarde logique et la sauvegarde physique. La première est très pratique pour migrer, restaurer une table précise ou relire le contenu dans un fichier SQL. La seconde est plus adaptée aux bases plus grosses, aux fenêtres de maintenance courtes et aux restaurations rapides en production.

mariadb-backup est l’outil que je privilégie quand je veux une copie complète d’un serveur en fonctionnement, avec une interruption minimale. MariaDB le présente comme une sauvegarde physique en ligne, et c’est exactement ce qui le rend utile dans un contexte d’exploitation sérieux. Le nom a changé au fil des versions, donc si tu tombes encore sur mariabackup dans un vieux tutoriel, il s’agit de l’ancien nom.

sudo apt install mariadb-backup
mariadb-backup --backup --target-dir=/var/backups/mariadb/full --user=backup -p

À l’inverse, mariadb-dump reste précieux dès qu’on veut un format portable et lisible. La restauration se fait ensuite avec le client mariadb, ce qui est simple à automatiser et très pratique pour rejouer un export dans un environnement de test.

mariadb-dump --user=backup -p --all-databases > /backup/all.sql
mariadb --user=backup -p < /backup/all.sql

Le point que je considère non négociable, ce n’est pas la commande choisie, c’est le test de restauration. Une sauvegarde non restaurée reste une promesse, pas une preuve. Je préfère toujours vérifier le plan de reprise avant d’en avoir besoin, même si cela prend un peu de temps.

Cette rigueur de sauvegarde prend toute sa valeur quand elle est intégrée au cycle DevOps et non traitée comme une tâche isolée.

Adapter MariaDB à un contexte DevOps

Dans un environnement DevOps, je traite la base comme un composant déclaratif, pas comme une boîte noire installée à la main. Je versionne la configuration, j’automatise le déploiement, je sépare les secrets des fichiers de code et je décris la création des comptes ou des schémas au même niveau que le reste de l’infrastructure.

• Configuration gérée dans des snippets dédiés sous /etc/mysql/mariadb.conf.d/.
• Déploiement automatisé avec Ansible, Salt ou un autre outil d’orchestration déjà présent dans la chaîne.
• Supervision minimale du service, de l’espace disque, du taux d’erreur et de la latence des requêtes clés.
• Migrations versionnées, pour éviter les changements manuels impossibles à rejouer plus tard.
• Secrets séparés, afin qu’un mot de passe de base ne se retrouve jamais en clair dans un dépôt Git.

J’aime aussi garder une logique simple pour les vérifications de santé: le service doit répondre, le moteur doit accepter une requête triviale, et les journaux ne doivent pas montrer d’erreurs répétées. Quand j’ai besoin de plus de disponibilité, j’ajoute du clustering ou de la réplication seulement après avoir clarifié les objectifs de RPO et de RTO. Sans ces repères, on ajoute souvent de la complexité sans vraie valeur opérationnelle.

Tout cela mène à une dernière étape, plus terre à terre, mais décisive: valider ce qui doit l’être avant d’ouvrir la machine à la production.

Ce que je valide avant de passer en production

• Le compte d’administration local fonctionne via le mécanisme prévu, sans dépendre d’un contournement fragile.
• Aucun compte anonyme ni base de test ne reste accessible par erreur.
• Le port 3306 n’est pas exposé inutilement, surtout pas sur Internet public.
• Les sauvegardes sont planifiées, stockées hors du serveur et testées en restauration.
• La configuration est déclarée, relue et reproductible, pas seulement “celle qui marche sur ma machine”.
• Les mises à jour de paquets sont testées sur un environnement de préproduction avant d’être appliquées en production.
• Les alertes couvrent au minimum l’espace disque, le service MariaDB et les échecs de connexion anormaux.

Quand ces points sont en place, MariaDB sur Debian devient un composant très fiable du socle d’infrastructure. Le vrai gain n’est pas d’avoir “installé la base”, mais d’avoir une base documentée, redéployable et récupérable sans improvisation le jour où quelque chose casse.