Aller au contenu

ccx-ops — exploitation serveur

Statut

HISTORICAL / COMPATIBILITY GUIDE

Cette page conserve le vocabulaire historique ccx-ops et les anciennes commandes directes associées afin d'aider à comprendre les procédures et scripts encore rencontrés dans l'historique du projet.

Elle ne doit pas être utilisée, à elle seule, comme preuve qu'un binaire ccx-ops ou qu'une commande ccx-* est actuellement installé dans le Runtime.

Pour l'exploitation courante du dépôt, la référence vérifiée est le Makefile et les scripts appelés par celui-ci.

Ce qu'il faut utiliser en priorité aujourd'hui

Depuis la racine du dépôt :

make doctor
make backup
make backup-verify BUNDLE=/chemin/vers/le/bundle
make restore-check BUNDLE=/chemin/vers/le/bundle

Le Makefile versionné définit actuellement ces entrées opérateur :

  • make doctor : diagnostics read-only de la plateforme ;
  • make backup : création d'un backup atomique ;
  • make backup-verify : vérification d'un bundle existant ;
  • make restore-check : restauration de contrôle dans une MariaDB éphémère isolée ;
  • make guard-static : vérification statique du wiring Runtime ;
  • make guard-runtime : vérification du Runtime WordPress actif ;
  • make docs-check : validation stricte de la documentation dans un répertoire temporaire ;
  • make docs-build : construction de la documentation servie.

Ces commandes sont de meilleurs points d'entrée de transmission parce qu'elles sont directement définies dans le dépôt.

Pourquoi ccx-ops apparaît encore dans la documentation

Historiquement, ccx-ops regroupait plusieurs commandes d'exploitation serveur : santé, sauvegardes, vérification, inventaire, alertes, capacité de restauration et audit global.

On peut encore rencontrer des noms comme :

ccx-health
ccx-backup
ccx-backup-prune
ccx-backup-verify
ccx-docker-backup
ccx-inventory
ccx-alert
ccx-restore-check
ccx-audit

Ces noms sont utiles pour lire les anciens audits, commits ou procédures, mais leur présence dans ce document ne certifie pas leur disponibilité actuelle sur le VPS.

Comment vérifier une commande historique

Avant d'utiliser un ancien nom :

  1. chercher son implémentation dans le dépôt ;
  2. vérifier s'il est encore installé dans l'environnement ciblé ;
  3. comparer son comportement avec le Makefile et les scripts actuels ;
  4. privilégier l'entrée actuelle lorsqu'elle existe.

Exemples d'observation locale :

command -v ccx-ops || true
command -v ccx-health || true
command -v ccx-backup || true

Puis dans le dépôt :

git grep -n "ccx-ops\|ccx-health\|ccx-backup\|ccx-restore-check\|ccx-audit" -- . ':!docs'

L'absence de résultat doit conduire à traiter le nom comme historique, pas à recréer un script au hasard.

make doctor

make doctor est une opération d'observation.

Elle vérifie notamment :

  • la configuration Docker Compose ;
  • les politiques de conteneurs ;
  • l'état des services ;
  • la réponse HTTP de WordPress ;
  • la réponse et la fraîcheur de la documentation servie ;
  • le wiring Runtime canonique via le guard read-only.

Elle ne remplace pas un diagnostic métier du catalogue.

Un échec de make doctor signifie qu'une précondition opérationnelle ou technique est en défaut. Il faut lire l'étape précise qui échoue avant toute mutation.

make backup

make backup est une écriture opérationnelle : il crée un nouveau bundle de sauvegarde.

Le Makefile délègue à :

scripts/backup-create.sh

La racine de backup est fournie via CCX_BACKUP_ROOT.

Avant exécution :

  • confirmer l'environnement ;
  • vérifier l'espace disque ;
  • vérifier le chemin de destination ;
  • éviter de confondre création d'un backup et validation d'un backup existant.

make backup-verify

Cette commande vérifie un bundle existant :

make backup-verify BUNDLE=/chemin/vers/le/bundle

Le Makefile délègue à :

scripts/backup-verify.sh

Elle sert à démontrer que l'artefact de sauvegarde possède la structure et les éléments attendus.

Une vérification réussie ne prouve pas, à elle seule, que la restauration complète du service fonctionnera.

make restore-check

Cette commande teste la restauration dans une MariaDB éphémère isolée :

make restore-check BUNDLE=/chemin/vers/le/bundle

Le Makefile délègue à :

scripts/backup-restore-check.sh

C'est le contrôle à privilégier pour valider la capacité réelle de restauration sans restaurer directement la production.

Il faut distinguer :

backup créé
    ↓
backup vérifié
    ↓
restore-check réussi

Ces trois niveaux ne sont pas équivalents.

Guards Runtime

Deux commandes sont utiles avant une opération sensible :

make guard-static
make guard-runtime

Elles passent par :

scripts/runtime-readonly-guard.sh
  • guard-static vérifie le wiring canonique sans Docker actif ;
  • guard-runtime vérifie la pile WordPress réellement démarrée.

Ces guards sont read-only et doivent être préférés à une modification exploratoire du Runtime.

Documentation

Le dépôt expose aussi :

make docs-check
make docs-build

docs-check construit la documentation en mode strict dans un répertoire temporaire afin de ne pas modifier le site servi.

docs-build construit le site servi et enregistre le commit Git courant dans :

site/.ccx-docs-commit

make doctor utilise ce marqueur pour détecter une documentation servie obsolète.

Ancien rôle de ccx-ops audit

Les anciennes documentations présentaient ccx-ops audit comme un agrégateur de santé, restore-check, documentation, capacité Docker et inventaire.

Cette intention reste pertinente : un audit d'exploitation doit agréger des preuves techniques cohérentes.

Mais le nom exact ccx-ops audit ne doit pas être considéré comme CURRENT sans vérification de l'exécutable installé.

Aujourd'hui, partir des commandes versionnées et vérifiables (make doctor, guards, backup/verify/restore-check) est plus sûr.

Diagnostic recommandé

En cas de problème d'exploitation :

1. Observer
   ↓
make doctor
   ↓
2. Identifier la couche en défaut
   ↓
Docker / WordPress / docs / wiring Runtime / sauvegarde
   ↓
3. Utiliser le contrôle spécialisé
   ↓
guard, backup-verify, restore-check, logs ciblés
   ↓
4. Corriger la cause
   ↓
5. Rejouer le contrôle initial

Ne pas créer ou modifier des données métier pour réparer un échec purement infrastructurel.

Invariants

  • Les outils d'exploitation serveur ne portent aucune logique métier.
  • Une commande historique n'est jamais supposée installée sans vérification.
  • Les entrées du Makefile versionné sont préférées quand elles couvrent le besoin.
  • doctor, guard-static et guard-runtime restent des opérations d'observation.
  • backup crée un artefact ; backup-verify le contrôle ; restore-check teste sa restaurabilité.
  • Une restauration de contrôle s'effectue dans un environnement isolé, jamais directement sur la production.
  • Un problème de Runtime ou d'infrastructure doit être réparé dans sa couche, pas compensé par une mutation métier.

Voir aussi