Archived

This repository has been archived on 2026-06-26. You can view files and clone it, but cannot push or open issues or pull requests.

Daniel Allaire b775b7f99d Neutraliser le moteur pour partage public (100% neutre)

Suppression de toute trace Chezlepro de l'outil (roles, scripts, docs
publiques, exemples, LICENSE). Prouve par scan exhaustif : git grep vide
pour chezlepro, asgard/TrueNAS, supernet reel 10.1.x.

Corrige 5 defauts de genericite fonctionnels (motd, app.ini Forgejo,
organisation openldap, nom AC step-ca, et IP reelles codees en dur dans
les defaults de roles -> plage d'exemple 10.0.x). LICENSE -> Alliance
Boreale. Fichiers mainteneur + CHANGELOG conserves (par decision).

La separation moteur/instance tient : OPS-Chezlepro surcharge deja ses
vraies valeurs de topologie. Verifie : make verifier exit 0 (4 tests).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-24 19:58:00 -04:00

2.3 KiB

Raw Permalink Blame History

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.

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 est documenté dans :

docs/vm-lifecycle.md

Intégrations futures

Les intégrations transversales des VM sont documentées dans :

docs/integrations-vm.md

2.3 KiB Raw Permalink Blame History