Set-OPS-Public/roles/serveur_ops_tenant

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/hebergement/implanter-un-tenant-sur-un-site.md — la séquence complète