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

Ceph sous-tend le stockage critique pour les machines virtuelles, les conteneurs et les services. Traiter les modifications Ceph comme du code — revues et vérifiées via un flux CI/CD — permet d'apporter des ajustements mineurs, sûrs et audibles. L'avantage : moins de régressions, une récupération plus rapide en cas de problème et une traçabilité claire de ce qui a changé et pourquoi.

Ce guide montre comment construire une automatisation CI/CD Ceph pratique avec un pilote étroit et vérifiable. Vous allez :

• Capturer un inventaire d'environnement fiable.
• Configurer un accès restreint pour l'automatisation.
• Implémenter un chemin de configuration sûr avec garde-fous explicites.
• Construire un pipeline minimal qui valide, teste en canari et applique.
• Vérifier les résultats avec des contrôles observables.
• Gérer les modes de défaillance courants avec des procédures de rollback.

Tous les exemples sont construits pour illustration. Ajustez les valeurs à votre topologie et votre tolérance au risque.

Inventaire de version et d'environnement

Avant d'automatiser quelque changement que ce soit, figez une vue cohérente du cluster. L'inventaire devient votre artefact de référence et votre première étape de pipeline.

Exécutez ces commandes depuis un hôte admin avec accès au CLI ceph et stockez les sorties dans un répertoire horodaté (par exemple, inventory/2025-01-15/) :

set -euo pipefail
TS="$(date +%F-%H%M%S)"\nOUT="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"

Gardez un résumé lisible pour des revues rapides.

Stockez ces artefacts avec votre dépôt de configuration pour que chaque exécution de pipeline référence les mêmes faits. Différencier les inventaires entre exécutions rend la dérive et les mises à jour évidentes.

Prérequis et accès

Il vous faut un outillage fiable et des identifiants à portée restreinte.

• Outils : CLI ceph et CLI rados installés sur vos hôtes d'exécution (runner).
• Synchronisation temporelle : NTP/chrony fonctionnel sur le runner et les nœuds du cluster.
• Réseau : le runner atteint les moniteurs (6789/3300) et les gestionnaires (managers) selon les besoins.
• Secrets : deux trousseaux de clés (keyrings), un en lecture seule pour la validation et un en écriture restreinte pour les changements contrôlés.

Créez une clé en lecture seule pour la validation :

# Exécuter avec privilèges admin une seule fois
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éez une clé de maintenance restreinte pour les écritures contrôlées. Limitez les capacités à ce que vous comptez automatiser initialement. Par exemple, pour des opérations limitées sur les pools et les clés de configuration :

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

Stockez les deux trousseaux de clés de manière sécurisée sur l'hôte runner. N'incorporez pas de clés dans les scripts. Utilisez des permissions 0600 et un utilisateur système dédié.

Conventionnellement, définissez les variables d'environnement dans votre job runner pour pointer vers le trousseau :

export CEPH_ARGS="--name client.cicd_ro --keyring /etc/ceph/ceph.client.cicd_ro.keyring"
# Pour les étapes d'application, basculez explicitement sur l'utilisateur maint par étape

Chemin de configuration sûr

Commencez par des changements qui sont :

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

Cibles précoces à fort signal :

• Portes en lecture seule : la santé doit être OK (ou un ensemble défini d'avertissements acceptables), les moniteurs en quorum, pas d'état nearfull/full.
• Hygiène des métadonnées de pool : s'assurer que les étiquettes d'application (application labels) sont présentes ; vérifier les quotas pour les nouveaux pools.
• Paramètres non perturbateurs à effet borné, modifiés progressivement (par exemple, ajuster un réglage de gestion sans impact sur le chemin d'E/S).

À éviter dans le premier pilote :

• Modifications de la CRUSH map qui déplacent beaucoup de données.
• Changements de size/min_size sur les pools de production.
• Mises à jour de paquets OSD/Moniteur.
• Drapeaux (flags) comme noout, norecover, noscrub sauf si vous avez un flux de maintenance explicite et borné dans le temps.

Utilisez des points d'arrêt (hold points) : un job qui émet un résumé et exige une approbation humaine explicite avant de procéder à toute application à l'échelle du cluster.

Exemple de pipeline pilote

Cet exemple montre un flux minimal en trois étapes :

1. validate : vérifications en lecture seule sur la production avec client.cicd_ro. Échoue rapidement si non sûr.
2. canary : crée un pool canari éphémère, effectue une écriture/lecture/suppression d'objet, puis supprime le pool. Exerce le chemin de contrôle avec client.cicd_maint sans toucher aux charges de travail existantes.
3. apply_config : applique optionnellement un petit changement de configuration réversible, conditionné par la santé et une approbation manuelle.

Arborescence de répertoires (exemple construit) :

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

# Utilise la clé en lecture seule
export CEPH_ARGS="--name client.cicd_ro --keyring /etc/ceph/ceph.client.cicd_ro.keyring"

# 1) Portes de santé du cluster
ceph status
HEALTH=$(ceph health -f plain)
if [[ "$HEALTH" != "HEALTH_OK" ]]; then
 echo "Refus de continuer : $HEALTH"
 exit 1
fi

# 2) Le quorum des moniteurs doit être >= 3 (ajustez le seuil à la taille de votre cluster)
MONS=$(ceph quorum_status --format json | jq -r '.quorum | length')
if (( MONS < 3 )); then
 echo "Taille du quorum $MONS en dessous du 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 drapeaux de cluster non sûrs
FLAGS=$(ceph osd dump | grep 'flags')
if echo "$FLAGS" | grep -E 'noout|norecover|nobackfill|norebalance|pause' >/dev/null; then
 echo "Drapeaux non sûrs présents : $FLAGS"
 exit 1
fi

echo "Validation réussie."

scripts/ceph-canary.sh

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

# Utilise la clé de maintenance pour les actions d'écriture mais garde la portée étroite
export CEPH_ARGS="--name client.cicd_maint --keyring /etc/ceph/ceph.client.cicd_maint.keyring"

CANARY_POOL="ci_canary_$(date +%s)"\n# Crée un petit pool canari (8 PG, répliqué ; ajustez pg_num selon votre politique de dimensionnement)
ceph osd pool create "$CANARY_POOL" 8 8 replicated
ceph osd pool application enable "$CANARY_POOL" rados --yes-i-really-mean-it

# Écrit, lit et supprime un objet de 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

# Supprime le pool canari
ceph osd pool delete "$CANARY_POOL" "$CANARY_POOL" --yes-i-really-really-mean-it
rm -rf "$TMPDIR"

echo "Canari réussi."

scripts/ceph-apply-config.sh

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

# Utilise la clé de maintenance, avec sauvegarde de config et point d'arrêt manuel.
export CEPH_ARGS="--name client.cicd_maint --keyring /etc/ceph/ceph.client.cicd_maint.keyring"

# Plan d'exemple : changer une clé de config à faible risque progressivement
# Plans/config-plan.yaml (exemple construit) :
# 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" )\nSCOPE=$(yq '.changes[0].scope' -r "$PLAN_FILE" )\nVAL=$(yq '.changes[0].value' -r "$PLAN_FILE" )\nPREV=$(yq '.changes[0].previous' -r "$PLAN_FILE" )\n# Sauvegarde la valeur existante si présente
EXISTING=$(ceph config get "$SCOPE" "$KEY" || true)
echo "Existant $KEY=$EXISTING"

# Point d'arrêt : exige une variable d'env explicite définie par l'approbateur dans le runner
: "${APPROVED:?Définissez APPROVED=yes pour continuer}"\n# Applique le 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 après changement de config ; restauration"
 if [[ -n "$EXISTING" ]]; then
 ceph config set "$SCOPE" "$KEY" "$EXISTING"
 else
 ceph config rm "$SCOPE" "$KEY"
 fi
 exit 1
fi

# Enregistre la valeur précédente pour le rollback
echo "$SCOPE $KEY $EXISTING" > " .rollback-$KEY.txt"\necho "Appliqué $KEY=$VAL"

Vous pouvez orchestrer ces scripts dans votre runner préféré comme trois jobs séquentiels avec une porte d'approbation avant ceph-apply-config.sh.

Vue compacte des étapes et portes :

Vérification et diagnostics

La vérification porte sur les sorties attendues et l'absence de nouveaux avertissements. Après chaque étape :

validate

• ceph status affiche HEALTH_OK.
• ceph quorum_status montre la longueur de quorum attendue.
• ceph df n'affiche pas de pools nearfull/full.
• ceph osd dump ne contient pas les drapeaux noout, norecover, nobackfill, norebalance, pause.

canary

• rados put/get/diff retourne succès.
• ceph health detail reste inchangé avant/après.
• ceph osd pool ls detail ne liste pas le pool canari après nettoyage.

apply_config

• ceph config get global mgr_stats_period affiche la nouvelle valeur (clé d'exemple construite).
• ceph health est encore HEALTH_OK 5 à 30 minutes après le changement.

Diagnostics utiles si quelque chose semble anormal :

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

# Flapping d'OSD
ceph osd tree
ceph osd dump | grep 'up|in'

# Soupçon réseau/horloge
ceph time-sync-status

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

Astuce : incluez toujours un court temps d'attente après apply_config. Certains effets apparaissent quelques secondes plus tard (ex. fréquence de monitoring), et vous voulez que les portes de santé les capturent. Un sleep de 5 secondes dans le script capture les régressions immédiates ; étendez à 15-30 minutes d'observation passive avant de déclarer le changement pleinement stabilisé.

Modes de défaillance et récupération

Prévoyez les façons courantes dont une automatisation Ceph peut échouer. Traitez chaque changement comme réversible.

Exemples de playbooks de rollback :

Rollback de 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 de propriété de pool (si vous avez changé une propriété par plan)

# Exemple : restaurer un quota ou une étiquette d'application (exemple construit)
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 après une sauvegarde vérifiée ; éviter dans le premier pilote)

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

Nettoyage des drapeaux non sûrs

# Nettoyer les drapeaux de maintenance seulement si vous les avez définis intentionnellement et terminé le travail
for f in noout norecover nobackfill norebalance pause; do
 ceph osd unset "$f" || true
done
ceph osd dump | grep flags

Liste de contrôle de confirmation de récupération :

• ceph health retourne HEALTH_OK sur une période soutenue (par exemple, 15 minutes).
• Pas de PGs bloqués : ceph pg dump_stuck retourne vide.
• Tests d'E/S sur un pool non critique réussissent : rados bench -p <test_pool> seq (optionnel, en lecture seule là où c'est sûr).

Liste de contrôle opérationnelle

Exécutez cette liste à chaque fois que vous proposez ou appliquez un changement via le pipeline.

Proposer

• Décrire l'intention, le rayon d'impact (blast radius) et le rollback dans le fichier de plan.
• Choisir une fenêtre creuse.

Valider

• Exécuter scripts/ceph-validate.sh.
• Confirmer HEALTH_OK, quorum >= 3, pas de nearfull/full, pas de drapeaux non sûrs.

Canari

• Exécuter scripts/ceph-canary.sh.
• Confirmer que le pool canari est nettoyé et qu'aucun nouvel avertissement n'apparaît.

Approuver

• Revoir le diff des artefacts d'inventaire et du plan de changement.
• Définir APPROVED=yes dans le runner seulement si vous acceptez le risque.

Appliquer

• Exécuter 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 des changements inattendus.

Rollback (si nécessaire)

• Utiliser les valeurs précédentes enregistrées ou la crushmap de sauvegarde.
• Confirmer que les portes de récupération reviennent au vert.

Post-mortem

• Si quelque chose s'est dégradé, écrire une note courte et ajuster les portes pour le capturer plus tôt la prochaine fois.

Extensions pratiques

Une fois le pilote stable et sans surprise, étendez prudemment :

• Ajoutez un linter pour vos fichiers de plan pour prévenir les fautes de frappe et les valeurs hors limites.
• Ajustements progressifs avec arrêts progressifs : par exemple, 20 -> 15 -> 10 sur plusieurs jours, chacun avec temps d'attente et vérification.
• Vérifications de politique en lecture seule : vérifier que chaque pool a une étiquette d'application ; alerter sur les tailles de réplica incohérentes.
• Portes de pré-vol pour les mises à niveau : comparer la sortie de ceph versions pour assurer l'homogénéité avant de mettre tout changement de paquet dans le périmètre.
• Vérifications conscientes de la topologie : bloquer les actions risquées si un domaine de panne a moins de N hôtes.

Conclusion

Un petit pilote CI/CD Ceph bien instrumenté apporte des gains rapides : résultats prévisibles, rollbacks confiants et itérations plus rapides. Commencez par des portes en lecture seule et un canari qui exerce le contrôle sans toucher aux données existantes. Ajoutez un unique changement de configuration réversible avec une porte d'approbation et des étapes de rollback claires. Gardez les inventaires et les rollbacks comme artefacts de première classe.

À mesure que vous gagnez en confiance, élargissez la surface progressivement : plus de vérifications, plus de paramètres, puis des changements prudents et conscients de la topologie. La clé est de garder chaque étape étroite, mesurable et facile à inspecter localement avant tout déploiement large. Cette approche réduit le retravail, améliore la sécurité et rend vos opérations Ceph progressivement plus fiables.