Daniel Allaire
f33b5be151
La console offrait des boutons sans sequence. Rien n'y apprenait que site-creer precede forge-amorcer, que le premier passage de site-deployer-tout s'arrete sur une forge vide sans que ce soit un echec, ni que rien n'est pret avant valider : cet ordre vivait en prose dans des documents que la console ne porte pas. La vue Assistants conduit 17 runbooks et 126 etapes. Les 132 cibles documentees y sont, chacune portee par un assistant ou exemptee avec son motif — une exemption muette est refusee. Le registre ne recopie pas le Makefile : il declare l'ordre, la nature, la portee et le pourquoi, et le libelle de chaque etape est lu dans le Makefile au moment de servir. P83 est ecrite en meme temps que la liste, pas apres, parce qu'une liste qui suit une autre prend du retard. Onze tests lui presentent des registres faux, un par forme de retard, et exigent qu'elle les refuse. Le navigateur ne nomme pas une commande, il nomme une place : la route lance ce que le registre declare a cet index-la, avec les seules variables declarees. L'index compte, le premier jour d'un site jouant site-deployer-tout deux fois. Une etape qui ecrit attend que la precedente ait reussi ; une mesure reste toujours offerte, parce que mesurer apres un echec est exactement ce qu'on fait ensuite. Valide : runbooks.py verifier a 0 ecart, make test a 0 echec, les 83 preuves rejouees, et la console lancee pour de vrai — 17 runbooks servis, six requetes malformees refusees une a une, une etape de mesure executee de bout en bout avec son journal. Limite, anterieure a ce travail : P02 (test_ecriture_plan) echoue sur domaines.yml, a l'identique sur une copie de HEAD. Ajouter ou retirer un domaine public depuis la vue Domaines leverait a l'enregistrement. Non corrige ici. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
215 lines
12 KiB
Markdown
215 lines
12 KiB
Markdown
# 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) |
|
||
|---|---|
|
||
| Serveurs · **Intégrations** · Applications · Bases · Domaines · **Nomenclature** · **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.
|
||
|
||
**Les formulaires sont GÉNÉRÉS.** Depuis le 2026-09-08, **les six registres** — serveurs,
|
||
applications, bases de données, serveurs de BD, domaines et nomenclature — ne portent plus de
|
||
formulaire écrit à la main : ils le construisent depuis `docs/audit/schema-plan.json`, lui-même
|
||
dérivé des constantes du moteur (`make schema`). Un champ ajouté au plan apparaît donc à l'écran
|
||
**sans qu'on touche à l'interface** — et il arrive au fichier, parce que la sauvegarde dérive du
|
||
même schéma. Ouvrir une vue et enregistrer sans rien toucher renvoie **exactement** le plan qu'on
|
||
vient de lire ; c'est mesuré à chaque `make prouver`.
|
||
|
||
Deux champs gardent volontairement leur propre éditeur, et le schéma le déclare : la **matrice des
|
||
intégrations** (elle montre aussi les universelles, non décochables, et les exemptions) et
|
||
l'**éditeur de liens** (il contraint le rôle à ce que `meta/liens.yml` accepte). Le générateur
|
||
s'efface plutôt que de remplacer un éditeur qui en sait plus que lui.
|
||
|
||
Deux preuves tiennent le schéma : **P61** refuse qu'un champ des plans réels
|
||
manque au schéma, ou que le schéma décrive une *forme* que les plans n'ont pas ; **P62** refuse
|
||
qu'un champ accepté par les *validateurs du moteur* manque au schéma — sans quoi le formulaire ne
|
||
saurait pas offrir une fonctionnalité que Set-OPS possède déjà.
|
||
|
||
**Sauvegarder n'efface plus les commentaires du plan.** Les registres portent la mémoire écrite des
|
||
décisions — pourquoi `backup-01` a été retiré, dans quel ordre les rôles du runner s'appliquent.
|
||
Jusqu'au 2026-09-08, chaque « Sauvegarder » en détruisait **quarante lignes**. Les quatre écrivains
|
||
passent désormais par une fusion ligne à ligne : un aller-retour sans modification laisse le
|
||
fichier **identique à l'octet**.
|
||
|
||
**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.
|
||
|
||
|
||
|
||
**Nomenclature** *(éditable)* — le **modèle** dont tout l'adressage dérive : zones de sécurité,
|
||
fonctions (catégorie · service), réservations. Chaque fonction montre **ce qu'elle dérive** — zone,
|
||
VLAN, sous-réseau, bloc d'hôtes — et les VM qui la portent ; on ne retire pas une fonction encore
|
||
portée. L'`index` y est **affiché mais pas éditable** : il est *alloué par le site*, pas décidé par
|
||
le tenant (cf. l'en-tête de `plan/nomenclature.yml`), et s'édite depuis le panneau **Intrants**.
|
||
|
||
**Applications** *(éditable)* — catalogue des applis, éditeur (rôle · hôte · port · FQDN exposé),
|
||
relations déclaratives (requiert · liens · bases), dépendances causales.
|
||
|
||
|
||
|
||
**Bases — serveur** *(éditable)* — les moteurs SGBD et les bases applicatives « nom @ serveur »,
|
||
avec les bases hébergées sur chaque serveur.
|
||
|
||
|
||
|
||
**Bases — fiche** *(éditable)* — portée · consommateur · serveur, **secret Vault** (jamais en clair,
|
||
un pointeur seulement) et le **DSN dérivé** (secret masqué).
|
||
|
||
|
||
|
||
**Domaines** *(éditable)* — zones DNS publique vs interne, autorité · edge · DNSSEC, expositions.
|
||
|
||
|
||
|
||
**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).
|
||
|
||
|
||
|
||
**Couches** *(dérivée)* — l'**ordre de déploiement** en 6 couches, du socle aux agents ; celui que
|
||
`make deployer-tout` déroule.
|
||
|
||
|
||
|
||
**Réseau** *(dérivée)* — la **flotte multi-instances** : adressage dérivé du seed, bascule
|
||
d'instance, devis de configuration des switches.
|
||
|
||
|
||
|
||
> 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.
|
||
|
||
---
|
||
|
||
### La vue **Assistants** — l'ordre des gestes, pas seulement les gestes
|
||
|
||
Les huit autres vues éditent le **plan**. Celle-ci conduit des **gestes**, et elle répond à un
|
||
trou précis : le `Makefile` porte **132 cibles documentées** qui disent chacune *ce qu'elle
|
||
fait*, et **aucune ne dit dans quel ordre**. Un exploitant devant un site neuf n'avait aucun
|
||
moyen d'apprendre, depuis la console, que `site-creer` précède `forge-amorcer`, que le premier
|
||
passage **s'arrête** sur une forge vide, ni que rien n'est « prêt » avant `valider`. Cette
|
||
connaissance vivait en prose dans les documents ; la console offrait des boutons sans séquence.
|
||
|
||
**Dix-sept assistants, 126 étapes, et la totalité des 132 cibles.** Chaque cible documentée est
|
||
soit portée par un assistant, soit **exemptée avec son motif** — et `P83` refuse qu'une cible
|
||
échappe aux deux. Sans cette garde, la console cacherait un pouvoir que le moteur possède.
|
||
|
||
**Le registre ne recopie pas le Makefile.** `docs/runbooks-construction.yml` déclare seulement
|
||
ce que le Makefile ne peut pas porter : l'**ordre**, la **nature** du geste, la **portée** et le
|
||
**pourquoi**. Le libellé de chaque étape est *lu dans le Makefile au moment de servir*. Une
|
||
cible renommée se voit donc immédiatement, elle ne s'invente pas — c'est la règle « une liste
|
||
qui suit une autre prend du retard », et la garde est écrite **en même temps** que la liste.
|
||
|
||
**Trois natures, trois comportements** :
|
||
|
||
| Nature | Ce que la console fait |
|
||
|---|---|
|
||
| `mesure` | n'écrit rien ; **toujours offerte**, même après un échec — mesurer pour comprendre est exactement ce qu'on fait ensuite |
|
||
| `écriture` | exige que l'étape précédente **non facultative** ait réussi ; sinon on bâtit sur un terrain non vérifié |
|
||
| `destructif` | exige d'**écrire `DETRUIRE`**, en plus du `CONFIRMER=true` que la cible réclame déjà |
|
||
|
||
**Le navigateur ne nomme pas une commande, il nomme une place.** `/api/runbook-etape` ne lance
|
||
jamais « la cible que la page demande » : il lance ce que le registre déclare **à cet index-là**,
|
||
avec les seules variables déclarées. Une page compromise — ou simplement périmée — ne peut donc
|
||
pas réclamer `raser` depuis un assistant de mesure. L'index compte : « Le premier jour d'un
|
||
site » lance `site-deployer-tout` **deux fois**, et les deux places n'ont pas le même sens.
|
||
|
||
**La portée décide, et elle se dérive.** Un assistant de site exige `materialiser`, un assistant
|
||
de locataire `configurer`, un assistant de poste **les deux**. Un assistant hors de portée reste
|
||
**visible et lisible** : savoir que le geste existe, et chez qui il se fait, fait partie du
|
||
métier. Ce qui est refusé, c'est de le lancer — et le refus dit sa raison.
|
||
|
||
---
|
||
|
||
## ③ 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).
|
||
- Les assistants : `docs/runbooks-construction.yml`, lus par `scripts/runbooks.py` (P83).
|
||
Vérifier le registre sans lancer la console : `python3 scripts/runbooks.py verifier`,
|
||
et le lire en texte : `python3 scripts/runbooks.py lister`.
|
||
- 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)**.
|