Self-Hosted Bare Metal Runners

Ein Self-Hosted Runner ist ein Bare Metal Runner, den Sie selbst betreiben und verwalten, anstatt einen von Bencher verwalteten On-Demand- oder Dedicated Runner zu nutzen. Sie richten das runner-Binary auf einen Bencher API-Server aus, und es beansprucht und führt Jobs auf Ihrer eigenen Hardware aus.

Das Self-Hosting eines Runner eignet sich gut, wenn Sie Folgendes möchten:

• Benchmarks auf spezifischer Hardware ausführen, die Bencher Cloud nicht anbietet
• Benchmark-Workloads innerhalb Ihres eigenen Netzwerks oder in einer Air-Gapped-Umgebung halten
• Bencher Self-Hosted durchgängig betreiben

Dieser Leitfaden führt durch das Registrieren eines Runner, das Beschreiben seiner Hardware mit einer Spec, das Verknüpfen beider und das Starten des runner-Binary. Einen konzeptionellen Überblick darüber, wie Runner, Specs, Sandboxes und Jobs zusammenpassen, finden Sie in der Bare Metal-Übersicht.

🐰 Firecracker-Sandboxing erfordert Linux mit aktiviertem KVM. Ein Runner, der nur Specs ohne Sandbox bedient, kann auf jedem unterstützten Host laufen.

Einen Runner erstellen

Ein Runner ist die Ressource, die das runner-Binary gegenüber Ihrem Bencher API-Server authentifiziert. Erstellen Sie einen mit der bencher CLI, der Runners REST-API oder der Bencher Console.

bencher runner create \
  --host https://api.bencher.example.com \
  --name "My Runner"

Bencher gibt den neuen Runner zusammen mit seinem Schlüssel zurück:

{
  "uuid": "...",
  "key": "bencher_runner_..."
}

Der Schlüssel wird nur einmal angezeigt, bewahren Sie ihn also sicher auf. Sie übergeben ihn dem runner-Binary, wenn Sie den Runner starten. Falls ein Schlüssel jemals verloren geht oder durchsickert, rotieren Sie ihn mit der POST /v0/runners/{runner}/key-API, was den vorherigen Schlüssel sofort ungültig macht.

Eine Spec erstellen

Eine Spec beschreibt die Hardware, die ein Runner bereitstellt: Betriebssystem, CPU-Architektur, Sandbox-Typ, CPU-Anzahl, Arbeitsspeicher, Festplatte und Netzwerkzugriff. Ein Job deklariert die Spec, die er benötigt, und ein Runner beansprucht nur Jobs für Specs, die er unterstützt.

Erstellen Sie eine Spec mit der bencher CLI, der Specs REST-API oder der Bencher Console:

bencher spec create \
  --host https://api.bencher.example.com \
  --name "Intel v1" \
  --os linux \
  --architecture x86_64 \
  --sandbox firecracker \
  --cpu 4 \
  --memory 51539607552 \
  --disk 137438953472

Lassen Sie --sandbox weg, um eine Spec ohne Sandbox zu definieren, und übergeben Sie --network, wenn Jobs auf dieser Spec Netzwerkzugriff erhalten dürfen. Arbeitsspeicher und Festplatte werden in Bytes angegeben. Mehr zu Specs und wie ein Testbed die für jeden Report verwendete Spec aufzeichnet, finden Sie unter Testbeds & Specs.

Eine Spec einem Runner zuweisen

Eine Runner Spec verknüpft eine Spec mit einem Runner. Ein Runner kann mehrere Specs unterstützen, und eine Spec kann von mehreren Runnern unterstützt werden. Ein Runner beansprucht nur Jobs, deren Spec ihm zugewiesen wurde.

Fügen Sie eine Spec zu einem Runner mit der bencher CLI oder der Runner Specs REST-API hinzu:

bencher runner spec add my-runner \
  --host https://api.bencher.example.com \
  --spec intel-v1

Entfernen Sie die Verknüpfung später mit der DELETE /v0/runners/{runner}/specs/{spec}-API.

Den Runner starten

Sobald ein Runner erstellt und mindestens eine Spec zugewiesen ist, starten Sie das runner-Binary auf Ihrer Hardware mit runner up. Geben Sie den API-Server-Host, die Runner-UUID oder den Slug sowie den Runner-Schlüssel an, entweder als Flags oder als Umgebungsvariablen:

runner up \
  --host https://api.bencher.example.com \
  --runner my-runner \
  --key bencher_runner_...

export BENCHER_HOST=https://api.bencher.example.com
export BENCHER_RUNNER=my-runner
export BENCHER_RUNNER_KEY=bencher_runner_...
runner up

Das runner-Binary öffnet eine einzige WebSocket-Verbindung zum API-Server, fragt Jobs ab, die zu seinen Specs passen, führt jeden aus und meldet die Ergebnisse zurück. Die Verbindung bleibt über Jobs hinweg offen, und das Binary aktualisiert sich selbst zwischen Jobs, wenn eine neue Version verfügbar ist.

Standardmäßig lehnt ein Runner jeden Job ab, dessen Spec keine Sandbox hat. Um einem Runner zu erlauben, Jobs ohne Sandbox direkt auf dem Host auszuführen, starten Sie ihn mit dem --danger-allow-no-sandbox-Flag.

• runner up

  
  

  runner up

  Startet den Runner und fragt Benchmark-Jobs ab und führt sie aus. Dies ist der langlaufende Befehl zum Betrieb eines Self-Hosted Runner. Der Runner öffnet eine einzige WebSocket-Verbindung zum API-Server, beansprucht Jobs, die zu seinen Specs passen, führt sie aus und meldet die Ergebnisse zurück.

  runner up [OPTIONS]

  Optionen

  --host <HOST>

  Der Bencher API-Server, zu dem eine Verbindung hergestellt werden soll. Standardmäßig wird https://api.bencher.dev verwendet. Kann auch mit der Umgebungsvariable BENCHER_HOST gesetzt werden.

  --runner <RUNNER>

  Die UUID oder der Slug des Runner, als der agiert werden soll. Kann auch mit der Umgebungsvariable BENCHER_RUNNER gesetzt werden.

  --key <KEY>

  Der Runner-Authentifizierungsschlüssel (bencher_runner_...), der zurückgegeben wurde, als der Runner erstellt wurde. Kann auch mit der Umgebungsvariable BENCHER_RUNNER_KEY gesetzt werden.

  --poll-timeout <POLL_TIMEOUT>

  Das Long-Poll-Timeout in Sekunden beim Warten auf einen Job, zwischen 1 und 900. Standardmäßig wird 55 verwendet.

  --danger-allow-no-sandbox

  Erlaubt das Ausführen von Jobs ohne Sandbox. Ohne dieses Flag wird ein Job, dessen Spec keine Sandbox hat, zur Laufzeit abgelehnt. Jobs ohne Sandbox laufen direkt auf dem Host, aktivieren Sie dies also nur für vertrauenswürdige Workloads. Kann auch mit der Umgebungsvariable BENCHER_DANGER_ALLOW_NO_SANDBOX gesetzt werden.

  --sandbox-log-level <SANDBOX_LOG_LEVEL>

  Das Log-Level für den Sandbox-Prozess. Standardmäßig wird warning verwendet.

  --no-auto-update

  Deaktiviert automatische Updates vom Server. Standardmäßig aktualisiert sich der Runner zwischen Jobs selbst, wenn der Server eine neue Version anbietet. Kann auch mit der Umgebungsvariable BENCHER_NO_AUTO_UPDATE gesetzt werden.

  --max-download-size <MAX_DOWNLOAD_SIZE>

  Die maximale Download-Größe in Bytes für Self-Update-Binaries. Standardmäßig werden 500 MiB verwendet. Steht im Konflikt mit --no-auto-update.

  --max-output-size <MAX_OUTPUT_SIZE>

  Die maximale Größe in Bytes für erfasstes stdout und stderr. Standardmäßig werden 25 MiB verwendet.

  --max-file-count <MAX_FILE_COUNT>

  Die maximale Anzahl an Ausgabedateien, die dekodiert werden. Standardmäßig wird 255 verwendet.

  --max-symlinks <MAX_SYMLINKS>

  Die maximale Anzahl an Symlinks, denen bei der Pfadauflösung gefolgt wird, entsprechend dem MAXSYMLINKS-Limit des Linux-Kernels. Standardmäßig wird 40 verwendet. Wird nur im Modus ohne Sandbox verwendet.

  --grace-period <GRACE_PERIOD>

  Die Karenzzeit in Sekunden nach dem Beenden des Benchmarks vor der finalen Ausgabeerfassung.

  Host-Tuning

  Vor jedem Benchmark wendet der runner Host-Tuning an, um Messrauschen zu reduzieren. Standardmäßig deaktiviert er ASLR, den NMI-Watchdog, SMT / Hyper-Threading und Turbo Boost; setzt den CPU-Scaling-Governor auf performance, Swappiness auf 10 und perf_event_paranoid auf -1. Die folgenden Flags belassen einzelne Optimierungen stattdessen bei ihren Host-Standardwerten.

  --no-tuning

  Deaktiviert alle Host-Tuning-Optimierungen.

  --aslr

  Belässt ASLR aktiviert (Standard: für Benchmarks deaktiviert).

  --nmi-watchdog

  Belässt den NMI-Watchdog aktiviert (Standard: für Benchmarks deaktiviert).

  --smt

  Belässt SMT / Hyper-Threading aktiviert (Standard: für Benchmarks deaktiviert).

  --turbo

  Belässt Turbo Boost aktiviert (Standard: für Benchmarks deaktiviert).

  --swappiness <SWAPPINESS>

  Setzt den Swappiness-Wert. Standardmäßig wird 10 verwendet.

  --governor <GOVERNOR>

  Setzt den CPU-Scaling-Governor. Standardmäßig wird performance verwendet.

  --perf-event-paranoid <PERF_EVENT_PARANOID>

  Setzt den perf_event_paranoid-Wert. Standardmäßig wird -1 verwendet.

  --help

  Hilfe ausgeben.

Die runner CLI-Referenz beschreibt jede Option, und die Runner Protocol-Referenz beschreibt die mit dem Server ausgetauschten Nachrichten.

Self-Hosted Runner-Workflow

Sobald der Runner verbunden ist, reichen Sie Benchmarks auf dieselbe Weise ein wie bei jedem Bare Metal Runner: Erstellen und pushen Sie ein Image und führen Sie dann bencher run --image mit einer passenden Spec aus. Das folgende Diagramm zeigt den vollständigen Weg, vom Registrieren des Runner bis zum Ausführen eines Jobs.

Weiter geht’s: runner CLI-Referenz ➡