Daniel Allaire
935a64a1bf
En voulant generer deux formulaires de plus, j ai trouve pire que ce que
je cherchais.
CE QUI ETAIT DEJA LA. Les quatre ecrivains de registre ecrasaient le
fichier au safe_dump. Mesure sur les fichiers reels : domaines.yml 6->3,
applications.yml 27->5, serveurs.yml 18->3. Quarante lignes, detruites
par n importe quel clic sur Sauvegarder dans les vues Serveurs,
Applications ou Domaines. Parmi elles, celle qui explique pourquoi
backup-01 a ete retire, et celle qui dit dans quel ordre les deux roles
du runner s appliquent. C etait l incident du 2026-08-18, jamais corrige
pour les registres du plan. Les quatre passent par _ecrire_registre :
aller-retour a vide identique a l octet, sur les quatre fichiers.
TROIS ECARTS DE SCHEMA, trouves en confrontant le schema aux VALIDATEURS
et non aux seuls plans :
- edge designe un GROUPE, pas un hote. Le schema disait serveurs : un
formulaire genere aurait offert une valeur qu aucun hote ne reconnait,
donc aucun SAN, donc la panne du 2026-08-25 reintroduite ;
- exposition, entierement valide par le moteur, manquait au schema ;
- liens etait items: {type: object} — une liste d objets sans forme.
Et mail, offert par la vue Domaines depuis sa creation, decrit ici comme
un booleen, saisi la-bas comme du texte, lu par rien : retire.
P62 garde tout ca. Elle separe l entite du reste mecaniquement : un
validateur lit son entite par des variables LOCALES, les autres registres
par ses PARAMETRES. Controle negatif rejoue.
LES FORMULAIRES. Serveurs de BD et Domaines sont generes, chargement et
sauvegarde compris. Quatre registres sur six. Le generateur a appris la
liste d objets.
LIMITE : restent serveurs et applications, les deux plus gros ; et je n ai
toujours pas ouvert ces pages dans un navigateur.
make prouver : CONFORME, 61 OK, 0 echec, 1 saute (62 preuves).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
163 lines
8.8 KiB
Markdown
163 lines
8.8 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, quatre registres sur six — **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**. Deux preuves le tiennent : **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.
|
||
|
||
---
|
||
|
||
## ③ 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)**.
|