Bare Metal Runners Autoalojados

Un Runner Autoalojado es un Bare Metal Runner que ejecutas y gestionas tú mismo, en lugar de usar un Runner On-Demand o Dedicated gestionado por Bencher. Apuntas el binario runner a un servidor API de Bencher, y este reclama y ejecuta Jobs en tu propio hardware.

Autoalojar un Runner es una buena opción cuando quieres:

• Ejecutar benchmarks en hardware específico que Bencher Cloud no ofrece
• Mantener las cargas de trabajo de benchmark dentro de tu propia red o un entorno aislado (air-gapped)
• Ejecutar Bencher Self-Hosted de principio a fin

Esta guía recorre el registro de un Runner, la descripción de su hardware con un Spec, la vinculación de ambos, y el inicio del binario runner. Para una visión general conceptual de cómo encajan Runners, Specs, Sandboxes y Jobs, consulta la Visión General de Bare Metal.

🐰 El sandboxing con Firecracker requiere Linux con KVM habilitado. Un Runner que solo sirve Specs sin sandbox puede ejecutarse en cualquier host compatible.

Crear un Runner

Un Runner es el recurso que autentica el binario runner con tu servidor API de Bencher. Crea uno con la CLI bencher, la API REST de Runners, o la Bencher Console.

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

Bencher devuelve el nuevo Runner junto con su clave:

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

La clave solo se muestra una vez, así que guárdala de forma segura. Se la pasarás al binario runner cuando inicies el Runner. Si una clave se pierde o se filtra alguna vez, rótala con la API POST /v0/runners/{runner}/key, lo cual invalida inmediatamente la clave anterior.

Crear un Spec

Un Spec describe el hardware que proporciona un Runner: sistema operativo, arquitectura de CPU, tipo de Sandbox, número de CPU, memoria, disco y acceso a la red. Un Job declara el Spec que necesita, y un Runner solo reclama Jobs para los Specs que soporta.

Crea un Spec con la CLI bencher, la API REST de Specs, o 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

Omite --sandbox para definir un Spec sin sandbox, y pasa --network si los Jobs en este Spec tienen permitido el acceso a la red. La memoria y el disco se especifican en bytes. Para más sobre los Specs y cómo un Testbed registra el Spec usado para cada Report, consulta Testbeds & Specs.

Asignar un Spec a un Runner

Un Runner Spec vincula un Spec a un Runner. Un Runner puede soportar múltiples Specs, y un Spec puede ser soportado por múltiples Runners. Un Runner solo reclama Jobs cuyo Spec le ha sido asignado.

Añade un Spec a un Runner con la CLI bencher o la API REST de Runner Specs:

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

Elimina la vinculación más tarde con la API DELETE /v0/runners/{runner}/specs/{spec}.

Iniciar el Runner

Con un Runner creado y al menos un Spec asignado, inicia el binario runner en tu hardware con runner up. Proporciona el host del servidor API, el UUID o slug del Runner, y la clave del Runner, ya sea como flags o variables de entorno:

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

El binario runner abre una única conexión WebSocket al servidor API, sondea Jobs que coincidan con sus Specs, ejecuta cada uno, y reporta los resultados de vuelta. La conexión permanece abierta entre Jobs, y el binario se actualiza a sí mismo entre Jobs cuando hay una nueva versión disponible.

Por defecto, un Runner rechaza cualquier Job cuyo Spec no tenga Sandbox. Para permitir que un Runner ejecute Jobs sin sandbox directamente en el host, inícialo con el flag --danger-allow-no-sandbox.

• runner up

  
  

  runner up

  Inicia el runner, sondeando y ejecutando Jobs de benchmark. Este es el comando de larga duración usado para operar un Runner Autoalojado. El runner abre una única conexión WebSocket al servidor API, reclama Jobs que coincidan con sus Specs, los ejecuta, y reporta los resultados de vuelta.

  runner up [OPTIONS]

  Opciones

  --host <HOST>

  El servidor API de Bencher al que conectarse. Por defecto, se usa https://api.bencher.dev. También se puede establecer con la variable de entorno BENCHER_HOST.

  --runner <RUNNER>

  El UUID o slug del Runner como el que operar. También se puede establecer con la variable de entorno BENCHER_RUNNER.

  --key <KEY>

  La clave de autenticación del Runner (bencher_runner_...) devuelta cuando se creó el Runner. También se puede establecer con la variable de entorno BENCHER_RUNNER_KEY.

  --poll-timeout <POLL_TIMEOUT>

  El tiempo de espera del long-poll en segundos mientras se espera un Job, entre 1 y 900. Por defecto, se usa 55.

  --danger-allow-no-sandbox

  Permite ejecutar Jobs sin un Sandbox. Sin este flag, un Job cuyo Spec no tenga Sandbox se rechaza en tiempo de ejecución. Los Jobs sin sandbox se ejecutan directamente en el host, así que solo habilita esto para cargas de trabajo de confianza. También se puede establecer con la variable de entorno BENCHER_DANGER_ALLOW_NO_SANDBOX.

  --sandbox-log-level <SANDBOX_LOG_LEVEL>

  El nivel de log para el proceso del sandbox. Por defecto, se usa warning.

  --no-auto-update

  Desactiva las actualizaciones automáticas desde el servidor. Por defecto, el runner se actualiza a sí mismo entre Jobs cuando el servidor ofrece una nueva versión. También se puede establecer con la variable de entorno BENCHER_NO_AUTO_UPDATE.

  --max-download-size <MAX_DOWNLOAD_SIZE>

  El tamaño máximo de descarga en bytes para los binarios de auto-actualización. Por defecto, se usan 500 MiB. Entra en conflicto con --no-auto-update.

  --max-output-size <MAX_OUTPUT_SIZE>

  El tamaño máximo en bytes para stdout y stderr recolectados. Por defecto, se usan 25 MiB.

  --max-file-count <MAX_FILE_COUNT>

  El número máximo de archivos de salida a decodificar. Por defecto, se usa 255.

  --max-symlinks <MAX_SYMLINKS>

  El número máximo de symlinks a seguir durante la resolución de rutas, coincidiendo con el límite MAXSYMLINKS del kernel de Linux. Por defecto, se usa 40. Solo se usa en modo sin sandbox.

  --grace-period <GRACE_PERIOD>

  El periodo de gracia en segundos después de que el benchmark termina antes de la recolección final de salida.

  Ajuste del Host

  Antes de cada benchmark, el runner aplica ajustes al host para reducir el ruido de medición. Por defecto, desactiva ASLR, el watchdog NMI, SMT / hyper-threading, y turbo boost; establece el governor de escalado de CPU a performance, swappiness a 10, y perf_event_paranoid a -1. Los flags de abajo mantienen las optimizaciones individuales en sus valores por defecto del host en su lugar.

  --no-tuning

  Desactiva todas las optimizaciones de ajuste del host.

  --aslr

  Mantiene ASLR habilitado (por defecto: desactivado para benchmarks).

  --nmi-watchdog

  Mantiene el watchdog NMI habilitado (por defecto: desactivado para benchmarks).

  --smt

  Mantiene SMT / hyper-threading habilitado (por defecto: desactivado para benchmarks).

  --turbo

  Mantiene turbo boost habilitado (por defecto: desactivado para benchmarks).

  --swappiness <SWAPPINESS>

  Establece el valor de swappiness. Por defecto, se usa 10.

  --governor <GOVERNOR>

  Establece el governor de escalado de CPU. Por defecto, se usa performance.

  --perf-event-paranoid <PERF_EVENT_PARANOID>

  Establece el valor de perf_event_paranoid. Por defecto, se usa -1.

  --help

  Imprime la ayuda.

Consulta la referencia de la CLI runner para conocer todas las opciones, y la referencia del Protocolo Runner para los mensajes intercambiados con el servidor.

Flujo de Trabajo del Runner Autoalojado

Una vez que el Runner está conectado, envías benchmarks de la misma forma que con cualquier Bare Metal Runner: construyes y subes una Image, luego ejecutas bencher run --image con un Spec coincidente. El diagrama de abajo muestra la ruta completa, desde el registro del Runner hasta la ejecución de un Job.

Continúa: Referencia de la CLI runner ➡