Daniel Allaire
ac85278366
La refonte de ce matin posait une convention. Une convention qu'on n'outille pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique au corpus documentaire. Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32 autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus utile du depot au §6 de autorisation.md. Les 38 le declarent desormais, lecteur determine document par document et non colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie, gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE). Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la premiere page ajoutee : un document qui s'annonce genere, et un fragment sans titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation dans leur corps — d'etre exemptes a tort. Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en nommant deux documents que mon inventaire avait manques (docs/audit/). Puis test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la nommant ; restauree -> OK. Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en revue ; elle garantit qu'on a du y penser. P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md annoncaient encore 30 preuves). Verifie : prouver.py 0 (34 OK), plan-recette inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
69 lines
2.5 KiB
Markdown
69 lines
2.5 KiB
Markdown
# Architecture Set-OPS
|
|
|
|
> **Pour qui :** le **mainteneur** — le survol du modèle. À lire avant `plan-et-generation.md`.
|
|
|
|
Set-OPS définit et construit l'écosystème numérique souverain. Il se
|
|
pilote par un **plan** : l'inventaire Ansible (`instance/inventories/production/hosts.yml`)
|
|
est **généré** depuis le plan, pas édité à la main.
|
|
|
|
- **Par où commencer + catalogue des mécanismes transverses : `docs/carte-set-ops.md`.**
|
|
- Modèle, registres, commandes et flux de travail : **`docs/plan-et-generation.md`**.
|
|
- Règles d'autorité : **`AGENTS.md`** (sections « Mission et identité » et « Le plan et la génération de l'inventaire »).
|
|
|
|
## Entités du plan
|
|
|
|
```text
|
|
serveur (VM) instance/plan/serveurs.yml fonction, état, placement, intégrations
|
|
application instance/plan/applications.yml groupe (rôle), hôte, port, requiert, expose
|
|
base instance/plan/bases-donnees.yml serveur de BD, base, propriétaire, secret (Vault), portée
|
|
domaine (DNS) instance/plan/domaines.yml zone publique, autorité, edge
|
|
nomenclature instance/plan/nomenclature.yml fonctions -> VMID / VLAN / IP (dérivés)
|
|
```
|
|
|
|
L'**application** est l'entité pivot ; le **groupe** Ansible n'est qu'une capacité
|
|
(le rôle appliqué). VMID / IP / VLAN et les appartenances de groupes sont **dérivés**.
|
|
|
|
## Rôles Ansible
|
|
|
|
Les rôles actifs sont conservés directement sous `roles/`.
|
|
|
|
Les sous-arborescences catégorielles de rôles ne doivent pas dupliquer un rôle actif. Un nouveau rôle doit être ajouté seulement lorsqu'un besoin opérationnel réel existe.
|
|
|
|
Les valeurs communes aux rôles doivent rester dans les defaults des rôles quand elles sont valables pour tous les environnements. Les inventaires ne doivent contenir que les politiques propres à leur contexte.
|
|
|
|
## Groupes et playbooks
|
|
|
|
Les groupes opérationnels de l'inventaire doivent correspondre à un playbook homonyme :
|
|
|
|
```text
|
|
instance/inventories/production/hosts.yml
|
|
serveur_debian
|
|
|
|
playbooks/groupes/serveur_debian.yml
|
|
```
|
|
|
|
Cette relation rend l'exploitation lisible :
|
|
|
|
```text
|
|
appartenance à un groupe
|
|
→ playbook correspondant
|
|
→ état voulu appliqué par Ansible
|
|
```
|
|
|
|
Les groupes structurels ou vides peuvent exister, mais un groupe assigné à une VM de production doit avoir un playbook s'il exprime une intention de configuration.
|
|
|
|
## Cycle de vie VM
|
|
|
|
Le cycle de vie des VM est documenté dans :
|
|
|
|
```text
|
|
docs/vm-lifecycle.md
|
|
```
|
|
|
|
## Intégrations futures
|
|
|
|
Les intégrations transversales des VM sont documentées dans :
|
|
|
|
```text
|
|
docs/integrations-vm.md
|
|
```
|