Automatisation CI/CD Redis avec exemples pratiques : guide d'implémentation

Redis se trouve souvent sur le chemin critique pour la latence et la disponibilité. Automatiser les workflows Redis avec CI/CD (Continuous Integration / Continuous Deployment : intégration continue / déploiement continu) réduit les erreurs manuelles, raccourcit les cycles de rétroaction et rend les opérations risquées répétables. Dans ce guide, vous allez :

• Inventorier les versions, la topologie et les environnements Redis pour que chaque changement soit ciblé et testable.
• Construire un pilote étroit et inspectable qui valide la configuration, exécute des tests de fumée et prouve un déploiement et un rollback sûrs.
• Ajouter vérification et diagnostics pour que chaque changement soit observable et réversible.
• Apprendre les modes de défaillance courants et les étapes de récupération concrètes.

L'objectif n'est pas d'automatiser tout d'un coup. Commencez par une petite tranche que vous pouvez inspecter localement et en préproduction, puis étendez une fois que vous faites confiance au chemin.

Inventaire des versions et environnements

Avant d'écrire le moindre code de pipeline, capturez ce qui tourne et où. Cet inventaire pilote les vérifications de compatibilité et la forme de votre déploiement.

• Version Redis : 6.x, 7.x ou variante de service géré.
• Topologie : instance unique, HA géré par Sentinel ou Cluster.
• Persistance : snapshots RDB (Redis Database : fichier de snapshot binaire Redis), AOF (Append Only File : journal d'ajout uniquement), ou les deux.
• Authentification : utilisateurs/mots de passe ACL (Access Control List : liste de contrôle d'accès), TLS, politiques réseau.
• Points de terminaison : noms d'hôte/ports par environnement.
• Bibliothèques clientes et versions : Node.js, Java, Go, etc.
• Risques de données : espaces de clés à forte écriture, politiques d'éviction, maxmemory.

Gardez cet inventaire sous contrôle de version près de votre infrastructure-as-code ou documentation d'opérations. Un tableau minimal et pratique à adapter :

Chemin de configuration sûr

L'automatisation réussit quand le périmètre est petit, mesurable et facile à observer.

Chemin recommandé :

1. Commencez avec une instance dev à nœud unique pour une itération rapide.

• Utilisez un Redis jetable pour la validation de config et les tests de fumée.
• Gardez la persistance désactivée en dev pour la vitesse : --save "" --appendonly no.

1. La préproduction reflète l'authentification et la persistance de production.

• Utilisez les mêmes ACL et mode de persistance que prévu pour la prod.
• Exécutez des tests de fumée réalistes et un benchmark léger pour assurer la marge.

1. Les changements en production utilisent un basculement sur replica (replica cutover : promotion contrôlée d'un replica en primaire).

• Ajoutez un replica du primaire actuel.
• Validez la santé de la réplication et promouvez seulement quand le replica est en synchronisation.
• Basculez les connexions applicatives via un enregistrement DNS (Domain Name System : système de noms de domaine) ou un drapeau de configuration.

1. Gardez la surface de changement étroite.

• Une variable par déploiement : ajustement de config, version Redis ou mise à jour bibliothèque cliente, mais pas tout à la fois.
• Portes de vérification explicites entre les étapes.

Une vue minimale étapes/portes :

Exemples pratiques CI/CD

Voici des exemples que vous pouvez copier et adapter. Ils évitent les conteneurs par défaut et s'appuient sur redis-server et redis-cli disponibles sur le runner ou l'hôte.

Prérequis

• Installez les outils Redis sur le runner ou l'agent.
• Debian/Ubuntu : sudo apt-get update && sudo apt-get install -y redis-tools redis-server
• macOS : brew install redis
• Stockez les secrets (mots de passe) dans le magasin de secrets de votre système CI.
• Fournissez des variables d'environnement pour les points de terminaison et identifiants : REDIS_HOST, REDIS_PORT, REDIS_PASS

Exemple 1 : Analyse de config locale et test de fumée

Ce script démarre un Redis éphémère, valide les commandes de base, puis nettoie.

#!/usr/bin/env bash
set -euo pipefail

PORT="6380"
TMP_DIR="$(mktemp -d)"CONF="$TMP_DIR/redis.conf"

cat > "$CONF" <<'EOF'
port 6380
save ""
appendonly no
protected-mode no
EOF

# Démarre Redis au premier plan pour un échec rapide, puis en arrière-plan.
redis-server "$CONF" --daemonize yes

# Attend l'ouverture du port
for i in {1..20}; do
  if redis-cli -p "$PORT" PING >/dev/null 2>&1; then break; fi
  sleep 0.2
done

# Test de fumée fonctionnel
redis-cli -p "$PORT" SET ci:hello world >/dev/null
VAL=$(redis-cli -p "$PORT" GET ci:hello)
if [[ "$VAL" != "world" ]]; then
  echo "Valeur inattendue : $VAL" >&2
  exit 1
fi

# Vérification latence
redis-cli -p "$PORT" --latency-history -i 0.1 -n 1 -c 5 >/dev/null || true

# Nettoyage
redis-cli -p "$PORT" SHUTDOWN NOSAVE || true
rm -rf "$TMP_DIR"
echo "OK : analyse de config locale et test de fumée réussis"

Résultat attendu

• Le script sort avec le code 0 et affiche OK.
• Aucun processus Redis résiduel.

Exemple 2 : Test de fumée applicatif avec Node.js

Utilisez votre bibliothèque cliente applicative pour exercer l'authentification et quelques commandes. Cela détecte les décalages ACL et protocole plus tôt que les tests d'intégration complets.

// fichier : smoke-redis.js
const { createClient } = require('redis');

(async () => {
  const client = createClient({
    socket: { host: process.env.REDIS_HOST, port: Number(process.env.REDIS_PORT || 6379) },
    password: process.env.REDIS_PASS
  });
  client.on('error', (err) => {
    console.error('Erreur client', err);
    process.exit(2);
  });
  await client.connect();
  const who = await client.sendCommand(['ACL', 'WHOAMI']);
  if (!who) throw new Error('ACL WHOAMI vide');
  await client.set('ci:app:probe', '42', { EX: 30 });
  const v = await client.get('ci:app:probe');
  if (v !== '42') throw new Error('Valeur inattendue : ' + v);
  await client.quit();
  console.log('OK test fumée app');
})().catch((e) => {
  console.error(e);
  process.exit(1);
});

Exécution :

export REDIS_HOST=redis-stage.example
export REDIS_PORT=6379
export REDIS_PASS='******'
node smoke-redis.js

Résultat attendu

• Affiche : OK test fumée app
• Code de sortie 0.

Exemple 3 : YAML CI minimal avec portes (GitHub Actions)

Ce pipeline valide la config locale, puis lance un test de fumée applicatif contre la préproduction, et enfin effectue une vérification de replica de production gardée avant tout basculement manuel.

name: redis-ci
on:
  push:
    branches: [ main ]
  workflow_dispatch:

jobs:
  config-parse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Installer Redis
        run: sudo apt-get update && sudo apt-get install -y redis-tools redis-server
      - name: Analyse de config locale et test de fumée
        run: |
          bash ./scripts/redis-local-smoke.sh

  stage-smoke:
    needs: config-parse
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Installer Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Installer Redis CLI
        run: sudo apt-get update && sudo apt-get install -y redis-tools
      - name: Installer dépendances
        run: npm ci
      - name: Test de fumée stage
        env:
          REDIS_HOST: ${{ secrets.STAGE_REDIS_HOST }}
          REDIS_PORT: ${{ secrets.STAGE_REDIS_PORT }}
          REDIS_PASS: ${{ secrets.STAGE_REDIS_PASS }}
        run: node smoke-redis.js

  prod-replica-verify:
    needs: stage-smoke
    runs-on: ubuntu-latest
    steps:
      - name: Installer Redis CLI
        run: sudo apt-get update && sudo apt-get install -y redis-tools
      - name: Vérifier santé réplication
        env:
          REDIS_HOST: ${{ secrets.PROD_REPLICA_HOST }}
          REDIS_PORT: ${{ secrets.PROD_REPLICA_PORT }}
          REDIS_PASS: ${{ secrets.PROD_REDIS_PASS }}
        run: |
          role=$(redis-cli -h "$REDIS_HOST" -p "$REDIS_PORT" -a "$REDIS_PASS" INFO replication | awk -F: '/role:/{print $2}')
          echo "role=$role"
          [[ "$role" == "slave" || "$role" == "replica" || "$role" == "replica\r" ]] || { echo "Pas un replica\); exit 1; }
          lag=$(redis-cli -h "$REDIS_HOST" -p "$REDIS_PORT" -a "$REDIS_PASS" INFO replication | awk -F: '/master_link_status:/{print $2}')
          echo "master_link_status=$lag"
          [[ "$lag" =~ up ]] || { echo "Lien de réplication down\); exit 1; }

Résultat attendu

• Le job échoue si le replica n'est pas sain, empêchant toute action de déploiement ultérieure.
• Vous effectuez le basculement final séparément avec un changement contrôlé (décrit ci-dessous).

Exemple 4 : Basculement de production sûr avec un replica

Prérequis

• Vous avez un primaire actuel P et un replica synchronisé R.
• Les applications se connectent via un enregistrement DNS (par exemple, redis-prod.example) ou un drapeau de configuration central que vous pouvez mettre à jour atomiquement.

Étapes

1. Geler brièvement les opérations à forte écriture (optionnel, selon la tolérance au risque).
2. Valider que le replica est en synchronisation :

   redis-cli -h R -a "$REDIS_PASS" INFO replication | egrep 'role|master_sync_in_progress|master_link_status|slave|replica'

Attendu : role: slave ou role: replica, master_link_status: up, master_sync_in_progress:0.

1. Promouvoir le replica.

• Pour les services gérés, utilisez la commande du fournisseur pour promouvoir.
• Pour du self-managed avec Sentinel, déclenchez un failover via Sentinel.
• Pour une promotion manuelle sur primaire/replica unique sans Sentinel, arrêtez les écritures sur P, puis :

     # Sur le replica R
     redis-cli -h R -a "$REDIS_PASS" REPLICAOF NO ONE

1. Basculer le trafic applicatif vers R.

• Mettez à jour le DNS ou votre configuration pour pointer vers R.
• Videz les pools de connexions clients pour qu'ils se reconnectent.

1. Gardez P comme replica du nouveau primaire pour un rollback rapide.

   redis-cli -h P -a "$REDIS_PASS" REPLICAOF R <port>

1. Observez erreurs, latence et réplication pendant au moins un cycle métier clé.

Rollback

• Si des problèmes apparaissent, inversez le changement DNS/config pour pointer à nouveau vers P.
• Remettez les rôles en place après investigation.

Vérification et diagnostics

Avant et après chaque changement, vérifiez la santé avec des contrôles rapides et ciblés.

Connectivité et identité

redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS PING
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS ACL WHOAMI

Attendu : PONG et le nom d'utilisateur ACL attendu.

Lecture/écriture fonctionnelle

redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS SET ci:probe 1 EX 60
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS GET ci:probe

Attendu : 1

État de réplication

redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS INFO replication | egrep 'role|slave|replica|master_link_status|master_sync_in_progress|slave_repl_offset|master_repl_offset'

Attendu : role: master sur primaire, role: replica sur replica, lien up, in_progress:0, et offsets proches.

Latence et opérations lentes

# Sonde latence rapide
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS --latency -i 0.1 -n 1 -c 5

# Instantané slowlog
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS SLOWLOG LEN
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS SLOWLOG GET 10

Posture mémoire et éviction

redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS INFO memory | egrep 'used_memory_human|maxmemory_human|maxmemory_policy'

Vérification persistance (si activée)

# Vérif AOF : forcer réécriture et s'assurer que le fichier n'est pas vide
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS BGREWRITEAOF
sleep 2
ls -lh $(redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS CONFIG GET appendfilename | tail -n1) || true

Vérification au niveau applicatif

• Exercez un chemin de requête représentatif qui implique le cache.
• Vérifiez le taux de hit du cache dans les logs ou métriques applicatives si disponible.

Modes de défaillance et récupération

Concevez votre pipeline pour s'arrêter quand ces situations surviennent et fournir un rollback déterministe.

Playbooks de rollback et récupération

Changement déployé mais signaux mauvais ? Faites le rollback d'abord, puis investiguez hors ligne. Gardez ces playbooks comme scripts dans votre repo.

Rollback 1 : Changement de connexion

• Si vous venez de changer le DNS ou un drapeau de config vers un nouveau primaire et voyez des erreurs :

# Réverter DNS ou config vers l'endpoint précédent
# Vider connexions app pour que les pools se reconnectent

Rollback 2 : Inversion de rôle après promotion échouée

# Remettre l'ancien primaire P en primaire si vous avez promu R
redis-cli -h P -a "$REDIS_PASS" REPLICAOF NO ONE
# Pointer les apps vers P
# Remettre R en replica de P
redis-cli -h R -a "$REDIS_PASS" REPLICAOF P <port>

Rollback 3 : Mauvaise config poussée en prod

# Remplacer fichier config par dernière version connue bonne
# Tenter redémarrage en fenêtre sûre
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS CONFIG REWRITE || true
# Si redémarrage requis, coordonner une fenêtre de failover ou maintenance brève

Validation du rollback

• Après tout rollback, relancez les vérifications de la section Vérification et diagnostics.
• Confirmez que taux d'erreur et latence app reviennent à la ligne de base.

Renforcer la confiance : étendre le pilote

Une fois le pilote vert sur plusieurs versions, étendez la couverture par petits pas :

• Ajoutez des tests de fumée par motif d'espaces de clés pour les préfixes critiques.
• Validez la restauration de sauvegarde en restaurant un petit dump dans une instance jetable et en lançant des vérifications en lecture seule.
• Placez les directives de config risquées derrière des preuves en staging (par exemple, changements de politique d'éviction, client-output-buffer-limits).
• Intégrez une porte de performance légère avec redis-benchmark en stage avec de faibles comptages pour protéger contre les régressions :

redis-benchmark -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS -n 5000 -t get,set -q

• Ajoutez des alertes qui reflètent vos vérifications pour que les trouvailles CI correspondent au monitoring runtime.

Check-list opérationnelle

Utilisez ceci comme runbook répétable pour chaque changement Redis.

Planification

• Identifiez la variable de changement unique (config, version ou bibliothèque cliente).
• Mettez à jour le tableau d'inventaire si quelque chose d'environnement-specific change.
• Écrivez ou mettez à jour les tests de fumée pour couvrir le changement.

Portes pré-déploiement

• Analyse de config locale : Redis jetable démarre et répond au PING.
• Test de fumée stage : auth, SET/GET et toute sonde applicative passent.
• Persistance : le réglage AOF/RDB se comporte comme attendu en stage.
• Santé replica : le replica de production montre lien up et lag proche de zéro.

Basculement (si applicable)

• Geler les écritures à haut risque si nécessaire.
• Promouvoir replica via commande gérée ou REPLICAOF NO ONE.
• Basculer DNS ou config vers nouveau primaire.

Vérification post-déploiement

• Connectivité : PONG et ACL WHOAMI corrects.
• Fonctionnel : clés de sonde définies et récupérées.
• Réplication : replicas restants sains et en synchronisation.
• Latence et taux d'erreur à ou mieux que la ligne de base pendant au moins un cycle clé.

Préparation au rollback

• L'ancien primaire est encore disponible et peut accepter le trafic.
• Le changement DNS/config est réversible en minutes.
• Scripts pour changement de rôle et vérification sont présents et testés.

Revue

• Documentez ce qui a changé et les signaux observés.
• Mettez en file la prochaine petite amélioration d'automatisation.

Conclusion

Automatiser Redis avec CI/CD porte ses fruits quand vous gardez le périmètre étroit, imposez des portes claires et rendez chaque étape observable et réversible. Commencez par un pilote que n'importe qui dans l'équipe peut lancer localement et en staging. Validez la configuration en démarrant réellement Redis, exercez les commandes critiques avec redis-cli et votre client applicatif, et déployez en production via un basculement replica sûr avec un chemin de rollback rapide. Avec le temps, faites grandir l'automatisation en ajoutant des vérifications ciblées et des garde-fous de performance, en gardant toujours un petit changement vérifiable par déploiement. Cette approche vous donne des changements Redis prévisibles sans ralentir la livraison.