Bare Metal Runners auto-hébergés

Un Runner auto-hébergé est un Bare Metal Runner que vous exécutez et gérez vous-même, au lieu d’utiliser un Runner On-Demand ou Dedicated géré par Bencher. Vous pointez le binaire runner vers un serveur API Bencher, et il réclame et exécute des Jobs sur votre propre matériel.

L’auto-hébergement d’un Runner est un bon choix lorsque vous souhaitez :

• Exécuter des benchmarks sur du matériel spécifique que Bencher Cloud ne propose pas
• Conserver les charges de travail de benchmark à l’intérieur de votre propre réseau ou d’un environnement isolé (air-gapped)
• Exécuter Bencher Self-Hosted de bout en bout

Ce guide vous accompagne dans l’enregistrement d’un Runner, la description de son matériel avec un Spec, la liaison des deux ensemble, et le démarrage du binaire runner. Pour un aperçu conceptuel de la façon dont les Runners, Specs, Sandboxes et Jobs s’articulent, consultez l’Aperçu Bare Metal.

🐰 Le sandboxing Firecracker nécessite Linux avec KVM activé. Un Runner qui ne sert que des Specs sans sandbox peut s’exécuter sur n’importe quel hôte pris en charge.

Créer un Runner

Un Runner est la ressource qui authentifie le binaire runner auprès de votre serveur API Bencher. Créez-en un avec la CLI bencher, l’API REST Runners, ou la Bencher Console.

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

Bencher renvoie le nouveau Runner accompagné de sa clé :

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

La clé n’est affichée qu’une seule fois, conservez-la donc en lieu sûr. Vous la transmettrez au binaire runner lorsque vous démarrerez le Runner. Si une clé est perdue ou divulguée, faites-la tourner avec l’API POST /v0/runners/{runner}/key, ce qui invalide immédiatement la clé précédente.

Créer un Spec

Un Spec décrit le matériel qu’un Runner fournit : système d’exploitation, architecture du CPU, type de Sandbox, nombre de CPU, mémoire, disque et accès réseau. Un Job déclare le Spec dont il a besoin, et un Runner ne réclame que les Jobs des Specs qu’il prend en charge.

Créez un Spec avec la CLI bencher, l’API REST Specs, ou la 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

Omettez --sandbox pour définir un Spec sans sandbox, et passez --network si les Jobs sur ce Spec sont autorisés à accéder au réseau. La mémoire et le disque sont spécifiés en octets. Pour en savoir plus sur les Specs et sur la façon dont un Testbed enregistre le Spec utilisé pour chaque Report, consultez Testbeds & Specs.

Assigner un Spec à un Runner

Un Runner Spec lie un Spec à un Runner. Un Runner peut prendre en charge plusieurs Specs, et un Spec peut être pris en charge par plusieurs Runners. Un Runner ne réclame que les Jobs dont le Spec lui a été assigné.

Ajoutez un Spec à un Runner avec la CLI bencher ou l’API REST Runner Specs :

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

Supprimez la liaison plus tard avec l’API DELETE /v0/runners/{runner}/specs/{spec}.

Démarrer le Runner

Avec un Runner créé et au moins un Spec assigné, démarrez le binaire runner sur votre matériel avec runner up. Fournissez l’hôte du serveur API, l’UUID ou le slug du Runner, et la clé du Runner, soit en tant que drapeaux, soit en tant que variables d’environnement :

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

Le binaire runner ouvre une unique connexion WebSocket vers le serveur API, interroge les Jobs correspondant à ses Specs, exécute chacun d’eux, et renvoie les résultats. La connexion reste ouverte d’un Job à l’autre, et le binaire se met à jour lui-même entre les Jobs lorsqu’une nouvelle version est disponible.

Par défaut, un Runner rejette tout Job dont le Spec n’a pas de Sandbox. Pour permettre à un Runner d’exécuter directement des Jobs sans sandbox sur l’hôte, démarrez-le avec le drapeau --danger-allow-no-sandbox.

• runner up

  
  

  runner up

  Démarre le runner, en interrogeant et en exécutant les Jobs de benchmark. C’est la commande de longue durée utilisée pour exploiter un Runner auto-hébergé. Le runner ouvre une unique connexion WebSocket vers le serveur API, réclame les Jobs correspondant à ses Specs, les exécute, et renvoie les résultats.

  runner up [OPTIONS]

  Options

  --host <HOST>

  Le serveur API Bencher auquel se connecter. Par défaut, https://api.bencher.dev est utilisé. Peut aussi être défini avec la variable d’environnement BENCHER_HOST.

  --runner <RUNNER>

  L’UUID ou le slug du Runner sous lequel opérer. Peut aussi être défini avec la variable d’environnement BENCHER_RUNNER.

  --key <KEY>

  La clé d’authentification du Runner (bencher_runner_...) renvoyée lors de la création du Runner. Peut aussi être défini avec la variable d’environnement BENCHER_RUNNER_KEY.

  --poll-timeout <POLL_TIMEOUT>

  Le délai d’attente du long-poll en secondes pendant l’attente d’un Job, entre 1 et 900. Par défaut, 55 est utilisé.

  --danger-allow-no-sandbox

  Autorise l’exécution de Jobs sans Sandbox. Sans ce drapeau, un Job dont le Spec n’a pas de Sandbox est rejeté à l’exécution. Les Jobs sans sandbox s’exécutent directement sur l’hôte, n’activez donc ceci que pour des charges de travail de confiance. Peut aussi être défini avec la variable d’environnement BENCHER_DANGER_ALLOW_NO_SANDBOX.

  --sandbox-log-level <SANDBOX_LOG_LEVEL>

  Le niveau de journalisation du processus de sandbox. Par défaut, warning est utilisé.

  --no-auto-update

  Désactive les mises à jour automatiques depuis le serveur. Par défaut, le runner se met à jour lui-même entre les Jobs lorsque le serveur propose une nouvelle version. Peut aussi être défini avec la variable d’environnement BENCHER_NO_AUTO_UPDATE.

  --max-download-size <MAX_DOWNLOAD_SIZE>

  La taille de téléchargement maximale en octets pour les binaires de mise à jour automatique. Par défaut, 500 Mio est utilisé. En conflit avec --no-auto-update.

  --max-output-size <MAX_OUTPUT_SIZE>

  La taille maximale en octets pour les sorties stdout et stderr collectées. Par défaut, 25 Mio est utilisé.

  --max-file-count <MAX_FILE_COUNT>

  Le nombre maximal de fichiers de sortie à décoder. Par défaut, 255 est utilisé.

  --max-symlinks <MAX_SYMLINKS>

  Le nombre maximal de liens symboliques à suivre lors de la résolution des chemins, correspondant à la limite MAXSYMLINKS du noyau Linux. Par défaut, 40 est utilisé. Utilisé uniquement en mode sans sandbox.

  --grace-period <GRACE_PERIOD>

  Le délai de grâce en secondes après la fin du benchmark avant la collecte finale des sorties.

  Réglage de l’hôte

  Avant chaque benchmark, le runner applique un réglage de l’hôte pour réduire le bruit de mesure. Par défaut, il désactive l’ASLR, le NMI watchdog, le SMT / hyper-threading et le turbo boost ; règle le gouverneur de mise à l’échelle du CPU sur performance, la swappiness sur 10, et perf_event_paranoid sur -1. Les drapeaux ci-dessous conservent au contraire les optimisations individuelles à leurs valeurs par défaut de l’hôte.

  --no-tuning

  Désactive toutes les optimisations de réglage de l’hôte.

  --aslr

  Conserve l’ASLR activé (par défaut : désactivé pour les benchmarks).

  --nmi-watchdog

  Conserve le NMI watchdog activé (par défaut : désactivé pour les benchmarks).

  --smt

  Conserve le SMT / hyper-threading activé (par défaut : désactivé pour les benchmarks).

  --turbo

  Conserve le turbo boost activé (par défaut : désactivé pour les benchmarks).

  --swappiness <SWAPPINESS>

  Définit la valeur de swappiness. Par défaut, 10 est utilisé.

  --governor <GOVERNOR>

  Définit le gouverneur de mise à l’échelle du CPU. Par défaut, performance est utilisé.

  --perf-event-paranoid <PERF_EVENT_PARANOID>

  Définit la valeur de perf_event_paranoid. Par défaut, -1 est utilisé.

  --help

  Affiche l’aide.

Consultez la référence de la CLI runner pour chaque option, et la référence du Protocole Runner pour les messages échangés avec le serveur.

Workflow d’un Runner auto-hébergé

Une fois le Runner connecté, vous soumettez les benchmarks de la même manière qu’avec n’importe quel Bare Metal Runner : construisez et poussez une Image, puis exécutez bencher run --image avec un Spec correspondant. Le diagramme ci-dessous montre le chemin complet, de l’enregistrement du Runner jusqu’à l’exécution d’un Job.

Continuez : Référence de la CLI runner ➡