Automatisation Ceph CI/CD avec des exemples pratiques

Intro

Cette version française explique Ceph CI/CD automation with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Ceph alimente le stockage critique de vos VMs, conteneurs et services (par exemple dans des environnements Linux ou Proxmox). Traiter chaque changement Ceph comme du code-conçu, revu et validé via un pipeline Ceph CI/CD-permet d'appliquer de petites modifications sûres et auditables. Le bénéfice est double: moins de régressions et une récupération plus rapide quand un incident survient, avec un historique clair de ce qui a changé et pourquoi. Ce guide propose une mise en place pratique de la Ceph automation au travers d'un pilote ciblé et vérifiable, avec canary, garde-fous, vérifications observables et Ceph rollback.

Objectifs concrets:

• Capturer un inventaire d'environnement fiable.
• Mettre en place des accès restreints pour l'automatisation.
• Définir un chemin de configuration sûr avec garde-fous explicites.
• Construire un pipeline minimal qui valide, canarise et applique.
• Vérifier les résultats avec des contrôles observables.
• Gérer les échecs fréquents avec des consignes de rollback.

Tous les exemples ci-dessous servent d'illustration. Adaptez-les à votre topologie, votre tolérance au risque et vos pratiques (clusters de stockage, RBD, etc.).

Inventaire des versions et de l'environnement

Avant d'automatiser quoi que ce soit, figez une vision cohérente du cluster. Cet inventaire devient votre artefact de référence et la première étape du pipeline.

Exécutez ces commandes depuis un hôte d'administration disposant du CLI ceph, puis stockez les sorties dans un répertoire horodaté (par exemple, inventory/2025-01-15/):

set -euo pipefail
TS="$(date +%F-%H%M%S)"
OUT="inventory/$TS"
mkdir -p "$OUT"

ceph -v | tee "$OUT/ceph-version.txt"
ceph versions | tee "$OUT/component-versions.json"
ceph status --format json-pretty | tee "$OUT/status.json"
ceph health detail | tee "$OUT/health.txt"
ceph osd tree | tee "$OUT/osd-tree.txt"
ceph osd df tree | tee "$OUT/osd-df-tree.txt"
ceph osd crush rule dump | tee "$OUT/crush-rules.json"
ceph osd getcrushmap -o "$OUT/crushmap.bin"
ceph df | tee "$OUT/df.txt"
ceph osd pool ls detail --format json-pretty | tee "$OUT/pools.json"
rados df --format json-pretty | tee "$OUT/rados-df.json"
ceph auth ls --format json-pretty | tee "$OUT/auth.json"

Conservez un court résumé lisible pour les revues rapides.

Stockez ces artefacts avec votre dépôt de configuration afin que chaque exécution du pipeline référence les mêmes faits. Différencier les inventaires entre exécutions met en évidence la dérive et les upgrades.

Prérequis et accès

Outils et identités doivent être fiables et strictement cadrés.

• Outils: CLIs ceph et rados installés sur vos runners.
• Synchronisation horaire: NTP/chrony opérationnel sur runner et nœuds du cluster.
• Réseau: le runner atteint les moniteurs (6789/3300) et les managers si nécessaire.
• Secrets: deux keyrings, l'un en lecture seule pour la validation, l'autre en écriture restreinte pour les changements contrôlés.

Créer une clé lecture seule pour la validation:

# À exécuter une fois avec des privilèges admin
ceph auth get-or-create client.cicd_ro mon 'allow r' osd 'allow r' mgr 'allow r' \
  | tee /etc/ceph/ceph.client.cicd_ro.keyring

Créer une clé de maintenance restreinte pour les écritures contrôlées. Limitez ses capacités exactement au périmètre que vous automatisez au début. Exemple: opérations limitées à un pool pilote et clés de config.

# Capacités d'exemple; resserrez selon votre politique
ceph auth get-or-create client.cicd_maint \
  mon 'allow rw' osd 'allow rw pool=<pilot_pool>' mgr 'allow rw' \
  | tee /etc/ceph/ceph.client.cicd_maint.keyring

Stockez ces keyrings en sécurité sur le runner. N'intégrez jamais les clés dans les scripts. Utilisez des permissions 0600 et un utilisateur système dédié.

Dans vos jobs, exportez l'environnement pour pointer vers la clé adaptée:

export CEPH_ARGS="--name client.cicd_ro --keyring /etc/ceph/ceph.client.cicd_ro.keyring"
# Pour les étapes d'application, basculez explicitement vers la clé maintenance

Chemin de configuration sûr

Commencez par des changements:

• À faible risque pour la disponibilité et la sécurité des données.
• Rapides à vérifier.
• Faciles à annuler.

Cibles à haut signal au départ:

• Garde-fous en lecture seule: santé OK (ou avertissements tolérés définis), moniteurs en quorum, absence d'états nearfull/full.
• Hygiène des métadonnées de pool: labels d'application présents; quotas vérifiés pour les nouveaux pools.
• Paramètres non disruptifs à effet borné, modifiés progressivement (ex.: un réglage de gestion sans impact sur le chemin IO).

À éviter dans le pilote initial:

• Éditions CRUSH massivement déplaçantes.
• Modifications size/min_size sur des pools de production.
• Upgrades OSD/Monitor.
• Flags comme noout, norecover, noscrub hors fenêtre de maintenance explicitement bornée.

Utilisez des points d'arrêt: un job qui émet un résumé et requiert une approbation humaine explicite avant toute application à l'échelle du cluster.

Exemple de pipeline pilote

Flux minimal en trois étapes:

1. validate: contrôles en lecture seule contre la production via client.cicd_ro. Échec rapide si conditions non sûres.
2. canary: création d'un pool canari éphémère, écriture/lecture/suppression d'un objet, puis suppression du pool. Cela exerce le chemin de contrôle avec client.cicd_maint sans toucher aux charges existantes.
3. apply_config: application optionnelle d'un petit changement de configuration, réversible, protégé par la santé et une approbation manuelle.

Arborescence (exemple):

repo/
  scripts/
    ceph-validate.sh
    ceph-canary.sh
    ceph-apply-config.sh
  plans/
    config-plan.yaml

scripts/ceph-validate.sh

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

# Clé lecture seule
export CEPH_ARGS="--name client.cicd_ro --keyring /etc/ceph/ceph.client.cicd_ro.keyring"

# 1) Garde-fous de santé
ceph status
HEALTH=$(ceph health -f plain)
if [[ "$HEALTH" != "HEALTH_OK" ]]; then
  echo "Refus d'avancer: $HEALTH"
  exit 1
fi

# 2) Quorum mon >= 3 (seuil d'exemple)
MONS=$(ceph quorum_status --format json | jq -r '.quorum | length')
if (( MONS < 3 )); then
  echo "Quorum $MONS sous le seuil"
  exit 1
fi

# 3) Pas de pools nearfull/full
if ceph df | grep -E 'NEARFULL|FULL' >/dev/null; then
  echo "Refus: condition nearfull/full présente"
  exit 1
fi

# 4) Pas de flags risqués
FLAGS=$(ceph osd dump | grep 'flags')
if echo "$FLAGS" | grep -E 'noout|norecover|nobackfill|norebalance|pause' >/dev/null; then
  echo "Flags risqués: $FLAGS"
  exit 1
fi

echo "Validation réussie."

scripts/ceph-canary.sh

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

# Clé de maintenance (portée restreinte)
export CEPH_ARGS="--name client.cicd_maint --keyring /etc/ceph/ceph.client.cicd_maint.keyring"

CANARY_POOL="ci_canary_$(date +%s)"

# Petit pool canari (paramètres d'exemple)
ceph osd pool create "$CANARY_POOL" 8 8 replicated
ceph osd pool application enable "$CANARY_POOL" rados --yes-i-really-mean-it

# Écrire, lire, supprimer un objet test
TMPDIR=$(mktemp -d)
echo "hello" > "$TMPDIR/obj"
rados -p "$CANARY_POOL" put canary_obj "$TMPDIR/obj"
rados -p "$CANARY_POOL" get canary_obj "$TMPDIR/obj.out"
diff "$TMPDIR/obj" "$TMPDIR/obj.out"
rados -p "$CANARY_POOL" rm canary_obj

# Nettoyage du pool
ceph osd pool delete "$CANARY_POOL" "$CANARY_POOL" --yes-i-really-really-mean-it
rm -rf "$TMPDIR"

echo "Canary OK."

scripts/ceph-apply-config.sh

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

# Clé maintenance, sauvegarde et point d'arrêt manuel
export CEPH_ARGS="--name client.cicd_maint --keyring /etc/ceph/ceph.client.cicd_maint.keyring"

# plans/config-plan.yaml (exemple):
# changes:
#   - scope: global
#     key: mgr_stats_period
#     value: "10"
#     previous: "20"

PLAN_FILE="plans/config-plan.yaml"
KEY=$(yq '.changes[0].key' -r "$PLAN_FILE")
SCOPE=$(yq '.changes[0].scope' -r "$PLAN_FILE")
VAL=$(yq '.changes[0].value' -r "$PLAN_FILE")
PREV=$(yq '.changes[0].previous' -r "$PLAN_FILE")

# Sauvegarde de la valeur existante
EXISTING=$(ceph config get "$SCOPE" "$KEY" || true)
echo "Valeur actuelle $KEY=$EXISTING"

# Point d'arrêt: exigence d'approbation explicite
: "${APPROVED:?Définir APPROVED=yes pour continuer}"

# Application du changement
ceph config set "$SCOPE" "$KEY" "$VAL"

# Porte rapide post-changement
sleep 5
if [[ "$(ceph health -f plain)" != "HEALTH_OK" ]]; then
  echo "Santé dégradée; revert en cours"
  if [[ -n "$EXISTING" ]]; then
    ceph config set "$SCOPE" "$KEY" "$EXISTING"
  else
    ceph config rm "$SCOPE" "$KEY"
  fi
  exit 1
fi

# Enregistrer la valeur précédente pour rollback
echo "$SCOPE $KEY $EXISTING" > ".rollback-$KEY.txt"

echo "Appliqué $KEY=$VAL"

Orchestrez ces scripts dans votre runner préféré en trois jobs séquentiels, avec une approbation avant ceph-apply-config.sh. Cela constitue un Ceph pipeline clair et auditable.

Vérifications et diagnostics

Après chaque étape, vérifiez les sorties attendues et l'absence de nouveaux avertissements.

• validate
• ceph status affiche HEALTH_OK.
• ceph quorum_status montre la longueur de quorum attendue.
• ceph df ne liste aucun pool nearfull/full.
• ceph osd dump ne montre pas de flags risqués (noout, norecover, nobackfill, norebalance, pause).

• canary
• rados put/get/diff réussit.
• ceph health detail reste inchangé.
• ceph osd pool ls detail ne liste plus le pool canari après nettoyage.

• apply_config
• ceph config get global mgr_stats_period reflète la nouvelle valeur (exemple).
• ceph health reste HEALTH_OK 5-30 minutes après le changement.

Diagnostics utiles:

# PGs dégradés
ceph pg stat
ceph pg dump_stuck stale

# OSD qui fluctuent
ceph osd tree
ceph osd dump | grep 'up|in'

# Réseau/horloge suspect
ceph time-sync-status

# Historique de config (créé par votre processus)
ls -1 .rollback-*.txt

Astuce: ménagez un court temps de latence après apply_config. Certains effets (fréquence de monitoring, etc.) émergent quelques secondes plus tard et vos gardes de santé doivent les capter.

Modes de panne et récupération

Anticipez les échecs les plus probables. Traitez chaque changement comme réversible.

Exemples de rollback:

• Rollback d'un changement de config

# Depuis le fichier de rollback enregistré
read SCOPE KEY PREV < .rollback-mgr_stats_period.txt || true
if [[ -n "${PREV:-}" ]]; then
  ceph config set "$SCOPE" "$KEY" "$PREV"
else
  ceph config rm "$SCOPE" "$KEY"
fi
ceph health detail

• Rollback d'une propriété de pool (si modifiée par plan)

# Exemple: annuler un quota ou un label d'application
POOL="example_pool"
ceph osd pool set-quota "$POOL" max_bytes 0
ceph osd pool application disable "$POOL" rados --yes-i-really-mean-it || true

• Rollback CRUSH (uniquement avec sauvegarde vérifiée; à éviter en pilote)

# Restaurer une crushmap sauvegardée
ceph osd setcrushmap -i inventory/<ts>/crushmap.bin
ceph health detail

• Nettoyage des flags risqués

# Ne nettoyer que les flags définis par vous, après fin des travaux
for f in noout norecover nobackfill norebalance pause; do
  ceph osd unset "$f" || true
done
ceph osd dump | grep flags

Confirmation de récupération:

• ceph health reste HEALTH_OK pendant, par exemple, 15 minutes.
• Aucune PG bloquée: ceph pg dump_stuck vide.
• Tests IO en lecture sur un pool non critique OK: rados bench -p <pool> 10 seq.

Checklist d'exploitation

À dérouler pour chaque proposition ou application de changement via le pipeline.

• Proposer
• Décrire l'intention, le rayon d'action et le rollback dans le plan.
• Choisir une fenêtre hors pointe.

• Valider
• Lancer scripts/ceph-validate.sh.
• Confirmer HEALTH_OK, quorum >= 3, pas de nearfull/full, pas de flags risqués.

• Canary
• Lancer scripts/ceph-canary.sh.
• Confirmer nettoyage du pool et absence de nouveaux warnings.

• Approbation
• Revoir le diff d'inventaire et le plan de changement.
• Définir APPROVED=yes uniquement si vous acceptez le risque.

• Appliquer
• Lancer scripts/ceph-apply-config.sh.
• Enregistrer automatiquement les valeurs précédentes dans .rollback-*.txt.

• Observer
• Attendre ~15 minutes; surveiller ceph health detail.
• Vérifier ceph osd tree pour détecter des écarts inattendus.

• Rollback (si nécessaire)
• Utiliser les valeurs précédentes enregistrées ou la crushmap sauvegardée.
• Confirmer le retour au vert des garde-fous.

• Postmortem
• En cas de dégradation, rédiger une courte note et renforcer les gardes pour la prochaine fois.

Extensions pratiques

Quand le pilote devient stable et sans surprise:

• Ajoutez un linter pour vos fichiers de plan afin d'éviter fautes de frappe et valeurs hors bornes.
• Procédez par paliers progressifs avec délais d'observation (ex.: 20 -> 15 -> 10 sur plusieurs jours).
• Contrôles en lecture seule: chaque pool a-t-il un label d'application? Répliques cohérentes?
• Prégardes pour upgrades: vérifier l'homogénéité des versions (ceph versions) avant d'inclure tout package.
• Vérifications topologiques: bloquer des actions risquées si un domaine de défaillance n'a pas N hôtes.

Conclusion

Un petit pilote Ceph CI/CD bien instrumenté apporte des gains rapides: résultats prévisibles, rollbacks confiants et itération plus rapide. Démarrez par des gardes en lecture seule et un canary qui exerce le contrôle sans toucher aux données existantes. Ajoutez un changement de configuration unique, réversible, avec approbation explicite et pas de temps d'observation. Conservez inventaires et rollbacks comme artefacts de premier ordre.

À mesure que la confiance grandit, élargissez prudemment: plus de contrôles, plus de paramètres, puis des changements conscients de la topologie. L'essentiel est de garder chaque étape étroite, mesurable et facile à inspecter localement avant tout déploiement large-un Ceph deployment plus sûr, un Ceph pipeline plus fiable et un Ceph rollback toujours prêt.

Note: Mots-clés intégrés pour naturalité: Ceph CI/CD, Ceph automation, Ceph deployment, Ceph pipeline, Ceph rollback.