Semaphore UI Runner erklärt: Schnellere Deployments, bessere Isolation, geringere Cloud-Kosten

Was ist ein Runner? #

Ein Semaphore-UI-Runner ist eine eigenstaendige Semaphore-Instanz ohne UI. Er verbindet sich mit deinem zentralen Semaphore-Server, holt Aufgaben ab und fuehrt sie aus. Runner koennen auf separaten Servern in jeder Region oder jedem Netzwerk gehostet werden - voellig unabhaengig davon, wo deine Semaphore-UI laeuft.

Welches Problem loest er? #

Ohne Runner laufen all deine Automatisierungsaufgaben auf einem einzigen Server. Das funktioniert am Anfang gut, aber wenn dein Team oder die Anzahl der Teams waechst, tauchen meist drei Probleme auf:

• Last. Eine grosse Warteschlange von Aufgaben, die um die Ressourcen eines einzigen Servers konkurrieren, verlangsamt alles.
• Isolation. Wenn mehrere Teams dieselbe Ausfuehrungsumgebung teilen, kann eine kaputte Pipeline alle anderen beeintraechtigen.
• Geografie. Ansible verbindet sich per SSH mit deinen Servern. Wenn deine Infrastruktur in Sydney steht, deine Semaphore-Instanz aber in Frankfurt laeuft, schleicht sich jedes Deployment durch eine transkontinentale Verbindung. Runner loesen alle drei Probleme.

Globale Runner vs. Projekt-Runner #

Semaphore bietet zwei Arten von Runnern an, und der Unterschied ist wichtig, wenn du den Pro-Plan bewertest.

Feature	Globale Runner (OSS)	Projekt-Runner (Pro)
Verfuegbar in	OSS (kostenlos)	Pro
Lastverteilung	✅	✅
Netzwerkisolation	❌	✅
Tag-basiertes Routing	❌	✅
Kontrolle pro Projekt	❌	✅

Globale Runner werden zufaellig ueber alle Projekte verteilt. Das ist grossartig fuer die Lastverteilung, aber du kannst nicht steuern, welcher Runner welche Aufgabe uebernimmt. Mit Projekt-Runnern kannst du jedem Template oder Inventory ein Tag zuweisen und dann bestimmte Aufgaben an bestimmte Runner leiten. Genau das ermoeglicht Isolation und geografisches Routing.

3 praxisnahe Einsatzfaelle fuer Runner #

1. Mehrere Teams, keine Stoerungen Dein Plattform-Team und dein Produkt-Team nutzen beide Semaphore. Sie arbeiten unabhaengig voneinander - unterschiedliche Projekte, unterschiedliche Server, unterschiedliche Risikotoleranz. Mit Projekt-Runnern bekommt jedes Team seinen eigenen Runner. Faellt der Runner eines Teams aus, merkt das andere Team davon nichts.

2. Verteilte Infrastruktur ueber mehrere Regionen Deine Website laeuft in einem Rechenzentrum in New York. Ein Backend-Service laeuft in Australien. Mit einem einzigen zentralen Runner in Europa geht jedes Deployment per SSH um die halbe Welt - langsam und unnoetig.

   Richte einen Runner in New York und einen in Australien ein. Tagge deine Inventories entsprechend. Jetzt verbindet sich jede Aufgabe lokal im selben Netzwerk und mit voller Geschwindigkeit. Schnellere Deployments und als Bonus eine kleinere Angriffsfläche.

3. Cloud-Kosten mit Webhooks + AWS Lambda senken Hier lohnt es sich, kurz langsamer zu machen, denn das ist eine echte Kostenoptimierung. Runner unterstuetzen Webhooks fuer zwei Ereignisse: Aufgabenstart und Aufgabenende. Damit kannst du Cloud-Ressourcen automatisch hoch- und herunterfahren.

   So sieht das Setup aus: Dein Runner laeuft auf einer AWS-EC2-Instanz. Solange sie laeuft, kostet sie Geld. Wenn sie gestoppt ist, kostet sie nichts.

   • Bei Aufgabenstart -> Webhook triggert eine Lambda-Funktion -> Lambda startet die EC2-Instanz -> Runner kommt online, verbindet sich mit Semaphore und uebernimmt die Aufgabe
   • Bei Aufgabenende -> Webhook triggert eine weitere Lambda-Funktion -> Lambda stoppt die EC2-Instanz

   Dein Runner laeuft nur dann, wenn er wirklich arbeitet. Fuer Teams mit sporadischer Auslastung kann allein das schon den Pro-Plan rechtfertigen.

So richtest du einen Projekt-Runner ein #

1. Gehe in die Projekteinstellungen und oeffne den Tab Runners. Dort siehst du alle vorhandenen Runner.

2. Klicke auf New Runner. Vergib einen Namen und ein Tag - zum Beispiel new-york.

3. Nach dem Speichern generiert Semaphore zwei Zugangsdaten: ein Token (auf beiden Seiten gespeichert und zur Identifizierung verwendet) und einen privaten Schluessel (nur auf dem Runner gespeichert und zur Verschluesselung der uebertragenen Daten verwendet). Lade den privaten Schluessel herunter - du brauchst ihn im naechsten Schritt.

4. Stelle den Runner auf deinem Zielserver bereit. Am einfachsten geht das mit Docker:

   docker run \
   -e SEMAPHORE_WEB_ROOT=https://semaphore.example.com \
   -e SEMAPHORE_RUNNER_TOKEN=/ADwjSWmWV8FZB4pwQaaEOWgqIdOR+oDOeOXe2a3JD0= \
   -e SEMAPHORE_RUNNER_PRIVATE_KEY_FILE=/config.runner.key \
   -v "/path/to/private/key:/config.runner.key" \
   -d semaphoreui/runner:v2.17.28
   

   Alternativ kannst du den interaktiven Setup-Befehl verwenden:

   semaphore runner setup
   

5. Oeffne in Semaphore ein beliebiges Template oder Inventory und weise das Runner-Tag new-york zu. Diese Aufgabe wird dann immer auf deinem Runner in New York ausgefuehrt.

Inventories taggen, nicht nur Templates #

Es gibt einen schlaueren Weg, Aufgaben zu routen, wenn du Server nach Region oder Netzwerk gruppiert hast. Statt jedes Template einzeln zu taggen, kannst du ein Runner-Tag direkt einem Inventory zuweisen.

Ein Inventory in Semaphore ist eine Liste von IP-Adressen, die Ansible verwendet, um sich mit deinen Servern zu verbinden. Wenn du weisst, dass eine bestimmte Servergruppe in New York steht, tagge dieses Inventory mit new-york. Ab dann wird jedes Template, das dieses Inventory verwendet, automatisch auf dem Runner in New York ausgefuehrt - ganz ohne Konfiguration pro Template.

Das ist besonders nuetzlich, wenn du neue Templates aufnimmst. Du waehlst einfach das richtige Inventory, und das Runner-Routing funktioniert automatisch.

Noch etwas: Parallelitaetsgrenzen #

Wenn du die Parallelitaet begrenzen willst, setze eine maximale Anzahl paralleler Aufgaben pro Runner. Standardmaessig ist sie unbegrenzt (0). Wenn du sie auf 5 setzt und dieser Runner bereits beschaeftigt ist, leitet Semaphore die Aufgabe an einen anderen Runner mit demselben Tag weiter.

Bereit, es auszuprobieren? #

Projekt-Runner sind im Semaphore-Pro-Plan verfuegbar. Wenn dein Team mit einem der oben genannten Szenarien konfrontiert ist - wachsende Aufgabenwarteschlangen, mehrere Teams, verteilte Infrastruktur - lohnt es sich, das genauer anzuschauen.