L'inventaire (hotes generes, group_vars, vault) quitte inventories/ pour instance/inventories/. Suivent : ansible.cfg, Makefile (export SETOPS_INSTANCE ?= instance + chemins derives), scripts (INSTANCE/), config_proxmox.py, .gitignore. Docs primaires (AGENTS/README/ plan-et-generation/architecture) refletent le layout instance/. Non destructif : diff vide, ansible-lint 0 echec, make inventaire-verifier OK. (Docs secondaires a rafraichir ; Phase 3 : deux depots.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.3 KiB
Architecture Set-OPS
Set-OPS définit et construit l'écosystème numérique souverain de Chezlepro. 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.
- 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
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 :
instance/inventories/production/hosts.yml
serveur_debian
playbooks/groupes/serveur_debian.yml
Cette relation rend l'exploitation lisible :
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 Chezlepro est documenté dans :
docs/vm-lifecycle.md
Intégrations futures
Les intégrations transversales des VM sont documentées dans :
docs/integrations-vm.md