Daniel Allaire
36b6926e21
Ses machines sont detruites. Le depot en parlait comme d un ecosysteme vivant, et l une de ces phrases datait de la veille : positionnement.md comptait ses 5 VM dans la flotte, chiffre que j avais moi-meme ecrit en revisant. CE QUI EST CORRIGE positionnement.md 51 VM sur quatre plans vivants, et non 56 sur cinq sortir-les-cles-du-poste le genome est replique DEUX fois, non trois wiki/Glossaire.md SQLite : ce qu il PORTAIT filiation-emancipation la famille de pairs a perdu un pair decisions-architecture D-83 consigne le retrait, avec son cout carte-set-ops.md 80 decisions en vigueur LE COUT, PARCE QU IL N ETAIT NOMME NULLE PART D-82 lui avait laisse deux raisons d etre : la mise en oeuvre de reference du modele origine, et un TEMOIN de plus du genome. Le retrait solde la premiere et abaisse la seconde de trois copies vivantes a deux. Or c est le raisonnement de son propre README qui portait tout : on n echappe pas a la boucle par la ruse, mais par le NOMBRE. Le nombre a baisse. Et le point unique de defaillance que patient 0 existait pour eliminer — eregion, hors flotte, que Set-OPS ne deploie ni ne sauvegarde ni ne prouve — est toujours a la racine. Il n a jamais ete elimine, seulement promu ; il n y a maintenant plus de miroir independant pour l absorber. CE QUI RESTE SUR LE TERRAIN, ET QUI N EST PAS DE LA PROSE Son plan est encore sur disque en federe: true. La federation lui reserve donc toujours l index 29, la zone SDN t29, ses VNets, les VLAN 1291-1296 et les sous-reseaux 10.29.16-21.0/24. Quatre machines du site — backup, cache, dns, forge — acceptent encore SSH, apt, DNS et HTTPS depuis 10.29.0.0/16 : un perimetre vide. Le runner du site clone encore ops-patient0. C est un geste, pas une intention, et il touche le reseau : il n est pas fait ici. La sequence est listee dans D-83. make prouver --verifier : CONFORME, 56 OK, 0 echec, 1 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
103 lines
5.7 KiB
Markdown
103 lines
5.7 KiB
Markdown
# Positionnement : ce que Set-OPS fait maison, et quand adopter l'existant
|
|
|
|
> **Pour qui :** le **mainteneur**, et quiconque arbitre une évolution : ce qui reste maison, et à quel seuil on adopte l'existant.
|
|
|
|
Ce document **acte une décision** pour ne plus la redébattre à chaque évolution :
|
|
quelles parties de Set-OPS sont volontairement *maison*, pourquoi, et à partir de
|
|
quel **seuil** il vaudra mieux adopter un outil du marché plutôt que continuer à
|
|
le réimplémenter.
|
|
|
|
> En une phrase : le cœur de Set-OPS (un plan déclaratif qui génère l'inventaire
|
|
> Ansible) **existe déjà sous forme mûre** — c'est NetBox. Set-OPS en est une
|
|
> version **souveraine, légère et sur-mesure**, assumée comme telle. Le risque à
|
|
> surveiller est de réimplémenter NetBox/AWX brique par brique.
|
|
|
|
---
|
|
|
|
## 1. La carte : chaque facette a un équivalent du marché
|
|
|
|
| Facette de Set-OPS | Équivalent mûr | Remarque |
|
|
| --- | --- | --- |
|
|
| Source de vérité déclarative → **génère l'inventaire Ansible** | **NetBox** / **Nautobot** + plugin `netbox.netbox.nb_inventory` | Le plus proche du **cœur** de Set-OPS (le « plan »). |
|
|
| GUI qui **exécute** Ansible (déployer, RBAC, planification) | **AWX** / Ansible Automation Platform ; **Semaphore** | Set-OPS a un GUI plus modeste (lancer `make`). |
|
|
| « La **définition instancie** toute la flotte » | **NixOS + Colmena/morph** ; **Terraform** (provider Proxmox) pour créer les VM | L'idée « méta-classe » au sens littéral. |
|
|
| **Application = entité pivot** avec ses dépendances et ressources | **Backstage** (catalogue de composants + graphe) | Le modèle `requiert`/`utilise`/`expose` y ressemble fortement. |
|
|
| IPAM / dérivation d'adressage | **NetBox** (IPAM natif) | Set-OPS dérive depuis la nomenclature. |
|
|
|
|
**Aucun** produit ne fait l'**assemblage exact** : Proxmox + Ansible + le modèle
|
|
bespoke (DSN, exposition DNS, dérivation par fonction) en **un seul outil
|
|
souverain et léger**. Cet assemblage-là est propre à Set-OPS.
|
|
|
|
---
|
|
|
|
## 2. Ce que Set-OPS fait sciemment maison (et pourquoi)
|
|
|
|
- **Le plan déclaratif** (`instance/plan/serveurs.yml`, `applications.yml`, `bases-donnees.yml`,
|
|
`domaines.yml`, `nomenclature.yml`) et le **générateur d'inventaire** (`make instancier`).
|
|
- Le **modèle application-hub** : bindings DSN (portée application/groupe/hôte) et
|
|
exposition DNS, taillés exactement pour nos concepts.
|
|
- Le **GUI** (Python stdlib, fichier unique) et les **validateurs / garde-fous**
|
|
(diff-vide, `node --check`, vérificateurs de registres).
|
|
|
|
Raisons assumées :
|
|
|
|
1. **Souveraineté** — mission explicite du dépôt. NetBox + AWX + Backstage = trois
|
|
applications lourdes à héberger et maintenir (Django + PostgreSQL, etc.). Set-OPS
|
|
reste possédé en entier, sans dépendance.
|
|
2. **Bon dimensionnement** — mais l'argument a bougé, et il faut le dire honnêtement.
|
|
Ce document a longtemps écrit « ~13 VM ». Le moteur pilote aujourd'hui **quatre plans
|
|
vivants** (mesuré le 2026-09-06) : Chezlepro 14 VM, Technolibre 15, le lab 15, plus les
|
|
7 machines du site — **51 VM déclarées**, réparties sur des écosystèmes qui ne se parlent
|
|
pas. *(Patient 0 en portait 5 ; ses machines n'existent plus.)* Ça reste très loin de l'échelle entreprise pour laquelle NetBox est fait,
|
|
et le seuil du §4 n'est pas franchi. Mais la courbe monte : c'est **le** chiffre à
|
|
regarder quand on se demande si la décision tient encore.
|
|
3. **Modèle sur-mesure** — NetBox exprimerait nos DSN / expositions à coups de
|
|
*custom fields* et de plugins, moins naturellement que nos registres.
|
|
4. **Maîtrise** — chaque ligne est comprise et auditable.
|
|
|
|
---
|
|
|
|
## 3. Ce que le maison NE fait PAS (et que les outils mûrs ont)
|
|
|
|
À garder en tête honnêtement — ce sont des fonctions qu'on n'a pas, pas des bugs :
|
|
|
|
- historique/audit des changements (au-delà de `git`) ;
|
|
- RBAC multi-utilisateurs ;
|
|
- détection de conflits IPAM, réservations, gestion d'adresses à grande échelle ;
|
|
- webhooks / intégrations tierces, API riche (REST/GraphQL) ;
|
|
- écosystème de plugins, communauté, correctifs de sécurité maintenus par d'autres.
|
|
|
|
---
|
|
|
|
## 4. La règle : plan de contrôle **gelé en fonctionnalités**
|
|
|
|
Set-OPS continue d'évoluer pour **décrire et déployer l'écosystème** (rôles,
|
|
services, registres applicatifs). En revanche, le **plan de contrôle** (le GUI,
|
|
le générateur, l'IPAM, la modélisation) est considéré **gelé en périmètre** : on
|
|
ne lui ajoute pas de fonctionnalités de type NetBox/AWX.
|
|
|
|
### Seuils d'adoption (les signaux de bascule)
|
|
|
|
Adopter l'outil du marché — **sans réécrire**, en branchant Ansible/notre GUI
|
|
par-dessus — dès qu'un de ces besoins devient réel :
|
|
|
|
| Besoin qui apparaît | Adopter |
|
|
| --- | --- |
|
|
| RBAC, plusieurs opérateurs, historique d'audit, secrets/credentials centralisés | **AWX** (exécution) |
|
|
| IPAM sérieux, détection de conflits, source de vérité partagée, API/webhooks | **NetBox** (et `nb_inventory` remplace notre générateur) |
|
|
| Catalogue de services / portail développeur, ownership, scaffolding | **Backstage** |
|
|
| Provisionnement de VM déclaratif et reproductible à plus grande échelle | **Terraform** (Proxmox) ou **NixOS + Colmena** |
|
|
|
|
**Test simple** : si on se surprend à vouloir réimplémenter une de ces fonctions
|
|
dans Set-OPS, c'est le signal d'adopter l'outil correspondant plutôt que de
|
|
prolonger le maison.
|
|
|
|
---
|
|
|
|
## 5. Décision en vigueur
|
|
|
|
- On **garde** le plan de contrôle maison : il fonctionne, il est souverain et
|
|
bien dimensionné pour aujourd'hui. Pas de réécriture sur NetBox « par principe ».
|
|
- On **gèle** son périmètre fonctionnel (voir §4).
|
|
- On **réévalue** à l'échéance d'un seuil ci-dessus, ou si la charge de
|
|
maintenance du maison dépasse le coût d'héberger l'outil mûr.
|