Daniel Allaire
8890c997af
Some checks are pending
verifier / verifier (push) Waiting to run
La doctrine des runners decrit trois portees depuis le 2026-08-22 : calculer plan -> inventaire aucune voute serveur_ops configurer roles sur ses machines voute du TENANT <- revendiquee, jamais recue materialiser creer/detruire des VM voute du SITE serveur_ops_site La deuxieme ligne etait un trou. RIEN ne deposait jamais la voute d'un tenant sur son runner. Un runner pouvait deriver son inventaire et ne rien pouvoir en faire : chaque role qui demande un secret echouait sur son assertion, et l'echec ne disait pas qu'il manquait un FICHIER, seulement que les valeurs etaient vides. Decouvert en preparant la reconstruction de Chezlepro. Le runner du SITE peut materialiser ses quinze machines ; il ne peut pas les configurer, parce que Chezlepro a sa PROPRE autorite de certification — donc `client_pki` y reclame un secret de Chezlepro. Le runner du site ne l'a pas, et NE DOIT PAS l'avoir : c'est la ligne qui rend l'hebergement mutualise defendable. `serveur_ops_tenant` est le symetrique exact de `serveur_ops_site` : un MARQUEUR, pas un installateur. Il depose la voute `decrypt: false`, puis RELIT l'en-tete du fichier depose — une voute dechiffree par accident est une fuite silencieuse. Le dossier d'inventaire (`principal` ou `production`) se DECOUVRE sur la machine plutot que d'etre ecrit. Pourquoi un role a part et non une option de `serveur_ops` : donner sa voute a un runner est un POUVOIR, pas un reglage. Le declarer au plan force a repondre a « cette machine a-t-elle le droit de configurer cet ecosysteme ? » — une option activee par defaut y repondrait a notre place. CHEZLEPRO LISAIT ENCORE SON GENOME CHEZ PATIENT 0. Trouve au passage, et bloquant pour la reconstruction : `serveur_ops_forge_amont` pointait sur `10.29.16.11` — la forge de patient 0, l'amont d'avant que le site ait la sienne. D-81 a tranche depuis. Laisse tel quel, Chezlepro se serait reconstruit depuis un moteur perime, sur un reseau que le decoupage en zones a de toute facon deplace. Corrige vers la forge du site, PAR SON IP — `forge.genese.internal` appartient a la zone souveraine du site, et un tenant ne resout que la sienne ; le certificat SERVI porte bien `IP Address:10.0.33.11`. La racine de l'AC du site est desormais versionnee a cote de la carte de la fabric a laquelle elle appartient, et son chemin se DERIVE du symlink `underlay.yml` : il vaut depuis le poste comme depuis un runner. Le role est inscrit dans les quatre registres qui l'exigeaient — couches de deploiement, graphe des dependances, catalogue des services, carte d'orientation. Ce sont les preuves P08, P38 et P48 qui l'ont reclame, chacune a son tour. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| defaults | ||
| meta | ||
| tasks | ||
| README.md | ||
serveur_ops_tenant — donner à un runner la voûte de SON écosystème
Pour qui : l'exploitant qui monte le runner d'un tenant.
Marqueur, pas installateur. serveur_ops installe le poste — Ansible, les collections, les
dépôts du génome, les symlinks. Ce rôle-ci y ajoute un pouvoir : la voûte de
l'écosystème, déposée chiffrée, sans laquelle le runner peut tout calculer et ne rien
configurer.
Les trois portées d'un runner
calculer plan → inventaire aucune voûte serveur_ops
configurer rôles sur ses machines voûte du TENANT serveur_ops_tenant
matérialiser créer/détruire des VM voûte du SITE serveur_ops_site
Aucun runner n'est omnipotent. Le runner d'un site matérialise le terrain et n'entre jamais chez un tenant ; le runner d'un tenant configure son écosystème et ne touche jamais la fabric.
Pourquoi un rôle à part
Donner sa voûte à un runner est un pouvoir, pas un réglage. Le déclarer au plan force à répondre à « cette machine a-t-elle le droit de configurer cet écosystème ? » — une option activée par défaut y répondrait à notre place.
Ce qu'il exige
| Variable | Ce que c'est |
|---|---|
serveur_ops_tenant_depot |
le dossier de cet écosystème chez le runner ; vaut serveur_ops_instance par défaut |
serveur_ops_tenant_voute_source |
le chemin du vault.yml sur le contrôleur |
Le dossier d'inventaire (principal ou production) se découvre sur la machine : il
n'est écrit nulle part.
Ce qu'il garantit
decrypt: false sur la copie, puis relecture de l'en-tête du fichier déposé. Une voûte
déchiffrée par accident est une fuite silencieuse — le fichier existe, le rôle se dirait
satisfait, et les secrets dormiraient en clair sur une machine. Le rôle refuse plutôt.
Voir aussi
roles/serveur_ops/README.md— l'installateurroles/serveur_ops_site/README.md— le pouvoir symétrique, côté fabricdocs/implanter-un-tenant-sur-un-site.md— la séquence complète