chore(ingress) : la moitié « nœud » du rôle s'en va, et avec elle la dernière exception d'output #34
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "chore/ingress-node-half-removal"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Le tier d'ingress est en conteneur depuis la PR #25. Le rôle avait gardé de quoi tourner sur un nœud et de quoi s'en retirer ; les quatre nœuds étant basculés, les deux n'ont plus d'objet.
C'était un reliquat « en attente », c'est devenu un prérequis :
tasks/vrf-crossing.ymls'accroche à la traverséexvrf-glbque l'étape suivante — le résolveur en conteneur — vient supprimer.Ce qui part
Quatre mécanismes qui n'existaient que parce qu'un proxy en table globale n'a pas de pied dans la VRF :
systemd-socket-proxydvers l'AC ACME, sur127.0.0.42:443, sousip vrf exec;/etc/hostsprivé monté dans la seule unitécaddy, qui y détournait le nom de l'AC ;xvrf-glbvers le Knot de la zone de challenge ;BindToDevice=sur la socket d'écoute.Plus
ingress_on_node,tasks/teardown.yml, l'entréeingress: caddydenetwork_anycast_owners, et le rôleingressdu play des nœuds.⚠ Ce qui n'était pas prévu : une ouverture de pare-feu vivante pour un usage mort
L'exception ACME d'
output— la seule exception au garde-fou anti-fuite de tout le jeu de règles — avait sa garde écrite surdn42_roles.ingress. Ce drapeau a changé de sens à la PR #25 : il voulait dire « ce nœud fait tourner le proxy », il veut dire « ce nœud héberge le conteneur du proxy ». La condition, elle, n'a pas suivi, et la règle a continué de se rendre quatre jours sur les quatre nœuds pour un Caddy absent.La chaîne
outputest maintenant réduite à ses deux garde-fous, sans une seule exception.⚠ Et un défaut latent dans
network, de la même familleLe handler « Put back the anycast addresses that the reconfigure stripped » bouclait sur
dn42_anycast, qui liste ce que le nœud annonce — y compris les services qu'un conteneur sert. Retireringress: caddyde la map l'aurait fait échouer sur unKeyError; le garder laissait une entrée désignant une unité absente de la machine.Le vrai risque est au-delà : rien n'empêchait ce handler de créer la VIP sur
lo-dn42d'un nœud où plus rien n'écoute, que Bird aurait aussitôt annoncée. Un trou noir anycast né d'un handler censé réparer.L'assert qui contrôle et le handler qui agit lisent désormais la même liste filtrée,
network_anycast_local— un fait et non deux expressions écrites deux fois.La preuve du rendu
git worktreesurmain, le même script de rendu des deux côtés,diff -ru:Ce second point a une conséquence de déploiement :
caddy.socketchange quand même (commentaires), donc socket puis service redémarrent, donc la VIP bat. D'où un conteneur à la fois.Le déroulé
Fait sur les 12 machines. Sur les quatre nœuds :
ACME=0, la VIP d'ingress absente delo-dn42,outputsans exception, résolveur et proxy qui répondent. Sur les quatre conteneurs : Caddy actif, VIP surlo, route préféréecnt_ingress(préférence 200) en v4 et en v6, HTTP et HTTPS à 302.⚠
X-Ingress-Nodea montréfr-bod1depuisfr-bod2juste après son déroulé — pas un défaut, la bascule anycast en train de faire son travail le temps que la session iBGP du conteneur revienne.Au passage
Le README du rôle portait encore deux sections décrivant
caddy.storage.swytch, remplacé le 07/08 — dont ses trois modes de panne, présentés comme ceux du module actuel. Regroupés et datés plutôt que supprimés : la leçon (« un magasin de certificats se juge sur ce qu'il fait quand un pair manque ») survit au module.Ce qui part est le code, pas la mémoire de ce qu'il a coûté : les quatre mécanismes gardent leur explication dans les defaults du rôle, dans son README et dans
flow-matrix.md.