Exploiter un bridge

Notes d'opérateur pour faire tourner le bridge et l'anneau derrière lui : charger un plan, survivre à un redémarrage, garder la contribution en mouvement, et tenir le moteur hors d'Internet.

Le gateway (point d'entrée public) et le bridge (visage du moteur) sont les deux services de longue durée qu'un opérateur maintient en bonne santé, avec derrière eux les agents p4 et leurs stage servers. Le moteur ne parle aucune authentification — il suppose que les machines capables de s'atteindre sont censées le faire — si bien que tout ce qui est public converge vers le gateway, et que le bridge s'atteint par un tunnel plutôt qu'en étant publié.

• Le placement est un plan que vous écrivez, pas une requête que vous formulez : le bridge répond 409 à qui lui demande de servir. Générez le plan, passez-le à blanc, puis chargez avec --confirm.
• La load generation est écrite sur disque avant que la première commande ne parte. Elle est choisie par le chargeur, vérifiée pour égalité exacte à chaque session et au déchargement, et consignée nulle part sur les machines — perdez-la et un modèle chargé ne peut même pas être démonté.
• La generation de nœud est ce même nombre. Chargez un anneau avec deux valeurs différentes et il sert exactement une requête avant que la tête ne s'arrête ; la session suivante reste bloquée à demi chargée. Utilisez une valeur neuve à chaque chargement, sinon un enregistrement laissé par une tentative ratée entre en collision avec elle.
• L'agent refuse de charger sans son journal opérationnel. C'est le registre d'admission qu'exige un chargement rejouable sans danger, pas un drapeau de débogage.

• Un redémarrage d'agent fait tomber ses nœuds. Les stage servers n'existent qu'à l'exécution ; le modèle doit être rechargé depuis le plan. C'est la procédure de reprise, pas l'échec d'une procédure.
• Le gateway ne le rechargera pas pour vous. Son watchdog d'anneau remarque un modèle qui a cessé de servir, apprend du 409 du bridge que le placement est externe, le signale une fois, puis cesse de demander.
• Les compteurs de contribution vivent dans la mémoire du bridge. Le gateway interroge toutes les 30 s et crédite en delta ; un redémarrage ne perd que ce qui n'avait pas été relevé, et le gateway rétablit une nouvelle base plutôt que de payer deux fois quand un compteur recule.

• Faites écouter le bridge sur la loopback et donnez-lui un service token. Sans ce jeton il n'authentifie personne, et tout ce qui l'atteint peut faire tourner l'anneau gratuitement — il le dit au démarrage plutôt que de vous le laisser découvrir plus tard.
• Les agents annoncent l'adresse que les autres agents composent. Utilisez le réseau le plus rapide que les hôtes partagent, jamais la loopback entre hôtes, et gardez ce réseau hors de l'Internet public.
• Si quelque chose doit se trouver sur une IP publique, rappelez-vous que les ports publiés par Docker sont DNAT'd avant la chaîne INPUT, donc une règle sur dport ne correspondra pas. Filtrez dans la chaîne DOCKER-USER sur le port de destination d'origine de conntrack (--ctorigdstport), et persistez avec un oneshot systemd ordonné After=docker.service.

• Un wallet d'opérateur non renseigné se lit comme zéro gain. Le gateway saute toute ligne de contribution sans propriétaire et ne journalise rien. Les nœuds ont l'air inoccupés alors qu'ils servent.
• `pkill` correspond à sa propre ligne de commande. ssh host 'pkill -f server.js; ...' tue le shell qui l'exécute. Mettez le motif dans un fichier de script plutôt que dans la commande distante, utilisez une classe de caractères (server[.]js), et souvenez-vous qu'un processus lancé en simple node server.js ne porte aucun chemin sur lequel filtrer — trouvez-le plutôt par son port d'écoute.