Guide complet Redis sous Docker : persistance et authentification par mot de passe

Enfin, le conteneur Redis tourne. Vous testez quelques interfaces, lecture/écriture OK. Le lendemain, vous ouvrez l’ordinateur pour vérifier l’état du service — toutes les données ont disparu. Coup au cœur.

Vous avez peut-être déjà vécu ça : après un redémarrage Docker, les données Redis semblent n’avoir jamais existé. Sessions utilisateur perdues, paniers vidés, cache effacé. Pire encore, on ne sait pas pourquoi ni comment y remédier.

Franchement, la première fois que ça m’est arrivé, j’étais paniqué. Petit projet, données de test envolées — pas la prod, mais cette impuissance dérange. On comprend ensuite que le conteneur est « temporaire » par nature : le supprimer efface les données ; le redémarrer sans persistance, c’est pareil.

Cet article vous guide pas à pas pour :

• Configurer la persistance RDB et AOF, afin que Redis ne perde pas les données au redémarrage du conteneur
• Activer l’authentification par mot de passe, pour éviter un accès non autorisé (des Redis sans mot de passe ont déjà servi au minage par des pirates)
• Monter un fichier de configuration, pour un déploiement Redis normé et maintenable
• Les bonnes pratiques production : journaux, healthcheck, optimisation des performances

Que vous soyez développeur backend, ingénieur DevOps ou débutant Docker, en suivant ce guide vous déployez un conteneur Redis de niveau production.

Pourquoi un conteneur Redis perd-il des données ?

Analogie : un conteneur Docker, c’est comme une chambre d’hôtel — au check-out, tout est vidé. Idem pour le conteneur : supprimez-le, les données partent.

Par défaut, Redis stocke sur le système de fichiers interne au conteneur. Les écritures vont vers /data/dump.rdb ou /data/appendonly.aof. Problème : ces chemins sont dans le conteneur. Suppression ou recréation du conteneur, et les fichiers disparaissent.

Cas réel : une startup déploie Redis en test sans persistance. Redémarrage serveur, toutes les sessions perdues, paniers vides. Même en test, l’équipe a compris que la conteneurisation impose la persistance des données.

Environ 70 % des pertes de données Redis sous Docker viennent d’une persistance non configurée. Ce piège, presque tout le monde le prend une fois.

Rôle du Volume Docker

Le Volume (data volume), c’est la clé : comme sauvegarder sur le cloud plutôt que sur le disque local du PC.

Avec -v, vous montez un répertoire hôte dans le conteneur : les données vivent sur l’hôte. Conteneur supprimé, données intactes ; redémarrage, relecture possible. D’où l’obligation en production de monter un volume de données.

En bref :

• Sans volume = données dans le conteneur = suppression = perte
• Avec volume = données sur l’hôte = conteneur supprimé, données conservées

Déploiement rapide d’un Redis de base

Avant la persistance, déployons le conteneur le plus simple pour voir concrètement l’absence de persistance.

Démarrer le conteneur de base

Dans le terminal :

docker run -d --name redis-basic -p 6379:6379 redis:latest

Signification :

• -d : arrière-plan
• --name redis-basic : nom du conteneur
• -p 6379:6379 : mappe le port 6379 du conteneur sur l’hôte
• redis:latest : image Redis la plus récente

Docker tire l’image si besoin, puis démarre le conteneur.

Vérifier que le conteneur fonctionne

docker ps

Si redis-basic est en Up, tout va bien.

Test lecture/écriture :

docker exec -it redis-basic redis-cli

Dans redis-cli :

set test "hello"
get test

Si la réponse est "hello", Redis répond correctement.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Limites de cette version minimale

Trois problèmes majeurs :

1. Pas de persistance : redémarrage = données perdues
2. Pas de mot de passe : n’importe qui peut se connecter
3. Configuration par défaut : pas de limite mémoire ni de stratégie de persistance personnalisée

Testez après redémarrage :

docker restart redis-basic
docker exec -it redis-basic redis-cli
get test

La clé test a souvent disparu — effet d’une persistance non configurée.

Configurer la persistance RDB (instantanés)

Redis propose RDB et AOF. Commençons par RDB, plus simple pour débuter.

Qu’est-ce que le RDB ?

RDB signifie Redis Database — un « instantané » de la base en mémoire. Périodiquement, Redis écrit tout dans un fichier dump.rdb.

Avantage : reprise rapide. Inconvénient : possible perte des écritures depuis le dernier instantané (ex. règle toutes les 5 minutes → jusqu’à 5 minutes de données en cas de crash).

Paramètres RDB

Contrôlé par save :

save <secondes> <nombre de clés modifiées>

Exemples :

• save 900 1 : au moins 1 clé modifiée en 900 s (15 min)
• save 300 10 : au moins 10 clés en 300 s (5 min)
• save 60 10000 : au moins 10000 clés en 60 s

Ces règles sont en OU : la première satisfaite déclenche la sauvegarde.

Monter un volume pour la persistance

Configurer RDB ne suffit pas : montez le volume sur l’hôte pour que dump.rdb survive à la suppression du conteneur.

mkdir -p ~/redis-data

Puis :

docker run -d \
  --name redis-rdb \
  -p 6379:6379 \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server --save 60 1 --dir /data

Points clés :

• -v ~/redis-data:/data : montage hôte → /data dans le conteneur
• --save 60 1 : test (1 clé en 60 s) — en prod, augmentez l’intervalle
• --dir /data : chemin du fichier RDB

Vérifier que la persistance fonctionne

docker exec -it redis-rdb redis-cli
set user:1 "Jean"
set user:2 "Marie"

Attendez ~60 s pour l’instantané, puis :

docker restart redis-rdb
docker exec -it redis-rdb redis-cli
get user:1

Si vous obtenez "Jean", la persistance est OK.

Sur l’hôte, ~/redis-data/dump.rdb doit exister — c’est l’instantané Redis.

Configurer la persistance AOF (journal)

Le RDB peut perdre les écritures après le dernier instantané. Pour une exigence forte sur l’intégrité des données, utilisez l’AOF.

Qu’est-ce que l’AOF ?

AOF = Append Only File. Chaque écriture (set, del, incr, etc.) est ajoutée à appendonly.aof.

Image : RDB = photo périodique, AOF = enregistrement continu. RDB = clichés espacés ; AOF = chaque action.

Avantage : plus sûr (souvent ≤ 1 s de perte avec everysec). Inconvénient : fichier plus volumineux, reprise un peu plus lente.

Trois stratégies de synchronisation AOF

1. appendfsync always : sync disque à chaque écriture — très sûr, performances faibles, peu adapté au fort trafic
2. appendfsync everysec : sync chaque seconde — recommandé en production, perte max ~1 s
3. appendfsync no : laissé à l’OS — performances max, risque de perte plus élevé, déconseillé

Démarrer Redis avec AOF

mkdir -p ~/redis-data

docker run -d \
  --name redis-aof \
  -p 6379:6379 \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server --appendonly yes --appendfsync everysec --dir /data

Paramètres :

• --appendonly yes
• --appendfsync everysec
• --dir /data

Après un moment :

ls ~/redis-data/

Vous devriez voir appendonly.aof.

Persistance hybride (Redis 4.0+, recommandé)

Depuis Redis 4.0, le mode hybride combine RDB et AOF :

• RDB pour une reprise rapide
• AOF pour la sécurité des données

Dans la config :

aof-use-rdb-preamble yes

Au redémarrage : chargement du préambule RDB, puis rejeu du delta AOF post-RDB.

Avec Redis 4.0+, le mode hybride est en général le bon choix — inutile de trancher RDB ou AOF.

Gérer Redis via un fichier de configuration (production)

Les paramètres en ligne de commande (--appendonly yes, etc.) deviennent illisibles quand ils se multiplient.

En production, standard = fichier de configuration.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Pourquoi un fichier de config ?

• Toute la config au même endroit
• Versionnable (Git)
• Partageable en équipe
• Modifications sans ressaisir une longue commande docker run

Pour un Redis longue durée, ne passez pas par des dizaines d’arguments CLI.

Obtenir la config standard

mkdir -p ~/redis-config
docker run --rm redis:latest cat /etc/redis/redis.conf > ~/redis-config/redis.conf

Personnaliser redis.conf

Ouvrez redis.conf et adaptez :

1. Réseau

# Autoriser toutes les IP (en prod, préférez l'IP interne)
bind 0.0.0.0

# Désactiver le mode protégé (après mot de passe)
protected-mode no

2. Authentification

requirepass YourStrongPassword123

3. Persistance

save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

aof-use-rdb-preamble yes

dir /data

4. Mémoire max

maxmemory 512mb
maxmemory-policy allkeys-lru

5. Journaux

loglevel notice
logfile ""

Démarrer avec le fichier de config

docker run -d \
  --name redis-prod \
  -p 6379:6379 \
  -v ~/redis-config/redis.conf:/usr/local/etc/redis/redis.conf \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server /usr/local/etc/redis/redis.conf

redis-server /usr/local/etc/redis/redis.conf indique le fichier à utiliser.

Vérifier la config

docker exec -it redis-prod redis-cli -a YourStrongPassword123
config get save
config get appendonly
config get maxmemory

Les valeurs doivent correspondre au fichier.

Authentification par mot de passe (3 méthodes)

Fait réel : Redis sans mot de passe exposé sur Internet, compromis et détourné pour le minage. Ce n’est pas une blague.

Pourquoi un mot de passe est obligatoire

Par défaut, Redis n’a pas de mot de passe. Port exposé (Internet ou réseau non fiable) = risque majeur.

En production, mot de passe = ligne de base.

Méthode 1 : paramètre en ligne de commande

docker run -d \
  --name redis-pwd \
  -p 6379:6379 \
  redis:latest \
  redis-server --requirepass "MyStr0ng#P@ssw0rd"

Pratique pour un test rapide ; évitez en production — le mot de passe reste dans l’historique shell.

Méthode 2 : fichier de config (recommandé)

requirepass YourStrongPassword123

Puis montage de redis.conf comme ci-dessus. Standard en équipe : pas d’exposition dans l’historique, gestion centralisée.

Recommandations :

• Au moins 16 caractères
• Majuscules, minuscules, chiffres, symboles
• Pas de mots courants ni de date de naissance

Méthode 3 : modification dynamique

Conteneur déjà lancé :

docker exec -it redis-pwd redis-cli
config set requirepass "NewPassword123"

Perdu au redémarrage — urgence uniquement.

Se connecter avec mot de passe

Option 1 : mot de passe sur la ligne de commande

docker exec -it redis-pwd redis-cli -a "MyStr0ng#P@ssw0rd"

Option 2 : AUTH après connexion

docker exec -it redis-pwd redis-cli
auth MyStr0ng#P@ssw0rd
set test "hello"

Erreur si mot de passe incorrect :

(error) NOAUTH Authentication required.

Utilisez auth pour vous authentifier.

Connexion depuis l’application

Chaîne de connexion :

redis://:YourStrongPassword123@localhost:6379

Exemple Node.js :

// Exemple Node.js
const redis = require('redis');
const client = redis.createClient({
  host: 'localhost',
  port: 6379,
  password: 'YourStrongPassword123'
});

Déploiement avec Docker Compose (équipes)

docker run devient pénible sur des commandes longues. En équipe ou multi-conteneurs, Docker Compose est préférable.

Intérêt de Docker Compose

• Config dans docker-compose.yml, versionnable
• Démarrage en une commande
• Environnement identique pour toute l’équipe
• Plusieurs services (Redis + MySQL + Nginx, etc.)

Exemple docker-compose.yml complet

version: '3.8'

services:
  redis:
    image: redis:7.2-alpine
    container_name: redis-prod
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - ./redis-config/redis.conf:/usr/local/etc/redis/redis.conf
      - ./redis-data:/data
    command: redis-server /usr/local/etc/redis/redis.conf
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

volumes:
  redis-data:
    driver: local

Notes :

• image: redis:7.2-alpine : image légère Alpine
• restart: always : redémarrage automatique
• volumes : config + données
• healthcheck : ping toutes les 10 s

Démarrage en une commande

docker-compose up -d

État, journaux, arrêt, redémarrage

docker-compose ps
docker-compose logs -f redis
docker-compose down
docker-compose restart redis

docker-compose down supprime le conteneur, pas le volume (données conservées).

Stack multi-services

version: '3.8'

services:
  redis:
    # config Redis...

  mysql:
    image: mysql:8.0
    # config MySQL...

  app:
    build: .
    # config app...
    depends_on:
      - redis
      - mysql

Redis, MySQL et l’app démarrent ensemble avec les dépendances gérées.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Dépannage et bonnes pratiques

Consulter les journaux

docker logs --tail 100 redis-prod
docker logs -f redis-prod

Avec Compose :

docker-compose logs -f redis

Les logs indiquent démarrage, erreurs de config, connexions suspectes, etc.

Healthcheck

healthcheck:
  test: ["CMD", "redis-cli", "ping"]
  interval: 10s
  timeout: 3s
  retries: 3

Toutes les 10 s, redis-cli ping ; 3 échecs → conteneur unhealthy. Avec restart: always, redémarrage automatique.

Optimisation des performances

1. Limiter la mémoire

maxmemory 512mb
maxmemory-policy allkeys-lru

allkeys-lru : à saturation, éviction des clés les moins récemment utilisées.

2. Désactiver les commandes dangereuses

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command KEYS ""

3. Fréquence de persistance

Les save par défaut conviennent à beaucoup de cas. Redis surtout cache, tolérance à la perte : intervalles plus larges possibles.

Renforcement sécurité

1. Ne pas exposer Redis sur Internet

Accès distant : tunnel SSH ou VPN.

bind 127.0.0.1 192.168.1.100

2. Mot de passe fort

requirepass Th1s!sA$tr0ngP@ssw0rd2024

3. Sauvegardes régulières

Même avec persistance, sauvegardez. Exemple de script :

#!/bin/bash
DATE=$(date +%Y%m%d)
cp ~/redis-data/dump.rdb ~/redis-backup/dump-$DATE.rdb
cp ~/redis-data/appendonly.aof ~/redis-backup/appendonly-$DATE.aof

Checklist production

• ✅ Persistance (hybride RDB+AOF recommandé)
• ✅ Mot de passe activé
• ✅ Volume monté sur l’hôte
• ✅ Config personnalisée (pas les défauts)
• ✅ Journaux consultables
• ✅ Healthcheck configuré
• ✅ Mémoire max limitée
• ✅ Commandes dangereuses désactivées/renommées
• ✅ Stratégie de sauvegarde
• ✅ Pas d’exposition publique (ou VPN/SSH)

Surveiller les performances

docker exec -it redis-prod redis-cli -a your_password
info memory
info persistence
info clients

Si vous êtes arrivé jusqu’ici, vous avez en principe un Redis conteneurisé de niveau production : données persistées, mot de passe, config structurée.

Conclusion

Vendredi soir, Redis déployé ; lundi matin, tout perdu. Vous savez maintenant : pas de persistance, données dans le conteneur, redémarrage = vide.

Ce guide couvre :

• RDB : instantanés, reprise rapide, adapté aux sauvegardes
• AOF : journal des écritures, sécurité élevée, perte typique ≤ 1 s
• Hybride (recommandé) : rapidité RDB + sécurité AOF
• Mot de passe : trois méthodes, obligatoire en production
• Fichier de config : déploiement normé, maintenance et équipe
• Docker Compose : démarrage unique, config as code

Si vous utilisez déjà Redis sous Docker, vérifiez tout de suite :

1. Volume monté ? (-v ~/redis-data:/data)
2. Persistance activée ? (RDB, AOF ou hybride)
3. Mot de passe ? (requirepass)
4. Config personnalisée ? (pas les défauts)

En production, ces quatre points sont le minimum.

Gardez cet article pour le prochain déploiement Redis ; partagez-le en équipe pour harmoniser les pratiques.

Les réglages ici visent Redis 7.x. Autre version : consultez la documentation officielle Redis pour d’éventuels changements de paramètres.