59 lines
3.2 KiB
YAML
59 lines
3.2 KiB
YAML
|
---
|
||
|
|
# LE RUNNER D'UN TENANT — celui qui CONFIGURE.
|
||
|
|
#
|
||
|
|
# Le travail d'un runner se divise en trois portées, et chacune a son rôle :
|
||
|
|
#
|
||
|
|
# calculer plan -> inventaire aucune voûte `serveur_ops`
|
||
|
|
# configurer rôles sur ses machines voûte du TENANT CE RÔLE
|
||
|
|
# matérialiser créer/détruire des VM voûte du SITE `serveur_ops_site`
|
||
|
|
#
|
||
|
|
# CE QUI MANQUAIT (2026-08-26). La portée « configurer » était attribuée à `serveur_ops`
|
||
|
|
# dans la doctrine — mais rien ne déposait jamais la voûte du tenant sur son runner. Un
|
||
|
|
# runner pouvait donc dériver son inventaire et ne rien pouvoir en faire : chaque rôle qui
|
||
|
|
# demande un secret échouait sur son assertion, et l'échec ne disait pas qu'il manquait un
|
||
|
|
# FICHIER, seulement que les valeurs étaient vides.
|
||
|
|
#
|
||
|
|
# Découvert en préparant la reconstruction de Chezlepro : le runner du SITE peut
|
||
|
|
# matérialiser ses quinze machines, mais ne peut pas les configurer — Chezlepro a sa
|
||
|
|
# PROPRE autorité de certification, donc `client_pki` y réclame 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'hébergement mutualisé défendable.
|
||
|
|
#
|
||
|
|
# POURQUOI UN RÔLE À PART, et non une option de `serveur_ops`. Donner sa voûte à un runner
|
||
|
|
# est un POUVOIR, pas un réglage. Le déclarer explicitement au plan force à répondre à la
|
||
|
|
# question « cette machine a-t-elle le droit de configurer cet écosystème ? » — alors
|
||
|
|
# qu'une option activée par défaut y répondrait à notre place. C'est le même patron que
|
||
|
|
# `serveur_artefacts` + `serveur_cache_site` : un installateur, puis un marqueur qui
|
||
|
|
# ajoute un pouvoir.
|
||
|
|
#
|
||
|
|
# QUI PEUT LE DÉCLARER : l'écosystème lui-même, pour SA machine. Un runner de SITE ne le
|
||
|
|
# déclare jamais — il porte les plans des tenants en `role: tenant` précisément pour dire
|
||
|
|
# qu'il prépare leur terrain sans les piloter.
|
||
|
|
|
||
|
|
serveur_ops_tenant_utilisateur: "setops"
|
||
|
|
serveur_ops_tenant_racine: "/opt/setops"
|
||
|
|
|
||
|
|
# Le dossier du dépôt de CET écosystème chez le runner, cloné par `serveur_ops`
|
||
|
|
# (entrée `role: instance` de `serveur_ops_depots`). Par défaut : celui que le lien
|
||
|
|
# `instance` désigne déjà — le pilote et sa voûte ne peuvent pas viser deux écosystèmes.
|
||
|
|
serveur_ops_tenant_depot: "{{ serveur_ops_instance | default('') }}"
|
||
|
|
|
||
|
|
# --- LA VOÛTE DU TENANT ------------------------------------------------------
|
||
|
|
#
|
||
|
|
# Déposée CHIFFRÉE, jamais en clair. Le mot de passe n'est pas stocké : l'exploitant le
|
||
|
|
# tape au moment d'agir.
|
||
|
|
#
|
||
|
|
# `decrypt: false` EST OBLIGATOIRE sur la copie. Sans lui, Ansible DÉCHIFFRE la source
|
||
|
|
# quand il détient le mot de passe — mesuré le 2026-08-24 sur la voûte du site, 776 octets
|
||
|
|
# en clair au lieu de 3465 chiffrés, sur une machine où ils n'avaient rien à faire.
|
||
|
|
serveur_ops_tenant_voute_source: ""
|
||
|
|
serveur_ops_tenant_voute_deposer: true
|
||
|
|
|
||
|
|
# LE DOSSIER D'INVENTAIRE SE DÉCOUVRE, il ne s'écrit pas. Le dépôt en connaît deux noms
|
||
|
|
# — `principal` et `production` — et l'ordre de préférence est celui de
|
||
|
|
# `inventory_rules.dossier_inventaire`. Écrire le nom en dur ici le ferait mentir pour
|
||
|
|
# l'écosystème qui emploie l'autre.
|
||
|
|
serveur_ops_tenant_inventaires_connus:
|
||
|
|
- principal
|
||
|
|
- production
|