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 · Intrants | Flux · Couches · Réseau (flotte + devis) |
Le flux d'exploitation, de bout en bout :
- Éditer une vue du plan → Sauvegarder ;
- « Appliquer le plan » → régénère l'inventaire (VMID/IP/VLAN dérivés) ;
- Vérifier (dry-run) sur un hôte → prévisualise sans rien changer ;
- Déployer → applique les rôles (confirmation renforcée si l'instance est en PROD) ;
- 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.
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.
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
.mddu 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
- 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 ». - É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.
- 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. - Bascule d'instance. Vue Réseau, bouton « Activer » sur une autre instance. Toutes les vues suivent, sans redémarrer.
- 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.
- 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.
- La flotte : unité Multi-instance & fédération.