Deep Dive : Redis – cache d’objets, verrouillage de fichiers, et pourquoi un mot de passe derrière le pare-feu

🌐 Aussi en: English · Deutsch · Español

Deep Dive de la série autour de l’Ansible Tour. Niveau : administration Linux avancée. Le tour explique les rôles ; les deep dives expliquent la technique en dessous – comment elle fonctionne, pourquoi elle est là, ce que cette installation en fait exactement, comment l’exploiter au quotidien et ce qui aurait existé d’autre.

Redis est le plus petit service de cette installation – quelques mégaoctets de mémoire, une fraction de cœur CPU – et les deux applications en dépendent. Le blog l’utilise comme cache d’objets (partie 3), Nextcloud pour le verrouillage de fichiers et comme cache partagé entre processus (partie 4). Cet article explique ce que Redis y fait, pourquoi les deux instances sont sécurisées différemment, ce que disent les chiffres et ce qu’une revue pour cet article a mis au jour.

🧭 Comment fonctionne Redis

Un thread, tout en mémoire

Redis garde toutes les données en RAM et exécute les commandes l’une après l’autre dans une seule boucle d’événements. Cela ressemble à un goulet d’étranglement et c’est l’inverse : pas de verrous entre threads, chaque commande est atomique, et une simple lecture prend des microsecondes. Le réseau et les appels système coûtent plus que la commande elle-même.

Clés, types, expiration

Chaque entrée est une clé avec une valeur – une chaîne, un hash, une liste, un ensemble. Chaque clé peut avoir une durée de vie ; Redis la supprime à son expiration. Les deux applications mettent une durée de vie sur presque chaque clé, le jeu de données se nettoie donc tout seul.

Quand la mémoire manque

maxmemory fixe une limite ; maxmemory-policy décide de ce qui se passe à la limite. allkeys-lru évince la clé la moins récemment utilisée – juste pour un cache pur, où chaque entrée peut être reconstruite. noeviction refuse plutôt les nouvelles écritures – juste pour des données qui ne doivent pas disparaître en silence, comme un verrou.

Persistance – ou aucune

Redis peut écrire des instantanés (RDB, contrôlés par save) et un journal de toutes les écritures (AOF). Les deux servent aux données qui doivent survivre à un redémarrage. Un cache et des verrous de courte durée n’ont besoin ni de l’un ni de l’autre : après un redémarrage le cache se remplit à nouveau et les applications prennent de nouveaux verrous.

Authentification et protected mode

requirepass (ou, depuis Redis 6, des utilisateurs ACL) oblige chaque client à s’authentifier d’abord. Le protected mode ne refuse les connexions extérieures que si Redis écoute sur toutes les interfaces sans mot de passe – dès qu’une adresse de liaison est configurée sans mot de passe, il n’aide plus.

🛡️ Pourquoi il est là

• Cache d’objets WordPress. WordPress demande à la base les mêmes options, menus et métadonnées d’articles à chaque requête. Avec l’extension Redis Object Cache, les réponses viennent de Redis.
• Verrouillage de fichiers Nextcloud. Quand deux clients écrivent le même fichier en même temps, Nextcloud a besoin d’un verrou que chaque processus PHP, dans chaque pod, voit immédiatement. Sans lui, les clients de synchronisation s’écrasent mutuellement. Nextcloud recommande explicitement Redis pour cela.
• Cache distribué Nextcloud. Les données partagées entre processus – configuration des apps, état proche des sessions – y sont aussi ; le cache par processus est APCu.

🔧 Ce que fait ce dépôt

Le blog : un cache jetable dans un pod verrouillé

command: ["redis-server", "--save", "", "--appendonly", "no",
          "--maxmemory", "80mb", "--maxmemory-policy", "allkeys-lru"]
securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  capabilities: { drop: [ALL] }

Tout ce qui est dans ce Redis peut être jeté, et il est configuré ainsi : aucune écriture disque, un plafond mémoire avec éviction LRU, un système de fichiers racine en lecture seule, aucune capability. Il n’a pas de mot de passe parce que rien en dehors du réseau des pods ne peut l’atteindre et qu’à l’intérieur seuls les pods WordPress y ont droit – une NetworkPolicy refuse tout autre pod, y compris la base et l’ingress controller.

Nextcloud : pourquoi le mot de passe

Sur les serveurs Nextcloud, Redis tourne sur l’hôte, et les pods l’atteignent via un Service Kubernetes qui pointe vers l’IP du nœud. Redis écoute donc sur l’adresse publique du serveur. Entre Internet et Redis, il y avait au départ exactement une règle nftables. Le rôle next_redis ajoute requirepass comme seconde couche, car une règle qui échoue en silence n’a rien d’hypothétique ici : fail2ban est resté mort deux jours sur le blog sans que personne ne s’en aperçoive. Le mot de passe parvient à Nextcloud via un Secret Kubernetes monté comme redis.config.php – pas via la ConfigMap qui contient le reste de la configuration, car les ConfigMaps ne sont pas faites pour les secrets.

- name: Redis | Ensure Redis requires authentication
  ansible.builtin.lineinfile:
    path: /etc/redis/redis.conf
    regexp: '^requirepass\s+'
    line: 'requirepass {{ nextcloud_redis_pass }}'
  no_log: true                 # the line contains the password
  notify: Restart Redis

- ansible.builtin.meta: flush_handlers   # restart NOW, the next role needs it

Le flush_handlers n’est pas décoratif : les rôles suivants lancent des commandes occ dans le pod, qui se connectent à Redis via l’IP du nœud. Sans le redémarrage immédiat, Redis n’écouterait encore que sur 127.0.0.1 à ce moment-là.

noeviction exprès

Le Redis de l’hôte n’a pas de limite mémoire et garde la politique par défaut noeviction. Pour des verrous, c’est juste : un verrou évincé serait un verrou qui a cessé en silence de protéger un fichier. Le jeu de données est minuscule de toute façon (voir plus bas), et le serveur a beaucoup de mémoire.

📊 Mesuré

Les deux charges ne se ressemblent pas du tout. Le cache du blog contient des dizaines de milliers de petits objets ; Nextcloud quelques dizaines de verrous et d’entrées de cache qui naissent et expirent sans cesse – plus de 11 000 clés ont expiré en une journée sur le plus grand serveur. Le taux de succès plus bas sur le petit serveur Nextcloud tient à la nature du verrouillage, ce n’est pas un problème : « ce fichier est-il verrouillé ? » est un échec chaque fois que la réponse est « non ». Le ratio de fragmentation que Redis indique pour les instances de l’hôte (7 à 9) paraît alarmant et ne signifie rien à cette taille – quelques mégaoctets de surcoût du processus divisés par un ou deux mégaoctets de données.

Le blog utilise Predis, un client écrit en PHP, parce que l’image officielle de WordPress ne contient pas l’extension phpredis. L’extension en C serait plus rapide ; avec 88 % de taux de succès et un cache de pages devant, la différence ne se voit pas dans les temps de réponse.

🔍 Ce que la revue pour cet article a trouvé

En rassemblant les faits pour cet article, quatre choses que l’installation n’avait pas faites sont apparues – aucune dangereuse, toutes bonnes à savoir. Les quatre sont corrigées depuis le 20 octobre 2026.

• Pas de bac à sable systemd pour le Redis de l’hôte. MariaDB sur les mêmes serveurs a reçu un drop-in de durcissement (aucune capability, système de fichiers en lecture seule, filtre d’appels système) ; Redis tourne seulement avec l’unité du paquet. SELinux le confine tout de même dans redis_t, il n’est donc pas sans protection – mais la seconde couche dont dispose MariaDB manque. Le plan de cet article même affirmait qu’elle existait. Corrigé : le même genre de drop-in que pour MariaDB – avec un piège en route : les options de bac à sable impliquent NoNewPrivileges, et sous ce régime SELinux a refusé le passage dans redis_t ; Redis n’a pas démarré pendant deux minutes. Un petit module local (init_nnp_daemon_domain(redis_t)) autorise exactement cette transition.
• Des instantanés dont personne n’a besoin. Le Redis de l’hôte garde le défaut du paquet save 3600 1 300 100 60 10000 et écrit régulièrement dump.rdb – pour des verrous à durée de vie et un cache qui se reconstruit tout seul. Restaurés après un redémarrage, des verrous périmés devraient même d’abord expirer. Corrigé : save "", comme sur le blog, et l’ancien dump.rdb supprimé.
• Un mot de passe changé ne serait pas arrivé jusqu’à Nextcloud. Les paramètres de connexion viennent d’un Secret monté avec subPath – et un montage subPath ne se met jamais à jour dans un pod en cours d’exécution. Le pod est redéployé quand sa configuration change, via une annotation de somme de contrôle, mais le Secret ne faisait pas partie de cette somme. Changer le mot de passe aurait redémarré Redis avec le nouveau alors que Nextcloud gardait l’ancien jusqu’à son prochain redémarrage fortuit : plus de verrous, des pages d’erreur. Corrigé : le Secret fait désormais partie de la somme de contrôle. La dernière partie manuelle est automatisée elle aussi – le démon de push notify_push lit le mot de passe dans config.php, où l’installateur l’a écrit une fois : le playbook l’y recopie depuis le Secret dès que les deux diffèrent.
• Monit ne le surveille pas. Monit redémarre et signale K3s, sshd et les services de supervision, mais pas le Redis ni le MariaDB de l’hôte sur les serveurs Nextcloud. Si Redis s’arrêtait, Nextcloud le remarquerait en premier et Grafana en second. Corrigé : les deux figurent désormais dans la liste de Monit.

🧰 Exploitation au quotidien

# host (Nextcloud): password from the config, never on the command line
export REDISCLI_AUTH="$(awk '/^requirepass/{print $2}' /etc/redis/redis.conf)"
redis-cli INFO stats | grep -E 'keyspace_(hits|misses)|evicted'
redis-cli INFO memory | grep used_memory_human
redis-cli SLOWLOG GET 5
redis-cli --latency            # Ctrl-C to stop

# blog pod
k3s kubectl -n wordpress exec deploy/redis -- redis-cli INFO keyspace
wp redis status                # inside the WordPress container, as www-data

• MONITOR affiche chaque commande en direct – utile quelques secondes, coûteux et plein de données sur une instance chargée.
• Vider. Sur le blog, wp cache flush vide le cache d’objets sans risque. Sur Nextcloud, un FLUSHALL supprime aussi tous les verrous ; uniquement en mode maintenance.
• Changer le mot de passe. Le modifier dans le vault, lancer le playbook : next_redis l’écrit dans redis.conf et redémarre Redis, next_k3s_deploy met à jour le Secret et – depuis la correction ci-dessus – redéploie le pod Nextcloud dans le même passage. notify_push le reçoit dans le même passage.
• Mises à jour. Le paquet de l’hôte reçoit les correctifs de sécurité via dnf-automatic, qui redémarre ensuite Redis ; l’image du blog suit l’épinglage dans versions.yml.

🆘 Antisèche : symptôme → commande

La version courte de cet article, pour le moment où quelque chose ne va pas. À lancer sur l’hôte en root ; <…> sont des espaces réservés. occ et wp sont les fonctions shell des deep dives Nextcloud et WordPress.

🔭 La suite

• Valkey. Après le changement de licence de Redis en 2024, le fork Valkey de la Linux Foundation est devenu le choix par défaut de plusieurs distributions. C’est un remplacement direct ; changer serait une modification de paquet ou d’image.
• Métriques. Un redis_exporter mettrait le taux de succès et la mémoire dans Grafana au lieu d’un INFO manuel.

⚖️ Alternatives – et pourquoi Redis

Redis est le genre de composant qu’on oublie facilement, parce qu’il ne se plaint jamais. La revue pour cet article a rappelé que « ça marche » et « c’est configuré comme le reste » sont deux affirmations différentes – et que la seconde vaut aussi d’être vérifiée pour les petits services.