Cycle de vie des services

Cette page décrit ce que fait le gestionnaire de plateforme autour d'une installation : profils d'installation, vérifications préalables, contrôles de vivacité, de disponibilité et tests fonctionnels, mises à niveau et retours arrière, sauvegardes et restaurations, détection de dérive, archive de support, rapport de recette signé et fiche composant. Les routes sont listées dans navin-manager/CONTRACT.md, sections 7.8 à 7.12.

Profils d'installation

Le profil se choisit dans l'assistant de création de cluster (Clusters, Nouveau cluster) et se modifie dans l'onglet Profil du cluster. Chaque règle est évaluée sur l'état réel de la console et du cluster, jamais déclarée.

Profil	Règles
Développement	Catalogue valide. Les problèmes DNS ne font qu'avertir.
Standard (entreprise)	TLS sur la console, certificats clients des agents, TLS sur chaque service qui le prend en charge, MFA exigée pour les rôles d'administration.
Bancaire sécurisé	Standard, plus TLS sur chaque point de terminaison, MFA enrôlée par chaque administrateur local, miroir seul, audit distant (syslog), aucun service de bac à sable, approbation d'une seconde personne pour chaque opération perturbatrice.
Isolé (sans Internet)	TLS partout, miroir seul, aucune connexion liée ni webhook hors des réseaux privés.
Hybride	Standard, plus TLS sur chaque connexion vers l'infrastructure du client.

Un profil dont toutes les règles ne sont pas respectées est affiché bloqué, avec les règles en échec et leur raison. Tant qu'il est bloqué, les installations, mises à niveau, commandes, démarrages et redémarrages sont refusés (profile_blocked) ; l'arrêt, la désinstallation, la configuration, le retour arrière et la sauvegarde restent possibles pour remettre le cluster en conformité.

Règle des quatre yeux (bancaire sécurisé) : l'arrêt, le redémarrage, la réinstallation, la désinstallation, la mise à niveau, le retour arrière, la restauration et l'application de configuration exigent une approbation. Demandez-la dans l'onglet Approbations (action, service, raison) ; un autre administrateur l'approuve ou la rejette ; le demandeur lance ensuite l'opération avec cette approbation, une seule fois, dans les 24 heures.

Les profils ne remplacent jamais la sécurité de l'infrastructure du client (BYO) : la console ne fait que lire les connexions, n'y lance aucune commande destructrice, et les règles de sortie et de TLS rendent compte de ce qui est lié.

Vérifications préalables

Les vérifications préalables s'exécutent au début de chaque installation et de chaque mise à niveau, et à la demande (onglet Profil, Lancer les vérifications) :

• faits de l'hôte : système d'exploitation, architecture, mémoire, disques et systemd bloquent ; les autres contrôles d'hôte avertissent ;
• DNS direct (le FQDN se résout vers l'adresse enregistrée) et inverse (l'adresse se résout vers le FQDN) ; un échec bloque sous chaque profil sauf développement ;
• vérifications préalables du catalogue (ports libres, réglages du noyau, outils) ;
• capacité : minimums de mémoire et de processeurs de chaque service géré placé sur chaque hôte ;
• versions : version de l'agent de chaque hôte, artefacts de la version installée présents dans le miroir ;
• TLS : validité de l'autorité de certification de la console, poignée de main TLS réelle avec le point de terminaison des agents et avec chaque point de terminaison TLS lié aux services (expiré, non approuvé ou refusé : échec ; moins de 14 jours : avertissement) ;
• les règles du profil du cluster.

Un seul échec critique fait échouer l'opération avant l'écriture du moindre fichier.

Vivacité, disponibilité et tests fonctionnels

Un port qui répond ne prouve pas que le service fonctionne. Le bloc Contrôles de la fiche composant affiche trois résultats distincts :

• vivacité : contrôles de santé de chaque instance, rafraîchis par les agents ;
• disponibilité : vérification du service déclarée au catalogue ;
• test fonctionnel : une opération réelle de l'outil avec un nonce neuf, exécutée par la tâche d'agent smoke.run : politique OPA chargée puis une décision qui doit autoriser et une qui doit refuser, magasin, modèle, relation et deux vérifications OpenFGA, écriture puis lecture puis suppression d'une clé etcd, abonnement puis publication puis livraison NATS, collecte des métriques processeur, mémoire et système de fichiers du node exporter. Les étapes de nettoyage s'exécutent même après un échec.

Chaque plan d'installation et de configuration se termine par la vérification du service puis le test fonctionnel ; le bouton Lancer le test fonctionnel de la fiche l'exécute seul.

Mises à niveau et retours arrière

Le bloc upgrade d'un descripteur déclare les versions de départ prises en charge (from), si le service a un état, les migrations (chacune peut être déclarée irreversible) et si un retour arrière est possible (avec sa raison sinon). Le miroir conserve plusieurs versions d'un artefact (clés de manifeste <service>:<nom>@<version>), ce qui permet aussi une installation à une version antérieure.

L'onglet Mise à niveau affiche la compatibilité (départ, arrivée, problèmes), puis exécute : vérifications préalables, sauvegarde d'un service avec état, l'hôte canari d'abord (nouvelle version, arrêt, migrations, fichiers et unités, démarrage, santé, test fonctionnel), les autres hôtes un par un, la vérification du service, le test fonctionnel et la nouvelle version. Avant toute exécution, les tâches qui ramènent la version précédente et ses fichiers sont scellées avec la mise à niveau.

Retour arrière : version, fichiers et unités précédents, et version de configuration précédente (enregistrée comme une nouvelle version restaurée depuis l'ancienne), puis santé, vérification du service et test fonctionnel. Quand une migration irréversible a été appliquée ou que le catalogue déclare le retour arrière impossible, il est refusé avec la raison et la restauration est proposée : version précédente plus les données de la sauvegarde prise avant la mise à niveau. Sans cette sauvegarde, l'impossibilité est affichée.

Testé sur l'hôte du bac à sable : OPA 1.21.3 vers 1.21.4 (sans état) et etcd 3.5.20 vers 3.5.21 (avec état, sauvegarde préalable, données conservées), chacun suivi d'un retour arrière.

Sauvegardes et restaurations

Le bloc backup d'un service avec état déclare les étapes, les fichiers produits, les étapes de restauration et une vérification facultative. Déclarés aujourd'hui : etcd (instantané cohérent, restauration d'un membre unique avec etcdutl) et NATS (magasin JetStream archivé pendant un arrêt de quelques secondes du serveur).

Onglet Sauvegardes du cluster : Sauvegarder maintenant lance une sauvegarde coordonnée des services choisis (tous par défaut) dans l'ordre des dépendances, sous un même identifiant d'ensemble ; l'empreinte sha256 de chaque fichier est enregistrée. Restaurer vérifie de nouveau les empreintes (un fichier modifié arrête la restauration avant tout arrêt), arrête les instances, exécute les étapes de restauration, les redémarre, puis lance les contrôles de santé, la vérification, la vérification du service et le test fonctionnel. Une sauvegarde ne se restaure que dans la version où elle a été prise ; pour revenir en deçà d'une mise à niveau, utilisez la restauration de la mise à niveau.

Limites annoncées par les scripts : la restauration etcd traite un cluster à membre unique et la méthode binaire ; un cluster à plusieurs membres se restaure membre par membre avec un nouveau jeton de cluster.

Détection de dérive

Chaque fichier et chaque unité écrits par la console sont enregistrés avec leur empreinte sha256. Une recherche de dérive (onglet Dérive, Rechercher maintenant, et chaque heure) demande à chaque agent les empreintes des chemins gérés : un fichier modifié, supprimé ou remplacé en dehors de la console ouvre un constat et l'alerte config_drift. Un constat est résolu quand le fichier est remis à la main (restauré), réécrit par la console (Réaligner sur le constat, ou toute application de configuration) ou supprimé avec le service.

Archive de support

Onglet Archives de support, Créer une archive : archive tar.gz avec le cluster et son profil, les faits des hôtes, les services et leurs versions, les fichiers de configuration rendus, les fins de journaux des instances, les opérations, les alertes ouvertes et les constats de dérive. Chaque secret connu de la console, les couples d'identifiants, les jetons, les clés privées, les adresses électroniques, les noms des utilisateurs enregistrés, les numéros de téléphone et de carte et les adresses IP des journaux sont masqués ; les opérateurs deviennent des pseudonymes stables. MANIFEST.json liste les fichiers et le nombre de remplacements par nature.

Rapport de recette signé

Onglet Recette, Lancer la recette : vérifications préalables, vivacité de chaque instance, disponibilité et test fonctionnel de chaque service géré, puis un rapport avec une ligne par vérification : PASS (exécutée et conforme), FAIL (exécutée et non conforme) ou BLOCKED (n'a pas pu s'exécuter, par exemple aucun test fonctionnel déclaré), chacune avec sa preuve. Les lignes d'installation comprennent la source hors ligne : chaque artefact de l'installation vient du miroir interne. Le verdict est FAIL quand une ligne a échoué, BLOCKED quand une n'a pas pu s'exécuter, sinon PASS.

Le rapport JSON est signé avec la clé Ed25519 de la console et lisible en HTML en anglais et en français. Vérifiez un rapport téléchargé hors ligne :

navin-manager verify-report --file report.json --public-key manager.pem

(code de sortie 0 quand la signature est valide et faite avec cette clé). La clé publique est affichée dans l'onglet Recette.

Fiche composant

Chaque service a la même fiche à douze onglets, remplie depuis l'état constaté et jamais depuis l'action demandée : Vue d'ensemble (état, santé, versions, contrôles, dérive ouverte), Instances, Configuration, Dépendances, Journaux, Métriques, Sécurité (TLS, secrets, ports, certificats, profil), Opérations, Mise à niveau, Sauvegardes, Audit et Support.