Die Runner-Flotte

SupaCloud führt jede Agent-Aufgabe in einem eigenen Container aus. Standardmäßig läuft dieser Container auf derselben Maschine wie der SupaCloud-Server — das Einzelhost-Deployment, das den meisten Installationen vollkommen genügt. Die Runner-Flotte ist der optionale Modus, in dem diese Arbeit stattdessen an eine oder mehrere separate Maschinen verteilt wird („Runner“ / „Worker-Nodes“), die Aufgaben vom Server abholen.

Du brauchst das wahrscheinlich noch nicht

Ein einzelner Host führt problemlos viele Agenten gleichzeitig aus. Greife nur dann zur Runner-Flotte, wenn du einen konkreten Grund hast: Agent-Arbeit, die mit dem Webserver um CPU/RAM konkurriert, eine Maschine mit GPU oder spezieller Toolchain, oder von Dritten beigesteuerte Rechenleistung. Bei ausgeschaltetem Hub-Modus (der Standard) verhält sich ein Deployment exakt so, als gäbe es die Flotte nicht.

Das Modell: Pull, nicht Push

Ein Runner ist rein ausgehend. Er baut eine HTTPS-Verbindung zum Server auf, authentifiziert sich mit seinem eigenen Bearer-Token und fragt: „Gibt es Arbeit für mich?“ Der Server verbindet sich nie zurück zum Runner, sodass ein Runner hinter NAT, einem Heimrouter oder einem Firmen-Proxy arbeitet — ohne eingehende Ports zu öffnen. Holt ein Runner einen Job ab, liefert der Server eine in sich geschlossene Start-Payload zurück — das aufgelöste Image, die Umgebung und die laufspezifischen Secrets für genau diese eine Aufgabe —, die der Runner zu Ende ausführt und deren Live-Ereignisse er zurückstreamt. Der Runner hält keine Kopie der Server-Datenbank und keine langlebigen Plattform-Secrets.

Wie das Dispatching einen Runner wählt

Ist der Hub-Modus an und startet eine Aufgabe, wählt der Server einen Runner mit einer einzigen Entscheidungsfunktion. Ab Werk ist das schlicht „der erste Online-Runner, dessen beworbene Fähigkeiten zum Image der Aufgabe passen.“ Alles darüber hinaus ist ein optionaler Hebel, der obenauf liegt und jeweils standardmäßig aus ist, sodass eine Null-Konfigurations-Flotte beim einfachen Verhalten bleibt:

• Fähigkeiten & Labels — ein Runner bewirbt die Images, die er ausführen kann, und freie Labels (z. B. gpu, eu-west); eine Aufgabe kann eine Label-Teilmenge verlangen.
• Drain / Cordon — einen Runner sanft stilllegen: er beendet seine laufende Arbeit, erhält aber nichts Neues mehr, sodass du eine Node aktualisieren oder ausmustern kannst, ohne laufende Aufgaben zu killen.
• Parallelitäts-Limit — ein Runner bewirbt, wie viele Aufgaben er gleichzeitig ausführt; der Server schickt nichts mehr, sobald er voll ist.
• Least-loaded + Gewicht — wenn aktiviert, geht jede neue Aufgabe an den am wenigsten ausgelasteten Runner, mit einem Gewicht, sodass eine größere Maschine proportional mehr aufnimmt.
• Priorität — eine höher priorisierte Aufgabe wird vor anderen in der Warteschlange eines Runners abgeholt.
• Pin — eine bestimmte Aufgabe auf einen bestimmten Runner zwingen; ist dieser Runner ausgelastet oder offline, wartet die Aufgabe auf ihn (statt stillschweigend woanders zu laufen).

Diese konfigurieren Admins — siehe die Admin-Anleitung Runner steuern & überwachen. Als Nutzer denkst du selten darüber nach: du startest eine Aufgabe und sie läuft.

Zuverlässigkeit

Der Server verfolgt den Heartbeat jedes Runners. Ein Runner, der über ein begrenztes Zeitfenster hinaus verstummt, wird als offline markiert und nicht mehr ausgewählt; jede Arbeit, die er angenommen, aber nie begonnen hat, wird erneut bereitgestellt, damit sie nicht hinter einer toten Maschine festhängt. Live-Ereignisse eines Remote-Laufs fließen in dasselbe Ereignisprotokoll wie ein lokaler Lauf, mit auf dem Weg hinein redigierten Secrets, sodass die Aufgaben-Zeitleiste identisch aussieht — egal ob sie neben dem Server oder auf einem Runner drei Zeitzonen entfernt lief.

Eine Namenskollision, die man kennen sollte

„Runner-Flotte“ benennt in SupaCloud leider zwei voneinander unabhängige Dinge:

1. Die Task-Runner-Flotte — diese Seite: separate Maschinen, die Agent-Aufgaben ausführen.
2. Die Connector-runner_fleet-Platzierung — eine Platzierungsoption für Marketplace-Connector-/Script-Wasm, bei der dieser gesandboxte Code auf einem connector-fähigen Runner statt im Server-Prozess läuft.

Sie teilen sich die Runner-Registry und den Pull-Transport, sind ansonsten aber getrennte Funktionen. Wenn diese Dokumentation „Runner-Flotte“ ohne Zusatz schreibt, ist die obige Task-Runner-Flotte gemeint.