Redis jetable et volume nommé

1. Redis : volume ou sans

Jusqu'à présent, nous avons déjà un câblage de base : l'application voit Redis, le profil cache s'active, et les conteneurs se montent de manière prévisible. La question du volume n'est pas nécessaire pour un premier lancement. Mais dans la vie locale, elle se pose très rapidement : Redis doit-il survivre à la recréation du conteneur, ou est-il plus avantageux de le garder jetable ?

Lorsque vous ajoutez Redis à une pile Compose pour la première fois, la main est vraiment tentée de faire « comme avec PostgreSQL » : si c'est un service, il lui faut un volume pour « ne rien perdre ». Le réflexe est compréhensible, mais pour Redis en tant que cache, il embrouille facilement le tableau. Nous commençons à traiter l’accélérateur de lectures comme une base de données et à trimballer dans l’environnement local un état superflu là où il n’est pas nécessaire.

L’environnement local a deux désirs opposés. D’un côté, on veut qu’après un redémarrage tout soit « comme hier » : rapide, chaud, pratique. De l’autre, on veut une réinitialisation facile : monter l’environnement, travailler, le démonter, le remonter et obtenir un état propre et prévisible sans les restes de la veille. Redis en tant que cache favorise plutôt le second scénario.

C’est pourquoi le chemin par défaut est simple : on considère d’abord Redis comme jetable. Cela n’empêche pas d’obtenir un premier cache-path fonctionnel, et on envisage la variante persistée comme une politique locale consciente, si elle est réellement nécessaire.

2. Redis comme cache : la perte de données n'est pas grave

La raison est simple : dans le Container-Ready Catalog Service, Redis stocke des données dérivées, pas la source de vérité. La source de vérité reste dans PostgreSQL. Si Redis est vide, la requête suivante fait simplement un cache miss, lit les données depuis la base et replace le résultat dans le cache. Désagréable ? Parfois oui. Mais c’est une perte d’accélérateur, pas une perte de données métier.

C’est pourquoi la question « volume ou pas » ne commence pas par « comment ne rien perdre » mais par « avons-nous besoin de conserver cet état entre les recréations du conteneur » .

/data et persistance dans le conteneur

Quand on dit « Redis stocke des données », le débutant imagine souvent un « fichier de base de données ». En réalité, Redis maintient d’abord les données dans la mémoire du processus. C’est-à-dire que tant que le conteneur vit et que le processus Redis tourne, les données sont présentes. Dès que le processus redémarre, la mémoire est vidée. Mais Redis dispose de mécanismes de persistance qui peuvent sauvegarder l’état sur disque pour le recharger au démarrage. Et c’est là qu’apparaît le dossier /data.

Dans l’image Docker officielle de Redis, le répertoire /data est utilisé comme emplacement où Redis peut écrire ses fichiers de persistance (par exemple, un snapshot RDB ou AOF, selon la configuration). Et ensuite commence le plus important pour Docker : si /data reste à l’intérieur du conteneur, ce n’est qu’une couche inscriptible du conteneur spécifique. Dès que le conteneur est supprimé et recréé, cet état disparaît.

Avec un volume nommé, l’idée est différente. Nous donnons à Redis un emplacement séparé pour stocker les données, qui vit indépendamment du conteneur. Le conteneur peut être recréé autant de fois que nécessaire, tandis que le volume reste. Si Redis est configuré pour écrire effectivement des fichiers de persistance dans /data, alors au prochain démarrage, il pourra les lire et restaurer l’état.

Il est utile de garder en tête un schéma simple :

flowchart TD
    %% Idée : les données vivent en mémoire dans Redis, et /data est juste un emplacement pour (éventuellement) écrire des fichiers de persistance
    A["Processus Redis (en mémoire)"] -->|écritures de persistance optionnelles| B["/data à l'intérieur du conteneur"]
    B -->|si pas de volume| C["couche inscriptible du conteneur"]
    B -->|si volume nommé| D["volume nommé (vit séparément)"]

Ici, « écritures de persistance optionnelles » est intentionnel, car la persistance de Redis est un univers de réglages à part entière. Nous n’avons pas besoin d’aller en profondeur, mais il est important de comprendre : le simple fait d’avoir un volume ne rend pas Redis « éternel » ; il fournit seulement un emplacement où Redis peut sauvegarder les données, s’il le fait.

3. Variante A : Redis jetable sans volume

Si nous maintenons Redis dans son rôle de « cache pour les lectures répétées », l’option la plus honnête et la plus simple est Redis sans volume. Cela signifie que le cache vit exactement aussi longtemps que le conteneur spécifique, et lors de la recréation de l’environnement, vous obtenez un « cache vierge ». En développement local, c’est même agréable : vous voulez souvent voir le comportement d’un cache miss après le démarrage pour comprendre que le cache fonctionne, et pas simplement « il reste quelque chose d’hier par hasard et maintenant ça semble rapide ».

Dans compose.yaml, cette variante est minimale. Habituellement, vous avez déjà ajouté le healthcheck de la leçon précédente, donc je montre le fragment dans cette forme « adulte » :

services:
  redis:
    image: redis:8.6.0

    # Dans cette variante, nous NE montons PAS /data : on recrée le conteneur — le cache est « vierge »
    # volumes: délibérément absents

    healthcheck:
      # Vérifie que Redis répond vraiment, pas seulement « le conteneur tourne »
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 5

Notez qu’il n’y a pas de volumes. Ce n’est ni une erreur ni un « oubli ». C’est une décision consciente : Redis en tant que cache tolère une « perte d’état », car l’état est dérivé. Si vous faites docker compose down, le conteneur Redis disparaît. Quand vous faites docker compose up, Redis est recréé. Le cache sera vide, puis se remplira au fil des requêtes vers votre API.

Cette approche s’accorde bien avec la discipline de réinitialisation de l’environnement que nous avons mise en œuvre avec Flyway et PostgreSQL. La base de données peut vivre dans un volume, car elle est la source de vérité et il est souvent important de conserver les données entre les redémarrages. Redis, lui, peut être éliminé sans douleur, car ce n’est qu’un accélérateur qui « se réchauffera » naturellement.

Si vous avez besoin de vérifier rapidement que Redis est réellement vivant et pas simplement « ajouté dans le YAML et oublié », le moyen le plus simple est de le pinger via redis-cli directement à l’intérieur du conteneur :

# Exécutez la commande à l'intérieur du conteneur redis et attendez la réponse PONG
docker compose exec redis redis-cli ping
# PONG

Cela ne transforme pas le cours en « cours sur Redis CLI », mais vous donne un indicateur simple et clair de disponibilité : Redis a non seulement démarré, mais répond à une commande de base.

4. Variante B : Redis avec volume nommé

Parfois, vous voulez quand même que Redis survive à la recréation du conteneur. Par exemple, vous chauffez le cache longtemps ou vous souhaitez qu’après docker compose down et up, l’environnement local démarre déjà « chaud ». Dans ce cas, on peut attacher Redis à un volume nommé. C’est exactement le même mécanisme que celui utilisé pour PostgreSQL, mais la motivation est différente : pour Postgres, c’est presque une nécessité (sinon vous perdez constamment des données), pour Redis, c’est un choix délibéré.

Dans Compose, cela se présente ainsi : Redis écrit dans /data, nous y montons un volume nommé. Fragment :

services:
  redis:
    image: redis:8.6.0
    volumes:
      # Montons le volume nommé dans /data — Redis PEUT y écrire des fichiers de persistance (si activé)
      - redis-data:/data
    healthcheck:
      # Vérification minimale de la disponibilité de Redis
      test: ["CMD", "redis-cli", "ping"]

volumes:
  # Le volume nommé vit séparément des conteneurs et survit à docker compose down (sans -v)
  redis-data:

Le sens de redis-data est que Docker conserve ce volume séparément des conteneurs. Le conteneur Redis peut être supprimé, mais le volume reste. Ensuite, un nouveau conteneur Redis monte à nouveau ce volume dans /data.

Maintenant, la partie la plus pratique : comment cela se rapporte-t-il à down et down -v .

Lorsque vous faites docker compose down, Compose supprime les conteneurs (et le réseau), mais par défaut ne supprime pas les volumes nommés. Cela signifie que redis-data reste. Au prochain up, il sera à nouveau connecté.

Lorsque vous faites docker compose down -v, Compose supprime à la fois les conteneurs et les volumes nommés associés. Ainsi, redis-data disparaît. Au prochain up, le volume est recréé et Redis est vierge, comme si vous veniez de l’ajouter.

Il est utile de voir cela une fois sous forme de « tableau de comportement » pour ne pas tout garder en mémoire comme une magie YAML :

docker compose down

docker compose down -v

Et c’est là qu’il est important de ne pas tomber dans le piège des attentes. Si vous avez attaché un volume, cela ne garantit pas que vous « sauvegardez le cache ». Redis peut ne pas avoir le temps d’écrire le fichier de persistance avant l’arrêt, ou la persistance peut être configurée de manière à ne pas enregistrer ce que vous attendez. C’est pourquoi, dans le cadre du cours, il est préférable de considérer le volume comme un outil « donner à Redis un emplacement pour sauvegarder », mais pas comme une promesse « le cache survivra toujours aux redémarrages ». Ce qui importe, c’est la discipline d’ingénierie autour de l’environnement et un modèle de cycle de vie des données clair, plutôt qu’une garantie absolue que le cache sera chaud après le redémarrage.

Si vous voulez vérifier que le volume existe vraiment et vit sa vie séparée, vous pouvez simplement lister les volumes :

# Listons tous les volumes Docker : vous verrez ici si redis-data a survécu à la commande down
docker volume ls
# ... vous verrez quelque chose comme :
# local   docker-java-catalog-service_redis-data

Le nom aura le préfixe du projet Compose (généralement le nom du répertoire), et c’est normal : Docker essaie d’éviter les conflits entre projets.

5. Stratégie pour app + postgres + redis

Le choix « volume ou sans volume » n’est pas une question de goût, mais une conséquence du rôle architectural de Redis dans le projet. À ce jour, Redis est précisément un cache. Cela signifie que si vous hésitez, commencez par la variante jetable. Elle est plus simple, plus honnête et apprend mieux la bonne attitude envers le cache : le cache doit améliorer la vie, mais ne doit pas devenir une deuxième base de données que vous êtes obligé de sauvegarder et de backuper « parce que sinon tout va casser ».

Avec un Redis jetable, vous avez une belle séparation des responsabilités. PostgreSQL stocke l’état réel du catalogue et des jobs d’export, et c’est pourquoi PostgreSQL a un volume nommé. Redis ne stocke que des accélérateurs de lectures, donc on peut recréer Redis sans douleur, surtout dans un environnement local où la réinitialisation de l’environnement est une opération quotidienne normale. Vous trouvez plus rapidement les erreurs de configuration, car vous n’êtes pas induit en erreur par les « restes du cache d’hier » qui masquent aujourd’hui un problème.

Le volume pour Redis devient justifié lorsque vous avez une raison spécifique. Par exemple, vous voulez comparer le comportement après la recréation de l’environnement avec un « cache chaud », ou votre workflow local consiste à monter l’environnement une fois par jour et vous voulez qu’il soit rapide immédiatement. Mais même dans ce cas, il est bon de garder à l’esprit les limites : Redis n’est toujours pas la source de vérité, et vous ne devriez pas écrire le code comme si Redis devait se souvenir de tout « pour toujours ». Si la perte de Redis brise le sens du service, alors vous en avez fait en secret le stockage principal. Cela change alors non seulement la politique Compose, mais aussi tout le modèle de l’application.

Un autre point pratique est la documentation. Si vous incluez tout de même un volume pour Redis, cette décision doit être lisible dans compose.yaml. Il ne faut pas le cacher dans dix fichiers override ou dans des scripts « magiques ». Que l’étudiant (ou votre futur collègue) ouvre le YAML et comprenne immédiatement : Postgres stocke les données dans un volume, Redis aussi stocke quelque chose dans un volume, mais pour une autre raison. C’est là toute la valeur de la discipline d’infrastructure : elle fonctionne et elle est explicable.

6. Erreurs typiques lors du travail avec Redis

Erreur n°1 : faire automatiquement de Redis un « comme PostgreSQL » sans prendre conscience de la différence de rôles.
Souvent, l’étudiant se contente de copier le motif « service → volume », et après quelques jours commence à considérer Redis comme un endroit où « il y a quelque chose d’important ». Le problème n’est pas le volume en soi, mais le glissement de la pensée : si Redis devient soudainement critique, alors le cache a cessé d’être un cache. Dans notre projet, la source de vérité reste PostgreSQL, et Redis ne stocke qu’un résultat dérivé de la lecture.

Erreur n°2 : s’attendre à ce que l’ajout d’un volume garantisse « après le redémarrage, le cache est chaud ».
Redis est un stockage en mémoire, et le fait qu’un volume existe ne signifie pas que les données y sont constamment et immédiatement écrites. La persistance de Redis se configure séparément. Donc si après down/up vous voyez un cache vide, ce n’est pas nécessairement « Docker est cassé ». C’est souvent simplement que vous attendiez du cache un comportement de base de données, alors qu’il ne vous a rien promis de tel.

Erreur n°3 : confondre restart et « recréation » du conteneur, puis s’étonner que les données « tantôt sont là, tantôt non ».
Redémarrer le même conteneur et supprimer le conteneur pour en créer un nouveau sont des histoires différentes. Dans le premier cas, la couche inscriptible (et même certains fichiers) peut subsister ; dans le second, vous partez effectivement de zéro. Dans un environnement Docker, il est important d’être précis dans les termes : « arrêté/démarré » et « supprimé/recréé » sont des scénarios différents.

Erreur n°4 : supprimer accidentellement les volumes utiles avec la commande down -v, puis essayer de « restaurer » le cache comme si c’était une base de données.
down -v est une commande puissante, et elle existe précisément pour vous permettre de réinitialiser l’environnement local de manière garantie. Mais si vous avez activé un Redis persisté pour plus de confort, puis lancez automatiquement down -v « parce que c’est dans mes habitudes », vous effacez vous-même l’état. Il est important de choisir consciemment : faites-vous une réinitialisation des conteneurs ou une réinitialisation des données ?

Erreur n°5 : transporter par défaut un Redis persisté dans le projet, sans laisser de voie jetable simple.
Pour un projet d’apprentissage et pour un niveau junior, il est plus utile que le chemin de base soit simple : on peut recréer Redis et rien de grave ne se produit. Il est préférable de laisser la variante persistée comme une extension consciente, et non comme le seul mode. L’environnement reste ainsi léger et prévisible, et le cache est vraiment un cache, pas une deuxième base de données cachée.

1

Mission

Docker for Spring, niveau 19, leçon 3

Bloqué

Redis jetable sans volume

Redis jetable sans volume

Ouvrir

1

Mission

Docker for Spring, niveau 19, leçon 3

Bloqué

Named volume pour Redis et différence entre `down` et `down -v`

Named volume pour Redis et différence entre `down` et `down -v`

Ouvrir