Daniel Allaire
45aaf2808d
La separation faite, la distribution devient sure. `serveur_ops_site` et `serveur_ops_tenant` deposent desormais LA CLE de la voute qu'ils deposaient deja chiffree. Le runner du site l'a recue : une seule cle chez lui, en 0600, et il ouvre sa voute tout seul. La fabric, pas un tenant. `false` PAR DEFAUT, ET CE N'EST PAS DECORATIF. Armer est le moment ou un humain remet la cle — le seul geste que la reproduction exige de lui. Un defaut a `true` armerait des machines sans que personne ne l'ait decide. Les deux roles exigent une declaration au plan et refusent d'armer sans qu'on dise AVEC QUELLE cle : poser un fichier vide laisserait un runner se croire arme. ECRIRE PUIS RELIRE, contre la faute SYMETRIQUE de celle de la voute : la on craignait un chiffre devenu clair, ici on craint une cle qui serait une voute, ou vide — Ansible accepte un mot de passe vide et n'ouvre rien. Existence, taille et mode mesures apres ecriture. CE QUE CA CHANGE : le mot de passe se tapait a chaque deploiement. Un geste repete vingt fois par semaine ne prouve rien, et il rendait tout deploiement non interactif impossible sans blocage. Il se remet une fois, et c'est un evenement. P32 A TROUVE LA MOITIE MANQUANTE : le role du tenant exigeait `serveur_ops_tenant_cle_source`, absente du plan de Chezlepro. Dit avant tout deploiement, dans les bons termes. make verifier : vert. make prouver : CONFORME, 52 OK, 0 echec, 0 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on |
||
|---|---|---|
| .. | ||
| 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