Set-OPS-Public/wiki/Le-GUI-console-d-exploitation.md

143 lines
7.1 KiB
Markdown
Raw Permalink Normal View History

# Le GUI (console d'exploitation)
> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.
---
## ① Le concept *(générique)*
Un moteur d'infrastructure a besoin d'une **interface humaine** — sinon il n'est utilisable que
par son auteur (ou une IA). Le principe fondateur : **un opérateur doit tout piloter seul**, sans
l'auteur et sans IA (« exploitable sans IA »).
Une bonne console d'exploitation obéit à trois règles :
- **Elle édite la SOURCE, pas l'artefact.** On modifie le *plan* (l'état voulu), jamais l'inventaire
généré. La console montre la vérité, elle ne la contourne pas.
- **Elle prévisualise avant d'agir.** *dry-run* (voir ce qui changerait) avant *apply* (changer).
- **Elle empêche l'invalide.** Le meilleur garde-fou n'est pas un message d'erreur : c'est une
interface où l'erreur est **impossible à saisir**.
---
## ② Comment Set-OPS le fait
`make inventaire-ui` lance une console web **locale** (`127.0.0.1`, protégée par un jeton). Ses vues :
| Vues **éditables** (le plan) | Vues **dérivées** (lecture seule) |
|---|---|
intégrations : le rôle déclare sa politique ; le cluster passe à l'hébergeur Deux corrections de propriété, l'une dans le plan, l'autre dans les intrants. 1. Intégrations universelles (D-33/D-34, P26) Le plan portait 57 lignes d'intégration écrites à la main, dont 28 disaient oui à quelque chose de vrai pour tous les hôtes. Elles n'existaient que pour être oubliées — et elles l'avaient été : dans Chezlepro, backup-01 et infra-pki-01 n'étaient ni supervisés, ni journalisés, ni certifiés. Le rôle déclare désormais sa politique une fois, dans meta/integration.yml ; le plan ne garde que les vrais choix et refuse la recopie. Les exemptions se dérivent du service rendu (sauf_role), jamais d'un nom d'hôte : l'AC ne s'enrôle pas auprès d'elle-même, et l'exemption suit step-ca si on le déplace. Une seule fonction de résolution — integrations_de() — lue par l'inventaire, la voûte et le panneau. Sans le passage par la voûte, les secrets des intégrations universelles auraient cessé d'être exigés et P18 serait passé au vert sur une voûte incomplète. Vérifié : diff vide sur Technolibre (la politique reproduit exactement les 41 lignes retirées) ; sur Chezlepro, exactement les groupes manquants, et pas client_pki sur infra-pki-01. 2. Vue Intégrations : la matrice La fiche montrait les intégrations d'UN serveur ; le trou de Chezlepro n'a pas été trouvé par le panneau mais par le devis de pare-feu. Matrice serveurs x intégrations : colonnes de politique en lecture seule, facultatives cochables sur place, ligne de couverture n/N qui rend le motif visible sans le juger. 3. Propriété des intrants (D-35/D-36, P27) Le cluster Proxmox appartient à l'hébergeur, comme sa fabric et sa frontière. Recopié chez chaque tenant, son inventaire avait déjà divergé : deux listes de stockages contradictoires pour le même matériel. API/nœuds/stockages/ponts vont dans proxmox-hebergeur.yml, à côté d'underlay.yml, dont le chemin se dérive — l'hébergeur reste non déclaré (D-17). Restent au tenant son golden template et ses défauts de placement. Le panneau nomme désormais le propriétaire de chaque section : éditer une section « hébergeur » vaut pour tous ses tenants, et l'écran ne le disait pas. 26 preuves OK, 0 échec. --syntax-check des deux playbooks Proxmox. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 14:09:22 -04:00
| Serveurs · **Intégrations** · Applications · Bases · Domaines · **Intrants** | Flux · Couches · **Réseau** (flotte + devis) |
Le flux d'exploitation, de bout en bout :
1. **Éditer** une vue du plan → **Sauvegarder** ;
2. **« Appliquer le plan »** → régénère l'inventaire (VMID/IP/VLAN **dérivés**) ;
3. **Vérifier** (dry-run) sur un hôte → prévisualise sans rien changer ;
4. **Déployer** → applique les rôles (confirmation **renforcée** si l'instance est en **PROD**) ;
5. **Créer la VM** → clone sur Proxmox depuis le plan.
**L'erreur rendue impossible.** Le champ « Hôte » d'une application est un `<select>` qui ne
propose que des **hôtes réels** : impossible de pointer vers un hôte fantôme. La console couvre le
schéma du plan — et la preuve **P19** le vérifie.
**La flotte, dans la vue Réseau.** Voir toutes les instances, **basculer** (« Activer »), **créer**
une instance depuis un modèle, repérer une **collision** d'index. Cf.
[Multi-instance & fédération](Multi-instance-et-fédération).
### Les vues, annotées
Chaque figure porte ses **repères** (pastilles + légende). Les vues **éditables** d'abord (le plan),
puis les vues **dérivées** (lecture seule) :
**Serveurs** *(éditable)* — inventaire actif et état de la flotte ; cartes serveur et tuiles
VMID/IP/VLAN **dérivées** du seed ; formulaire **Identité** = le seul endroit où l'on édite le plan.
![Vue Serveurs, annotée](img/Set-OPS-Serveurs-annote.svg)
**Applications** *(éditable)* — catalogue des applis, éditeur (rôle · hôte · port · FQDN exposé),
relations déclaratives (requiert · liens · bases), dépendances causales.
![Vue Applications, annotée](img/Set-OPS-Applications-annote.svg)
**Bases — serveur** *(éditable)* — les moteurs SGBD et les bases applicatives « nom @ serveur »,
avec les bases hébergées sur chaque serveur.
![Vue Bases (serveur BD), annotée](img/Set-OPS-Bases-annote.svg)
**Bases — fiche** *(éditable)* — portée · consommateur · serveur, **secret Vault** (jamais en clair,
un pointeur seulement) et le **DSN dérivé** (secret masqué).
![Vue Bases (fiche de base), annotée](img/Set-OPS-Bases-2-annote.svg)
**Domaines** *(éditable)* — zones DNS publique vs interne, autorité · edge · DNSSEC, expositions.
![Vue Domaines, annotée](img/Set-OPS-Domaines-annote.svg)
intégrations : le rôle déclare sa politique ; le cluster passe à l'hébergeur Deux corrections de propriété, l'une dans le plan, l'autre dans les intrants. 1. Intégrations universelles (D-33/D-34, P26) Le plan portait 57 lignes d'intégration écrites à la main, dont 28 disaient oui à quelque chose de vrai pour tous les hôtes. Elles n'existaient que pour être oubliées — et elles l'avaient été : dans Chezlepro, backup-01 et infra-pki-01 n'étaient ni supervisés, ni journalisés, ni certifiés. Le rôle déclare désormais sa politique une fois, dans meta/integration.yml ; le plan ne garde que les vrais choix et refuse la recopie. Les exemptions se dérivent du service rendu (sauf_role), jamais d'un nom d'hôte : l'AC ne s'enrôle pas auprès d'elle-même, et l'exemption suit step-ca si on le déplace. Une seule fonction de résolution — integrations_de() — lue par l'inventaire, la voûte et le panneau. Sans le passage par la voûte, les secrets des intégrations universelles auraient cessé d'être exigés et P18 serait passé au vert sur une voûte incomplète. Vérifié : diff vide sur Technolibre (la politique reproduit exactement les 41 lignes retirées) ; sur Chezlepro, exactement les groupes manquants, et pas client_pki sur infra-pki-01. 2. Vue Intégrations : la matrice La fiche montrait les intégrations d'UN serveur ; le trou de Chezlepro n'a pas été trouvé par le panneau mais par le devis de pare-feu. Matrice serveurs x intégrations : colonnes de politique en lecture seule, facultatives cochables sur place, ligne de couverture n/N qui rend le motif visible sans le juger. 3. Propriété des intrants (D-35/D-36, P27) Le cluster Proxmox appartient à l'hébergeur, comme sa fabric et sa frontière. Recopié chez chaque tenant, son inventaire avait déjà divergé : deux listes de stockages contradictoires pour le même matériel. API/nœuds/stockages/ponts vont dans proxmox-hebergeur.yml, à côté d'underlay.yml, dont le chemin se dérive — l'hébergeur reste non déclaré (D-17). Restent au tenant son golden template et ses défauts de placement. Le panneau nomme désormais le propriétaire de chaque section : éditer une section « hébergeur » vaut pour tous ses tenants, et l'écran ne le disait pas. 26 preuves OK, 0 échec. --syntax-check des deux playbooks Proxmox. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 14:09:22 -04:00
**Intégrations** *(éditable)* — la **matrice serveurs × intégrations**. Les colonnes ✓ vertes
sont la **politique des rôles** : elles s'appliquent à tout hôte et ne se décochent pas ; un `—`
barré signale une **exemption dérivée du service rendu** (l'AC ne s'enrôle pas auprès d'elle-même).
Les autres colonnes sont de vrais choix, cochables ici. La ligne **couverture** ne juge pas — elle
rend le motif visible : c'est au lecteur de savoir si les manquants sont des décisions ou des oublis.
> Cette vue existe parce que la fiche de détail ne montrait les intégrations que **d'un serveur à
> la fois**. Deux serveurs sans supervision ni journaux sont restés invisibles jusqu'à ce qu'un
> devis de pare-feu les énumère : l'information était à l'écran, répartie sur quatorze clics.
**Flux** *(dérivée)* — la **matrice d'audit** : la source de nftables *et* la justification lisible
de chaque flux (sens ingress/egress, chiffrement).
![Vue Flux, annotée](img/Set-OPS-Flux-annote.svg)
**Couches** *(dérivée)* — l'**ordre de déploiement** en 6 couches, du socle aux agents ; celui que
`make deployer-tout` déroule.
![Vue Couches, annotée](img/Set-OPS-Couches-annote.svg)
**Réseau** *(dérivée)* — la **flotte multi-instances** : adressage dérivé du seed, bascule
d'instance, devis de configuration des switches.
![Vue Réseau, annotée](img/Set-OPS-Reseau-annote.svg)
> Chaque figure est un **SVG auto-contenu** (la capture y est intégrée) : un seul fichier portable
> qui rend tel quel dans le wiki, un `.md` du dépôt, ou un navigateur.
---
## ③ Pourquoi c'est transférable
| Set-OPS | Équivalents ailleurs |
|---|---|
| GUI au-dessus d'Ansible | **AWX** / Ansible Automation Platform, **Semaphore** |
| éditer la source de vérité | l'UI de **NetBox** (IPAM/DCIM), une CMDB |
| dry-run → apply | `terraform plan/apply`, tout panneau IaC |
| l'invalide impossible à saisir | *validation à la source*, formulaires contraints |
Tu as appris **la console d'exploitation, éditer-la-source, dry-run-avant-apply, la validation à la
saisie** — pas « le GUI de Set-OPS ».
---
## ④ À toi de jouer
1. **Lance-la.** `make inventaire-ui`, ouvre l'URL affichée. Repère l'inventaire actif et l'état de
la flotte (en haut), les onglets, « Appliquer le plan », « Sauvegarder ».
2. **Édite → prévisualise.** Vue **Serveurs**, change la mémoire d'un hôte, **Sauvegarder**,
**Appliquer le plan**, puis **Vérifier** (dry-run) : tu vois ce qui *changerait* avant d'agir.
3. **Répare un hôte fantôme (l'erreur impossible).** Si une appli pointe un hôte inexistant, ouvre
la vue **Applications**, sélectionne-la : le `<select>` « Hôte » ne montre **que des hôtes
réels**. Choisis le bon, **Sauvegarder**, **Appliquer**. Tu ne *peux pas* re-saisir le fantôme.
4. **Bascule d'instance.** Vue **Réseau**, bouton **« Activer »** sur une autre instance. Toutes
les vues suivent, sans redémarrer.
5. **Sens le garde-fou.** Essaie de sauvegarder un plan incohérent (ex. une base dont le
consommateur n'existe pas) : la console **refuse** avec une raison. L'invalide ne passe pas.
6. **Casse & répare.** Édite `hosts.yml` à la main, reviens dans la GUI, « Appliquer le plan » : ta
modification est **écrasée** par le plan. La source de vérité, c'est le plan — pas l'inventaire.
---
## Pour aller plus loin *(dépôt)*
- Lancer : `make inventaire-ui` ; le code : `scripts/inventory_gui.py`.
- Ce que le GUI sait écrire (et la preuve) : `scripts/couverture_gui.py` (P19).
- Le flux plan → apply : unité **[Infra as Code & idempotence](Infra-as-Code-et-idempotence)**.
- La flotte : unité **[Multi-instance & fédération](Multi-instance-et-fédération)**.