Daniel Allaire
6120e6f006
boites (dovecot) · cache-apt (artefacts) · certificat (client_pki, 14/14)
collaboration (nextcloud) · collecte (prometheus) · file-courriel (postfix)
forge (forgejo) · identite (keycloak) · ingestion (loki) · moteur (icinga)
resolution (resolveur) · runner (serveur_ops) · tableaux (grafana)
voute (ops_tenant) — toutes vertes, sans une ligne ecrite dans Icinga.
DEUX PRINCIPES QUE LA PREMIERE SONDE A IMPOSES.
Une sonde doit pouvoir etre mise en defaut PAR PARAMETRE : cible et seuils
sont des variables du role, on prouve le rouge avec un port ferme ou un
seuil impossible, sans rien casser. Et la sonde vit LA OU VIT LA VERITE :
« ce noeud est-il collecte ? » appartient a prometheus, pas au client —
une seule y voit les N noeuds, et surtout elle voit le cas SILENCIEUX.
ON DEMANDE AU SERVICE CE QU IL PENSE DE LUI-MEME quand il sait le dire
(healthz, /ready, status.php, decouverte OIDC). Quand il ne sait pas, on
va chercher la verite de terrain : « moteur » ne regarde ni le service ni
le port, il demande a la base depuis combien de temps elle n a pas ete
rafraichie — la lecon des sauvegardes appliquee a la supervision.
QUATRE FOIS J AI ECRIT LA SONDE AVANT DE MESURER, QUATRE FOIS ELLE A EU
TORT. La forge : port et chemin des depots inventes, elle ecoute en 3000
derriere l edge et n a legitimement aucun depot. Loki : « panne
persistante » conclue sur deux lectures a quelques secondes d intervalle
juste apres un redemarrage — deux mesures rapprochees ne distinguent pas
un etat d un instant. Keycloak : vise en 8443, il ecoute en 8080. Le
runner : git en root refuse un depot d un autre proprietaire. A chaque
fois le remede est le meme — lire la verite du role, ne pas la supposer.
Et le meme piege Jinja qu avec client_sante : ${#tableau[@]} contient {#.
Le remede etait deja au depot ; je l ai reecrit au lieu de le chercher.
RESTE : client_smtp, client_artefacts, client_journal, icingaweb2 et
ops_site. Ce sont des chemins de report, dont la panne se voit deja par le
silence des sondes qu ils portent.
make prouver : CONFORME, 64 OK, 0 echec, 0 saute (P64 : 14 sondes).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
89 lines
5 KiB
YAML
89 lines
5 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
|
|
|
|
# --- ARMER LE RUNNER : LA CLE DE SA VOUTE ------------------------------------
|
|
#
|
|
# UN RUNNER MAITRE DE SA VOUTE (decision de l'exploitant, 2026-08-28). Deposer le chiffre
|
|
# sans la cle laisse un runner qui calcule son inventaire et ne peut rien en faire : chaque
|
|
# role reclamant un secret echoue sur son assertion, et l'echec ne dit pas qu'il manque un
|
|
# FICHIER — seulement que les valeurs sont vides.
|
|
#
|
|
# `false` PAR DEFAUT, ET CE N'EST PAS DE LA PRUDENCE DECORATIVE. Armer est un ACTE, pas un
|
|
# reglage : c'est le moment ou un humain remet la cle, et c'est le seul geste que la
|
|
# reproduction exige de lui (cf. docs/filiation-emancipation.md). Un defaut a `true`
|
|
# armerait des machines sans que personne ne l'ait decide.
|
|
#
|
|
# LA SOURCE EST UN POINTEUR, JAMAIS UNE VALEUR : le chemin du fichier de mot de passe sur
|
|
# le poste de l'exploitant. Il ne vit dans aucun depot, et rien ici n'en lit le contenu.
|
|
#
|
|
# DESTINATION : `<racine>/.config/setops-vault-<depot-en-minuscules>`, la meme convention
|
|
# que `scripts/voutes.py` — le runner derive donc sa propre liste d'identites sans qu'on
|
|
# ait a la lui ecrire. Hors de tout depot git, en 0600.
|
|
serveur_ops_tenant_cle_deposer: false
|
|
serveur_ops_tenant_cle_source: ""
|
|
serveur_ops_tenant_cle_destination: >-
|
|
{{ serveur_ops_tenant_racine }}/.config/setops-vault-{{ serveur_ops_tenant_depot | lower }}
|
|
|
|
# --- Sonde de supervision -----------------------------------------------------------
|
|
# Le chemin ou le RUNNER lit la voute de son ecosysteme.
|
|
# LE DEPOT VIENT DU ROLE, PAS D'UNE SUPPOSITION : `serveur_ops_tenant_depot` designe
|
|
# deja le dossier clone sur le runner.
|
|
serveur_ops_tenant_sonde_depot: "{{ serveur_ops_tenant_depot }}"
|
|
serveur_ops_tenant_sonde_voute: >-
|
|
/opt/setops/{{ serveur_ops_tenant_sonde_depot }}/inventories/principal/group_vars/all/vault.yml
|