Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
71 lines
2.7 KiB
Markdown
71 lines
2.7 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/<inventaire>/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/<inventaire>/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 transversales
|
|
|
|
Elles ne sont plus « futures » : `client_pki`, `client_backup`, `client_metrique`,
|
|
`client_journal`, `client_smtp`, `client_resolveur` et `client_artefacts` sont déployés sur
|
|
la flotte. Elles sont documentées dans :
|
|
|
|
```text
|
|
docs/integrations-vm.md
|
|
```
|