Self-Hosted Bare Metal Runners

Um Self-Hosted Runner é um Bare Metal Runner que você executa e gerencia por conta própria, em vez de usar um Runner On-Demand ou Dedicated gerenciado pela Bencher. Você aponta o binário runner para um servidor de API Bencher, e ele reivindica e executa Jobs no seu próprio hardware.

Auto-hospedar um Runner é uma boa escolha quando você quer:

• Executar benchmarks em hardware específico que a Bencher Cloud não oferece
• Manter as cargas de trabalho de benchmark dentro da sua própria rede ou em um ambiente isolado (air-gapped)
• Executar o Bencher Self-Hosted de ponta a ponta

Este guia mostra como registrar um Runner, descrever seu hardware com uma Spec, vincular os dois e iniciar o binário runner. Para uma visão conceitual de como Runners, Specs, Sandboxes e Jobs se encaixam, consulte a Visão Geral de Bare Metal.

🐰 O sandboxing com Firecracker requer Linux com KVM habilitado. Um Runner que atende apenas Specs sem sandbox pode rodar em qualquer host suportado.

Criar um Runner

Um Runner é o recurso que autentica o binário runner no seu servidor de API Bencher. Crie um com a CLI bencher, a Runners REST API, ou o Bencher Console.

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

A Bencher retorna o novo Runner junto com sua chave:

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

A chave é exibida apenas uma vez, então guarde-a com segurança. Você a passará ao binário runner quando iniciar o Runner. Se uma chave for perdida ou vazada, rotacione-a com a API POST /v0/runners/{runner}/key, que invalida imediatamente a chave anterior.

Criar uma Spec

Uma Spec descreve o hardware que um Runner fornece: sistema operacional, arquitetura de CPU, tipo de Sandbox, número de CPUs, memória, disco e acesso à rede. Um Job declara a Spec de que precisa, e um Runner só reivindica Jobs para Specs que ele suporta.

Crie uma Spec com a CLI bencher, a Specs REST API, ou o 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

Omita --sandbox para definir uma Spec sem sandbox, e passe --network se os Jobs nesta Spec tiverem permissão de acesso à rede. Memória e disco são especificados em bytes. Para mais sobre Specs e como um Testbed registra a Spec usada em cada Report, consulte Testbeds & Specs.

Atribuir uma Spec a um Runner

Uma Runner Spec vincula uma Spec a um Runner. Um Runner pode suportar múltiplas Specs, e uma Spec pode ser suportada por múltiplos Runners. Um Runner só reivindica Jobs cuja Spec lhe foi atribuída.

Adicione uma Spec a um Runner com a CLI bencher ou a Runner Specs REST API:

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

Remova o vínculo mais tarde com a API DELETE /v0/runners/{runner}/specs/{spec}.

Iniciar o Runner

Com um Runner criado e ao menos uma Spec atribuída, inicie o binário runner no seu hardware com runner up. Forneça o host do servidor de API, o UUID ou slug do Runner e a chave do Runner, seja como flags ou variáveis de ambiente:

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

O binário runner abre uma única conexão WebSocket ao servidor de API, faz polling por Jobs que correspondam às suas Specs, executa cada um e reporta os resultados de volta. A conexão permanece aberta entre os Jobs, e o binário se atualiza entre os Jobs quando uma nova versão está disponível.

Por padrão, um Runner rejeita qualquer Job cuja Spec não tenha Sandbox. Para permitir que um Runner execute Jobs sem sandbox diretamente no host, inicie-o com a flag --danger-allow-no-sandbox.

• runner up

  
  

  runner up

  Inicia o runner, fazendo polling e executando Jobs de benchmark. Este é o comando de longa duração usado para operar um Self-Hosted Runner. O runner abre uma única conexão WebSocket ao servidor de API, reivindica Jobs que correspondam às suas Specs, os executa e reporta os resultados de volta.

  runner up [OPTIONS]

  Opções

  --host <HOST>

  O servidor de API Bencher ao qual se conectar. Por padrão, https://api.bencher.dev é usado. Também pode ser definido com a variável de ambiente BENCHER_HOST.

  --runner <RUNNER>

  O UUID ou slug do Runner sob o qual operar. Também pode ser definido com a variável de ambiente BENCHER_RUNNER.

  --key <KEY>

  A chave de autenticação do Runner (bencher_runner_...) retornada quando o Runner foi criado. Também pode ser definida com a variável de ambiente BENCHER_RUNNER_KEY.

  --poll-timeout <POLL_TIMEOUT>

  O timeout de long-poll em segundos enquanto aguarda um Job, entre 1 e 900. Por padrão, 55 é usado.

  --danger-allow-no-sandbox

  Permite executar Jobs sem um Sandbox. Sem essa flag, um Job cuja Spec não tem Sandbox é rejeitado em tempo de execução. Jobs sem sandbox rodam diretamente no host, então habilite isso apenas para cargas de trabalho confiáveis. Também pode ser definida com a variável de ambiente BENCHER_DANGER_ALLOW_NO_SANDBOX.

  --sandbox-log-level <SANDBOX_LOG_LEVEL>

  O nível de log para o processo do sandbox. Por padrão, warning é usado.

  --no-auto-update

  Desabilita as atualizações automáticas do servidor. Por padrão, o runner se atualiza entre os Jobs quando o servidor oferece uma nova versão. Também pode ser definida com a variável de ambiente BENCHER_NO_AUTO_UPDATE.

  --max-download-size <MAX_DOWNLOAD_SIZE>

  O tamanho máximo de download em bytes para binários de auto-atualização. Por padrão, 500 MiB é usado. Conflita com --no-auto-update.

  --max-output-size <MAX_OUTPUT_SIZE>

  O tamanho máximo em bytes para stdout e stderr coletados. Por padrão, 25 MiB é usado.

  --max-file-count <MAX_FILE_COUNT>

  O número máximo de arquivos de saída a decodificar. Por padrão, 255 é usado.

  --max-symlinks <MAX_SYMLINKS>

  O número máximo de symlinks a seguir durante a resolução de caminho, correspondendo ao limite MAXSYMLINKS do kernel Linux. Por padrão, 40 é usado. Usado apenas no modo sem sandbox.

  --grace-period <GRACE_PERIOD>

  O período de carência em segundos após o benchmark encerrar antes da coleta final de saída.

  Ajuste do Host

  Antes de cada benchmark, o runner aplica ajustes ao host para reduzir o ruído de medição. Por padrão, ele desabilita ASLR, o NMI watchdog, SMT / hyper-threading e o turbo boost; define o governor de escalonamento de CPU como performance, a swappiness como 10 e perf_event_paranoid como -1. As flags abaixo mantêm otimizações individuais nos padrões do host.

  --no-tuning

  Desabilita todas as otimizações de ajuste do host.

  --aslr

  Mantém o ASLR habilitado (padrão: desabilitado para benchmarks).

  --nmi-watchdog

  Mantém o NMI watchdog habilitado (padrão: desabilitado para benchmarks).

  --smt

  Mantém o SMT / hyper-threading habilitado (padrão: desabilitado para benchmarks).

  --turbo

  Mantém o turbo boost habilitado (padrão: desabilitado para benchmarks).

  --swappiness <SWAPPINESS>

  Define o valor de swappiness. Por padrão, 10 é usado.

  --governor <GOVERNOR>

  Define o governor de escalonamento de CPU. Por padrão, performance é usado.

  --perf-event-paranoid <PERF_EVENT_PARANOID>

  Define o valor de perf_event_paranoid. Por padrão, -1 é usado.

  --help

  Imprime a ajuda.

Consulte a referência da CLI runner para todas as opções, e a referência do Runner Protocol para as mensagens trocadas com o servidor.

Fluxo de Trabalho do Self-Hosted Runner

Uma vez que o Runner está conectado, você envia benchmarks da mesma forma que com qualquer Bare Metal Runner: construa e publique uma Image, depois execute bencher run --image com uma Spec correspondente. O diagrama abaixo mostra o caminho completo, desde o registro do Runner até a execução de um Job.

Continue: Referência da CLI runner ➡