Faire tourner Redis sur son serveur : cache, persistance, et le port qu'il ne faut pas laisser ouvert

Un binaire, deux bases de données

Presque personne n’installe Redis pour lui-même. Ce que les gens veulent, c’est soit un cache — un endroit rapide et jetable où garder des réponses calculées — soit un magasin qui survit à un redémarrage et détient des données auxquelles on tient vraiment. Redis peut être les deux, et le même apt-get install -y redis-server vous donne l’un ou l’autre, ce qui est précisément le piège. L’installation est triviale ; décider lequel des deux vous faites tourner est la décision qui compte, et Redis ne la prendra pas pour vous.

La thèse est donc étroite : le risque dans une installation Redis n’est jamais l’installation, c’est de faire tourner un magasin quand vous vouliez un cache, ou de laisser un cache ouvert sur Internet. Une erreur sur ce premier choix perd des données au prochain redémarrage. Une erreur sur le second offre à un inconnu un processus quasi-root sur un port public. Les deux sont de la configuration, pas de l’empaquetage.

Avant le premier paquet : lire la machine

Un serveur est rarement aussi vide qu’il en a l’air, et un second Redis empilé sur un Redis en marche est un désordre confus. La reconnaissance est la différence entre installer un service et entrer en collision avec un.

• Redis est-il déjà là, et quelle version ? command -v redis-server && redis-server --version. Si oui, vous configurez, vous n’installez pas — et réinstaller par-dessus une instance qui marche risque de la redémarrer à un moment que vous n’avez pas choisi.
• Un service tourne-t-il déjà ? systemctl is-active redis-server 2>/dev/null || systemctl is-active redis 2>/dev/null. L’unité s’appelle redis-server sur Debian et Ubuntu et redis sur la famille RHEL, et supposer la mauvaise est une erreur classique.
• Le port 6379 est-il déjà pris ? ss -tlnH 'sport = :6379' vous dit ce qui détient le port — et, tout aussi important, sur quelle interface il est lié. Un processus qui écoute déjà sur 0.0.0.0:6379 est une découverte, pas une note de bas de page.

1. Installer, mais seulement si c’est absent

Sur Debian et Ubuntu le paquet est redis-server ; sur la famille RHEL c’est redis. L’installation elle-même est l’étape la moins intéressante, et la seule règle qui compte est celle qu’on saute facilement sous la pression : si Redis est déjà installé et sert, ne réinstallez pas. Vérifiez la version, confirmez le service, et passez à la partie qui change le résultat.

La preuve que cette étape a marché n’est pas « la commande est sortie à 0 ». C’est une chaîne de version de redis-server --version — un fait concret qu’un humain ou un modèle peut lire sans deviner.

2. L’activer, puis prouver qu’il répond

Activez le démon pour qu’il survive à un redémarrage — systemctl enable --now redis-server — puis, essentiel, prouvez qu’il répond réellement plutôt que d’être seulement active. La vérification honnête est redis-cli ping qui renvoie PONG : elle exerce tout le chemin, socket et serveur, en un aller-retour. Une unité active mais qui ne répond pas à PING est un serveur que vous n’avez pas réellement testé.

3. Décider cache ou magasin — parce que le défaut n’est pas évident

C’est l’étape que tous les guides sautent et à laquelle tous les incidents remontent. Redis a deux mécanismes de persistance, et lequel est actif par défaut n’est pas quelque chose que vous devriez deviner.

• Les snapshots RDB écrivent un instantané à un instant donné, sur un planning. Rapides, compacts, et lossy par définition : tout ce qui a été écrit depuis le dernier snapshot disparaît si le processus meurt. Parfait pour un cache ; silencieusement inacceptable pour un magasin.
• L’AOF (append-only file) journalise chaque écriture, si bien que la reprise les rejoue. Bien plus durable, au prix d’un fichier plus gros et de plus d’I/O. C’est le mode que vous voulez quand les données dans Redis sont des données que vous ne pouvez pas recalculer.

L’erreur est de traiter Redis comme un magasin durable tout en faisant tourner des défauts de snapshot réglés pour un cache, et de découvrir l’écart seulement après un crash. Décidez le rôle d’abord, puis réglez la persistance pour qu’elle corresponde — et si c’est réellement un cache, assumez que les données sont jetables plutôt que de prétendre le contraire.

4. Le port : celui qui devient un mineur de cryptomonnaie

L’erreur Redis la plus lourde de conséquences est de l’exposer. Un Redis sans auth lié à 0.0.0.0 est l’un des services les plus fiablement exploités de l’Internet public : un attaquant se connecte, écrit un payload, et transforme votre hôte de base de données en mineur de cryptomonnaie ou en point de pivot. Il n’y a aucune nuance subtile ici — le correctif est deux réglages, appliqués ensemble :

• Lier à 127.0.0.1. Si la seule chose qui parle à Redis est une application sur la même machine, il n’a jamais besoin d’une interface publique. Liez au loopback et toute la classe d’attaques venant d’Internet disparaît.
• Définir requirepass. Si Redis doit réellement être joignable hors de la machine, il doit avoir un mot de passe, et la connexion doit être protégée en transit. Un Redis public sans auth n’est pas un risque que vous gérez, c’est une brèche que vous n’avez pas encore remarquée.

Pour un cache, ajoutez les deux réglages qui le maintiennent cache : un plafond maxmemory pour qu’il ne dévore pas la machine, et une politique d’éviction — allkeys-lru est le défaut sensé pour un cache pur — pour qu’il jette les vieilles clés au lieu de refuser les écritures une fois plein.

Ce que Redis ne fait pas pour vous

Redis n’est pas une file de messages durable avec des garanties de livraison ; traiter une liste comme un broker marche jusqu’à ce qu’un crash entre deux snapshots perde silencieusement des messages. Un nœud unique n’est pas de la haute disponibilité — cela demande de la réplication et Sentinel ou Cluster, et une décision que vous prenez exprès, pas un défaut dont vous héritez. Il ne chiffre pas les données au repos, et les builds plus anciens ne chiffrent pas en transit sans TLS configuré. Et rien dans l’installation de Redis ne sauvegarde quoi que ce soit : si vous avez choisi le rôle de magasin, le fichier de persistance est à vous de protéger. La commodité n’est pas de la durabilité.

La vérification qui prouve la posture, pas seulement l’installation

Dans l’ordre : redis-cli ping renvoyant PONG pour un serveur vivant ; ss -tlpn confirmant que Redis est sur 127.0.0.1:6379 et pas, en douce, sur 0.0.0.0 ; si un mot de passe a été défini, un AUTH qui réussit et une commande non authentifiée qui est refusée ; redis-cli config get maxmemory et la politique d’éviction relue comme ce que vous vouliez ; et systemctl is-enabled pour qu’il survive à un redémarrage. Prouvez l’adresse de bind, car c’est la ligne entre un cache privé et un incident public.

Ce que Servor apporte là-dedans

Servor livre Redis comme une recette — parmi 150+ playbooks vérifiés — et la forme d’une recette est ce qui empêche un service au défaut dangereux d’être négligent. Ce n’est pas un script figé tiré à l’aveugle : elle commence par la reconnaissance, en lisant si Redis est déjà installé, si le service tourne, et ce qui détient déjà le port 6379, pour que le run s’adapte à un serveur réel plutôt que d’en supposer un vide. Un modèle bon marché le pilote, et chaque étape qu’il propose porte sa propre vérification — la chaîne de version, le redis-cli ping renvoyant PONG — si bien que le succès est prouvé, pas affirmé. Le playbook est idempotent : un Redis existant est vérifié et rapporté plutôt que réinstallé par-dessus.

Les guardrails sont écrits précisément parce que le défaut est dangereux : si un mot de passe est fourni, la recette configure requirepass et lie au localhost, et elle ne laisse jamais Redis ouvert sur 0.0.0.0 sans authentification. La configuration dangereuse est celle que la recette refuse de produire.

Et l’exécution ne quitte jamais le chemin zero-knowledge : chaque commande est signée dans votre navigateur avec une clé dérivée de votre clé de vault, relayée verbatim, et vérifiée par l’agent sur la machine avant de s’exécuter. L’agent atteint le plan de contrôle via une connexion sortante, si bien qu’un Redis que vous avez correctement lié au loopback reste joignable pour l’administration sans jamais être exposé. Si Redis sert d’appui à une application que vous mettez en production, associez-le à la discipline de l’article PostgreSQL en production et à la boucle approuver-signer-vérifier de l’article Plan-Execute-Verify. Parcourez le reste du catalogue de recettes, ou voyez comment la partie opérationnelle s’articule dans notre guide d’exploitation des serveurs.