Daniel Allaire
a8bea83a91
Après audit du dépôt : docs/carte-set-ops.md = point d'entrée « à lire d'abord » (index du corpus) + catalogue des mécanismes transverses (2 directions de binding, pont de cert, résolution BD par registre, socle-first, check-mode, voûte) avec où ils vivent. But : ne plus re-découvrir l'existant. Constat : la cruft était déjà inventoriée dans catalogue-services.md (rôles-catégories inertes, échafaudages) — référencée, pas dupliquée. catalogue-services « État d'implémentation » rafraîchi (rôles éprouvés sur VM réelles : socle, PKI, LDAP, DNS, nginx, pile courriel). Pointeur ajouté depuis architecture-set-ops.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
67 lines
2.4 KiB
Markdown
67 lines
2.4 KiB
Markdown
# Architecture Set-OPS
|
|
|
|
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
|
|
```
|