Set-OPS-Public/roles/serveur_ops_tenant
Daniel Allaire 6120e6f006 sondes : quatorze, une par role, derivees en objets Icinga
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
2026-09-10 03:00:21 -04:00
..
defaults sondes : quatorze, une par role, derivees en objets Icinga 2026-09-10 03:00:21 -04:00
meta sondes : quatorze, une par role, derivees en objets Icinga 2026-09-10 03:00:21 -04:00
tasks sondes : quatorze, une par role, derivees en objets Icinga 2026-09-10 03:00:21 -04:00
templates sondes : quatorze, une par role, derivees en objets Icinga 2026-09-10 03:00:21 -04:00
README.md runner : serveur_ops_tenant — le runner d'un tenant recoit enfin sa voute 2026-08-26 15:30:51 -04:00

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