Daniel Allaire
1832530f29
Ajout de meta/supervision.yml a six roles, chacun deposant sa propre sonde selon le contrat des greffons Nagios. DEUX PRINCIPES POSES AU DOCUMENT DE CONCEPTION, parce que la premiere sonde les a imposes : 1. UNE SONDE DOIT POUVOIR ETRE MISE EN DEFAUT PAR PARAMETRE. Cible et seuils sont des variables du role : on la prouve rouge avec un port ferme ou un seuil impossible, sur une machine reelle, sans rien casser, et aussi souvent qu on veut. Une sonde qu on ne peut prouver qu en cassant un service ne sera prouvee qu une fois. 2. LA SONDE VIT LA OU VIT LA VERITE. « Ce noeud est-il collecte ? » est une sonde de serveur_prometheus, pas de client_metrique : une seule y voit les N noeuds, et surtout elle voit le cas SILENCIEUX — celui qui a cesse d etre collecte ne peut pas s en plaindre. LES SIX : cache-apt (artefacts, repond + place), resolution (resolveur, zone interne ET Internet — deux chemins distincts), forge (forgejo, son propre /api/healthz), collecte (prometheus, 15/15 cibles), tableaux (grafana, base ok), ingestion (loki, PRET a ingerer, pas seulement en ecoute). TROIS FOIS J AI ECRIT LA SONDE AVANT DE MESURER, ET TROIS FOIS ELLE A EU TORT. La forge : port 443 et chemin des depots INVENTES — elle ecoute en 3000 derriere l edge et n a legitimement aucun depot. Loki : j ai conclu « panne persistante » sur deux lectures prises a quelques secondes d intervalle, juste apres un redemarrage ; l anneau etait ACTIVE et la reponse est passee a ready moins d une minute plus tard. Le delai de stabilisation est desormais un AVERTISSEMENT nomme, pas une panne. On demande au service ce qu il pense de lui-meme quand il sait le dire (healthz, /ready, /api/health) plutot que d inventer un critere de l exterieur. make prouver : CONFORME. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q |
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| README.md | ||
serveur_resolveur
Le résolveur de l'écosystème : un seul Unbound pour tout le tenant, récursif depuis les serveurs racine, qui délègue la zone souveraine à PowerDNS.
Pourquoi un seul, et pourquoi ici
Avant le 2026-08-24, client_unbound posait un Unbound sur chaque VM. Ça marchait et
c'était parfaitement étanche — mais c'était N démons identiques pour un service unique.
Mesure prise avant de décider : ~21 Mo de RSS par VM, et 28 à 189 requêtes servies depuis le démarrage. Le gain de cache mutualisé est donc négligeable ; ce qu'on récupère, c'est un démon au lieu de quatorze, et un endroit à regarder au lieu de quatorze.
Pourquoi pas sur la frontière
Un résolveur partagé par tout le SITE — l'OPNsense — aurait été le geste le plus économe. Il devrait alors connaître la zone interne de chaque tenant : sans vues par réseau soigneusement réglées, le tenant A résoudrait les noms du tenant B. C'est l'étanchéité qu'on protège partout ailleurs.
Et un tenant dont le résolveur vit chez l'hébergeur ne peut plus s'émanciper avec
(voir docs/filiation-emancipation.md).
La récursion est générique ; la zone interne ne l'est pas. C'est ce qui fait du résolveur un service de tenant, et non de fabric.
La cohabitation avec l'autoritatif
Les deux vivent sur infra-dns-01 et voudraient le port 53. Le partage est dérivé, pas
déclaré — l'exploitant n'a pas à se souvenir de déplacer un port parce qu'il a ajouté un
rôle :
resolveur (Unbound) 10.29.19.11:53 + 127.0.0.1:53 la seule porte
autoritatif (PowerDNS) 127.0.0.1:5300 derrière lui
Personne n'interroge l'autoritatif directement. Le résolveur le prend en stub-zone.
Aucun transitaire
forward-addr reste vide : Unbound récurse depuis la racine. Poser un transitaire
reviendrait à confier chaque question de l'écosystème à un tiers — ce que la bascule du
2026-08-23 avait justement supprimé.
Ce qu'il vérifie avant de se déclarer bon
Il interroge sa propre adresse pour la zone interne et pour un nom de l'Internet. Un résolveur « active » qui ne répond pas est le pire des cas : toute la flotte pointe vers lui, et découvre la panne en essayant de résoudre — c'est-à-dire au moment où le diagnostic lui-même devient impossible.
Variables principales
| Variable | Défaut | Rôle |
|---|---|---|
serveur_resolveur_ecoutes |
loopback + IP du tenant | où il répond |
serveur_resolveur_reseaux_autorises |
le supernet du tenant | qui a le droit de demander |
serveur_resolveur_autoritatif |
127.0.0.1:5300 |
la zone souveraine |
serveur_resolveur_transitaires |
[] |
vide = récursion depuis la racine |
Ce que ce rôle ne fait pas
Il ne bascule aucun /etc/resolv.conf — c'est le travail de client_resolveur, qui
valide que ce service répond avant de désigner qui que ce soit.