Eine Bridge betreiben

Betreibernotizen für die Bridge und den Ring dahinter: einen Plan laden, einen Neustart überstehen, den Beitragsfluss aufrechterhalten und die Engine aus dem Internet heraushalten.

Das Gateway (öffentlicher Eingang) und die Bridge (Gesicht der Engine) sind die zwei langlebigen Dienste, die ein Betreiber gesund hält, mit den p4-Agents und ihren Stage-Servern dahinter. Die Engine spricht überhaupt keine Authentifizierung — sie nimmt an, dass Maschinen, die einander erreichen können, das auch sollen —, also konvergiert alles Öffentliche auf dem Gateway, und die Bridge wird über einen Tunnel erreicht, statt veröffentlicht zu werden.

• Platzierung ist ein Plan, den du schreibst, keine Anfrage, die du stellst: Die Bridge antwortet jedem mit 409, der sie zum Bedienen auffordert. Erzeuge den Plan, lass ihn als Dry-Run laufen, und lade ihn dann mit --confirm.
• Die Load-Generation wird auf die Platte geschrieben, bevor das erste Kommando hinausgeht. Sie wird vom Ladenden gewählt, bei jeder Session und bei jedem Unload auf exakte Gleichheit geprüft und ist auf den Maschinen nirgends festgehalten — verlierst du sie, lässt sich ein geladenes Modell nicht einmal abbauen.
• Die Node-Generation ist dieselbe Zahl. Lade einen Ring mit zwei verschiedenen, und er bedient genau eine Anfrage, bevor der Kopf stehen bleibt; die nächste Session hängt halb geladen. Nimm pro Load einen frischen Wert, sonst kollidiert eine Registrierung, die ein gescheiterter Versuch hinterlassen hat, damit.
• Der Agent verweigert das Laden ohne sein Betriebsjournal. Das ist der Zulassungsnachweis, den ein replay-sicherer Load braucht, kein Debug-Flag.

• Ein Agent-Neustart verwirft seine Nodes. Stage-Server existieren nur zur Laufzeit; das Modell muss aus dem Plan erneut geladen werden. Das ist die Wiederherstellungsprozedur, kein Fehlerfall.
• Das Gateway lädt es nicht für dich neu. Sein Ring-Watchdog bemerkt ein Modell, das nicht mehr bedient, lernt aus dem 409 der Bridge, dass die Platzierung extern ist, sagt das einmal und hört auf zu fragen.
• Beitragszähler leben im Speicher der Bridge. Das Gateway pollt alle 30 s und schreibt per Delta gut; ein Neustart verliert nur, was noch nicht abgeholt war, und das Gateway baselined neu, statt doppelt zu bezahlen, wenn ein Zähler zurückspringt.

• Binde die Bridge auf Loopback und gib ihr ein Service-Token. Ohne das Token authentifiziert sie niemanden, und alles, was sie erreicht, kann den Ring kostenlos ausführen — sie sagt das beim Start, statt es dich später herausfinden zu lassen.
• Agents bewerben die Adresse, die andere Agents wählen. Nutze das schnellste Netz, das die Hosts teilen, nie Loopback zwischen Hosts, und halte dieses Netz aus dem öffentlichen Internet heraus.
• Muss etwas auf einer öffentlichen IP sitzen, denk daran, dass Dockers veröffentlichte Ports vor der INPUT-Chain DNAT't werden, eine Regel auf dport greift also nicht. Filtere in der DOCKER-USER-Chain über den ursprünglichen Zielport von conntrack (--ctorigdstport) und persistiere mit einem systemd-Oneshot, geordnet After=docker.service.

• Eine nicht gesetzte Betreiber-Wallet liest sich als null Einnahmen. Das Gateway überspringt jede Beitragszeile ohne Besitzer und loggt nichts. Die Nodes sehen untätig aus, während sie bedienen.
• `pkill` matcht seine eigene Kommandozeile. ssh host 'pkill -f server.js; ...' killt die Shell, die den Befehl ausführt. Pack das Muster in eine Skriptdatei statt in den Remote-Befehl, nutze eine Zeichenklasse (server[.]js), und denk daran: Ein als bloßes node server.js gestarteter Prozess trägt keinen Pfad, auf den man matchen könnte — finde ihn stattdessen über seinen Listening-Port.