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>
48 lines
2 KiB
Markdown
48 lines
2 KiB
Markdown
# 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'installateur
|
|
- `roles/serveur_ops_site/README.md` — le pouvoir symétrique, côté fabric
|
|
- `docs/implanter-un-tenant-sur-un-site.md` — la séquence complète
|