Exploitation

Clusters et hôtes

• Créer un cluster dans Clusters, Nouveau cluster : un nom et un mode (production, preprod, test, development ou sandbox).
• Ajouter des hôtes avec un jeton d'amorçage ou l'amorçage SSH (voir Installation hors ligne). Un jeton appartient à un seul cluster, expire et compte un nombre maximal d'utilisations ; révoquez-le une fois les hôtes enregistrés.
• Page d'un hôte : faits, résultats des contrôles préalables (relancez-les avec Lancer les contrôles), métriques (CPU, mémoire, charge, disques, réseau), composants et leurs actions.
• Paramètres machine : la page liste les paramètres du noyau (sysctl) et les limites de processus demandés par les services placés sur l'hôte (par exemple vm.max_map_count pour OpenSearch), avec la valeur actuelle et la valeur recommandée. Appliquer écrit /etc/sysctl.d/90-navin-*.conf et /etc/security/limits.d/90-navin-*.conf sur l'hôte.
• Maintenance : un hôte en maintenance ne déclenche aucune alerte ; utilisez-la pendant une intervention matérielle.
• Mise hors service : retirez d'abord ses composants, puis Mettre hors service : l'agent oublie ses identifiants et les certificats de l'hôte sont révoqués.

Services

• Installer : l'assistant de Clusters, Installer des services choisit les services, le placement par mode, les liaisons et la configuration. La validation refuse un placement qui enfreint une règle du mode (par exemple un nombre pair de nœuds maîtres OpenSearch) et l'installation en production d'un service réservé aux bacs à sable.
• Démarrer, arrêter, redémarrer : sur tout le service, un composant ou un seul composant d'hôte.
• Redémarrage progressif : les hôtes redémarrent par lots (batch_size), avec un contrôle de santé après chaque lot ; l'opération s'arrête au premier hôte en échec (tolerate_failures, 0 par défaut). La console propose la taille de lot parmi les hôtes qui font tourner le service et ne demande jamais d'échecs tolérés ; l'API garde le champ pour l'automatisation.
• Approbations (banking-secure) : une action perturbatrice sans approval_id utilise l'approbation accordée au demandeur pour la même action et le même service (approuvée, non expirée, non utilisée) ; personne ne saisit d'identifiant d'approbation.
• Contrôle du service : la vérification de bout en bout du catalogue (par exemple une décision OPA ou un PING Redis).
• Commandes : actions du catalogue comme cluster_create pour Redis, snapshot pour etcd, setup_schema pour Temporal, bundle_status pour OPA. Les commandes qui modifient des données demandent une confirmation.
• Journaux : le bouton Journaux récupère les dernières lignes du journal (journalctl) ou des fichiers de journalisation d'un composant sur un hôte.
• Ajouter ou retirer des hôtes d'un composant : la configuration de chaque instance est rendue à nouveau (les listes de pairs changent) et un redémarrage progressif l'applique.
• Désinstaller : refusé tant qu'un autre service utilise le service ; purge_data supprime aussi les répertoires de données.
• Configuration cliente : les fichiers dont un consommateur a besoin pour joindre le service (par exemple les variables EAI_* du Control Plane Navin).
• Actions du cluster (bouton Actions du cluster de la page Services, POST /api/v1/clusters/{id}/actions) : démarrer, arrêter, redémarrer ou redémarrer progressivement tous les services, redémarrer les seules instances dont la configuration a changé (restart_stale, après réécriture de leurs fichiers et unités) et vérifier tous les services. Une seule opération suit l'ordre des dépendances : un fournisseur démarre avant ses consommateurs et s'arrête après eux ; un redémarrage arrête tout dans l'ordre inverse, puis redémarre tout dans l'ordre avec les contrôles de santé. Le plan est affiché avant le lancement, avec les services et instances écartés et la raison : connexion externe, installation ou retrait en cours, état administratif, instance ou hôte en maintenance, hôte décommissionné.
• Actions d'un hôte (menu de l'hôte dans la vue Hôtes et services et sur la fiche hôte, POST /api/v1/hosts/{id}/actions) : démarrer, arrêter, redémarrer tous les composants de l'hôte, ou seulement ceux dont la configuration a changé, en une opération dans l'ordre des dépendances. Avec le profil banking-secure, l'arrêt et les redémarrages demandent l'approbation d'une seconde personne pour le service * (cluster) ou host:<id> (hôte).

Configurations

• L'onglet Configuration d'un service regroupe les paramètres par section, avec leur description, leur valeur par défaut, la valeur recommandée et l'unité ; les secrets s'affichent comme définis ou non.
• Enregistrer crée une version avec une note. Versions compare deux versions (les secrets n'apparaissent que comme modifiés ou non) et Restaurer crée une nouvelle version avec le contenu d'une ancienne.
• Groupes de configuration : ils surchargent des paramètres pour certains hôtes (par exemple plus de mémoire sur les gros hôtes). Un hôte appartient au plus à un groupe par service.
• Aperçu affiche les fichiers rendus pour un hôte et un composant, secrets masqués.
• Appliquer écrit les fichiers modifiés et redémarre les composants (rolling, all ou none). Les hôtes qui tournent encore avec une configuration plus ancienne portent la mention Redémarrage nécessaire.

États administratifs et modes d'exploitation

Un service porte un état administratif (enabled, disabled, maintenance, quarantined, suspended) et une autorisation d'exécution security_state (authorized ou revoked). POST /api/v1/clusters/{cluster_id}/services/ {service}/mode applique un mode ; chaque mode a son effet propre, renvoyé dans effect :

Mode	Nouvelles requêtes	Transactions en cours	Processus	État laissé
drain	refusées	terminées, jusqu'à drain_timeout_s (300 s par défaut)	arrêtés	maintenance
scale_to_zero	refusées jusqu'au prochain démarrage	terminées (délai d'arrêt de l'agent)	arrêtés	enabled
security_suspend	refusées	interrompues aussitôt (SIGKILL)	arrêtés	suspended, revoked
emergency_stop	refusées	interrompues aussitôt (SIGKILL)	arrêtés	disabled
disable	refusées après un arrêt	inchangées	inchangés	disabled
quarantine	inchangées	continuent	gelés (seul l'arrêt reste permis)	quarantined
maintenance	inchangées	continuent	inchangés	maintenance
enable	lève l'état, ne démarre rien			enabled

L'agent reçoit le délai d'arrêt dans la tâche service.control (stop_timeout_s) : SIGTERM puis SIGKILL après ce délai, SIGKILL immédiat à 0. Le planificateur refuse (409 service_admin_state) ce qu'un état interdit : un service disabled refuse tout ce qui le ferait tourner, un service quarantined ou suspended refuse tout sauf l'arrêt et la désinstallation. La suspension de sécurité et sa levée (avec un motif) demandent pki:manage. Le vidage et la mise à zéro suivent la règle des deux personnes du profil comme un arrêt.

Verrou de sécurité : POST /api/v1/clusters/{cluster_id}/security-lock {reason} (pki:manage) refuse toute nouvelle opération du cluster (423 cluster_security_locked) sauf une suspension de sécurité ou un arrêt d'urgence, jusqu'à DELETE .../security-lock. Chaque mode, verrou et refus est audité.

Opérations

Chaque action est une opération. La page Opérations les liste par cluster ; une opération montre ses étapes, les tâches de chaque étape par hôte, leur état, leur durée et leurs journaux en direct. Interrompre arrête les tâches en attente (les tâches en cours se terminent). Relancer crée une nouvelle opération à partir de l'étape en échec. Une tâche sans résultat après son délai échoue avec l'état timed_out.

Blueprints

Clusters, Blueprint exporte les services d'un cluster (modes, méthodes, placement par groupe d'hôtes, configuration sans les secrets). L'import d'un blueprint dans un autre cluster avec une correspondance d'hôtes reproduit l'installation ; les secrets sont générés à nouveau ou demandés.

Mises à jour

1. Construisez et chargez le bundle hors ligne de la nouvelle version (le miroir peut contenir plusieurs versions).
2. Mettez à jour le paquet du serveur et lancez navin-manager migrate, puis redémarrez navin-manager.
3. Mettez à jour les paquets des agents (dnf upgrade ou apt install) : les agents gardent leur identité.
4. Mettez à jour les services un par un depuis leur page : Réinstaller avec la version du nouveau catalogue, puis un redémarrage progressif. L'alerte agent_version_mismatch liste les agents restés sur une version plus ancienne.

Dépendances des services à l'installation

Avant chaque installation, le Manager résout ce dont chaque service a besoin (ses requires dans le mode choisi), dans cet ordre :

1. la liaison choisie dans l'assistant ;
2. un service de la même installation ;
3. un service déjà installé sur le cluster : ses paramètres de connexion (adresse, port, base, utilisateur) sont relus, ses secrets restent scellés ;
4. la seule connexion déclarée de ce type ;
5. sinon le fournisseur est ajouté à l'installation (mode par défaut, ou premier mode HA permis par les hôtes quand le service l'exige), placé sur les hôtes du service qui en a besoin, puis installé et configuré avant lui ; ses propres dépendances sont résolues de la même façon.

L'assistant affiche le résultat aux étapes Liaisons et Installer : statut de chaque dépendance, adresse, paramètres, noms des clés scellées, puis la liste numérotée de toutes les étapes de l'opération. Pendant l'installation, chaque service commence par l'étape « dépendances » : elle revérifie les fournisseurs et écrit une ligne de journal par liaison, sans secret ; la page de l'opération affiche ce rapport et le message de toute tâche en échec.

L'installation est refusée quand un fournisseur installé est arrêté, en échec ou en cours d'installation (dependency_unavailable), quand plusieurs connexions du même type conviennent (dependency_choice_required), ou quand le fournisseur est réservé aux bacs à sable alors que le cluster est en production ou en préproduction (dependency_connection_required : liez plutôt une connexion existante du même type, par exemple le cluster PostgreSQL de la banque). L'API garde la seule règle de validation avec auto_dependencies: false.

Sauvegardes

Élément	Méthode
Base de la console	Sauvegardes du PostgreSQL de la banque (il contient clusters, configurations, opérations, audit).
Clé maître	/etc/navin-manager/master.key, copiée une fois dans le coffre de la banque. Sans elle, les secrets stockés sont perdus.
Réglages du serveur	/etc/navin-manager/ (server.yaml, server.env, certificats).
Miroir	Se reconstruit depuis les bundles ; conservez les bundles des versions en service.
Données des services	Avec les outils de chaque service (par exemple la commande snapshot d'etcd, pg_basebackup pour PostgreSQL).

PostgreSQL

Le catalogue installe PostgreSQL 16 avec pgvector en serveur unique (mode standalone, méthodes podman, package et python) ou en cluster hautement disponible de 2 à 7 membres, 3 recommandés (mode ha, méthodes package et python) : Patroni conserve la clé du leader dans le service etcd du cluster, les autres membres sont des réplicas en flux et le réplica sain le plus avancé est promu quand le leader est perdu ; l'ancien leader revient comme réplica (pg_rewind, ou un nouveau clone). Installez d'abord etcd en mode cluster : Patroni rétrograde le leader quand etcd est injoignable.

• Consommateurs : la liaison liste tous les membres ; les clients utilisent la liste libpq avec target_session_attrs=read-write et joignent toujours le leader. Pour un client qui ne prend qu'une adresse, placez HAProxy devant les membres avec un contrôle HTTP GET /primary sur le port de l'API REST de Patroni (8008) : seul le leader répond 200.
• TLS (tls_enabled, méthodes podman et package) : le SQL, la réplication et l'API REST de Patroni utilisent le certificat de l'autorité de la console, les connexions sans TLS sont refusées (hostnossl reject), les membres se vérifient en verify-full. Activez-le quand etcd utilise TLS : etcd demande alors un certificat client à Patroni. Les liaisons donnent sslmode=require car les consommateurs ne reçoivent pas l'autorité ; un client qui la possède peut utiliser verify-full.
• pgvector (pgvector, actif par défaut) : provision_consumer crée l'extension vector dans template1 et dans la base de chaque consommateur ; enable_extension ajoute vector, pg_trgm ou une autre extension contrib à une base.
• Commandes du mode ha : cluster_status (patronictl list), switchover vers un réplica nommé, reinit_member d'un réplica, push_settings (écrit max_connections, les WAL, ttl, loop_wait, retry_timeout et synchronous_mode dans etcd, puis redémarre les membres un par un, le leader en dernier).
• Sauvegarde : pg_basebackup sur le leader (tar, WAL en flux, manifeste SHA256), vérifiée par pg_verifybackup. Une restauration arrête tous les membres, remplace le répertoire de données du membre de la sauvegarde et réinitialise l'état du cluster dans etcd ; ce membre démarre comme leader et chaque autre membre est de nouveau cloné depuis lui à son démarrage.