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>
58 lines
3.2 KiB
YAML
58 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
|