Self-Hosted Bare Metal Runner

Self-Hosted Runner — это Bare Metal Runner, который вы запускаете и которым управляете сами, вместо использования управляемого Bencher On-Demand или Dedicated Runner. Вы указываете бинарному файлу runner API-сервер Bencher, и он берёт и выполняет Job на вашем собственном оборудовании.

Самостоятельное размещение Runner подходит, когда вы хотите:

• Запускать бенчмарки на определённом оборудовании, которое не предлагает Bencher Cloud
• Держать benchmark-нагрузки внутри собственной сети или в изолированной (air-gapped) среде
• Запускать Bencher Self-Hosted от начала до конца

Это руководство проведёт вас через регистрацию Runner, описание его оборудования с помощью Spec, связывание двух сущностей вместе и запуск бинарного файла runner. Концептуальный обзор того, как Runner, Spec, Sandbox и Job сочетаются друг с другом, смотрите в обзоре Bare Metal.

🐰 Изоляция через Firecracker требует Linux с включённым KVM. Runner, обслуживающий только не изолированные Spec, может работать на любом поддерживаемом хосте.

Создание Runner

Runner — это ресурс, который аутентифицирует бинарный файл runner на вашем API-сервере Bencher. Создайте его с помощью CLI bencher, REST API для Runners или Bencher Console.

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

Bencher возвращает новый Runner вместе с его ключом:

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

Ключ показывается только один раз, поэтому сохраните его в надёжном месте. Вы передадите его бинарному файлу runner при запуске Runner. Если ключ когда-либо потерян или скомпрометирован, замените его с помощью API POST /v0/runners/{runner}/key, что немедленно делает предыдущий ключ недействительным.

Создание Spec

Spec описывает оборудование, которое предоставляет Runner: операционную систему, архитектуру CPU, тип Sandbox, количество CPU, память, диск и сетевой доступ. Job объявляет нужный ему Spec, а Runner берёт только те Job, чьи Spec он поддерживает.

Создайте Spec с помощью CLI bencher, REST API для Specs или 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

Опустите --sandbox, чтобы определить не изолированный Spec, и передайте --network, если Job на этом Spec разрешён сетевой доступ. Память и диск указываются в байтах. Подробнее о Spec и о том, как Testbed записывает Spec, использованный для каждого Report, смотрите в Testbeds и Specs.

Назначение Spec для Runner

Runner Spec связывает Spec с Runner. Runner может поддерживать несколько Spec, а Spec может поддерживаться несколькими Runner. Runner берёт только те Job, чей Spec ему назначен.

Добавьте Spec к Runner с помощью CLI bencher или REST API для Runner Specs:

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

Удалить связь позже можно с помощью API DELETE /v0/runners/{runner}/specs/{spec}.

Запуск Runner

После того как Runner создан и назначен хотя бы один Spec, запустите бинарный файл runner на вашем оборудовании с помощью runner up. Укажите хост API-сервера, UUID или slug Runner и ключ Runner, либо в виде флагов, либо в виде переменных окружения:

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

Бинарный файл runner открывает одно WebSocket-соединение с API-сервером, опрашивает на наличие Job, соответствующих его Spec, выполняет каждую и сообщает результаты обратно. Соединение остаётся открытым между Job, и бинарный файл обновляет себя между Job, когда доступна новая версия.

По умолчанию Runner отклоняет любую Job, чей Spec не имеет Sandbox. Чтобы разрешить Runner выполнять не изолированные Job напрямую на хосте, запустите его с флагом --danger-allow-no-sandbox.

• runner up

  
  

  runner up

  Запускает runner, который опрашивает сервер и выполняет benchmark Job. Это долго работающая команда, используемая для работы с Self-Hosted Runner. Runner открывает одно WebSocket-соединение с API-сервером, берёт Job, соответствующие его Spec, выполняет их и сообщает результаты обратно.

  runner up [OPTIONS]

  Опции

  --host <HOST>

  API-сервер Bencher, к которому подключаться. По умолчанию используется https://api.bencher.dev. Также может быть задано переменной окружения BENCHER_HOST.

  --runner <RUNNER>

  UUID или slug Runner, от имени которого работать. Также может быть задано переменной окружения BENCHER_RUNNER.

  --key <KEY>

  Ключ аутентификации Runner (bencher_runner_...), возвращённый при создании Runner. Также может быть задано переменной окружения BENCHER_RUNNER_KEY.

  --poll-timeout <POLL_TIMEOUT>

  Тайм-аут длинного опроса в секундах при ожидании Job, от 1 до 900. По умолчанию используется 55.

  --danger-allow-no-sandbox

  Разрешить выполнение Job без Sandbox. Без этого флага Job, чей Spec не имеет Sandbox, отклоняется во время выполнения. Не изолированные Job выполняются напрямую на хосте, поэтому включайте это только для доверенных нагрузок. Также может быть задано переменной окружения BENCHER_DANGER_ALLOW_NO_SANDBOX.

  --sandbox-log-level <SANDBOX_LOG_LEVEL>

  Уровень логирования для процесса sandbox. По умолчанию используется warning.

  --no-auto-update

  Отключить автоматические обновления с сервера. По умолчанию runner обновляет себя между Job, когда сервер предлагает новую версию. Также может быть задано переменной окружения BENCHER_NO_AUTO_UPDATE.

  --max-download-size <MAX_DOWNLOAD_SIZE>

  Максимальный размер загрузки в байтах для бинарных файлов самообновления. По умолчанию используется 500 MiB. Конфликтует с --no-auto-update.

  --max-output-size <MAX_OUTPUT_SIZE>

  Максимальный размер в байтах для собираемых stdout и stderr. По умолчанию используется 25 MiB.

  --max-file-count <MAX_FILE_COUNT>

  Максимальное количество выходных файлов для декодирования. По умолчанию используется 255.

  --max-symlinks <MAX_SYMLINKS>

  Максимальное количество символических ссылок, по которым следует переходить при разрешении путей, соответствующее ограничению MAXSYMLINKS ядра Linux. По умолчанию используется 40. Используется только в не изолированном режиме.

  --grace-period <GRACE_PERIOD>

  Льготный период в секундах после завершения бенчмарка перед итоговым сбором вывода.

  Тонкая настройка хоста

  Перед каждым бенчмарком runner применяет тонкую настройку хоста, чтобы снизить шум измерений. По умолчанию он отключает ASLR, NMI watchdog, SMT / hyper-threading и turbo boost; устанавливает регулятор масштабирования частоты CPU в performance, swappiness в 10, а perf_event_paranoid в -1. Флаги ниже вместо этого оставляют отдельные оптимизации на значениях хоста по умолчанию.

  --no-tuning

  Отключить все оптимизации тонкой настройки хоста.

  --aslr

  Оставить ASLR включённым (по умолчанию: отключён для бенчмарков).

  --nmi-watchdog

  Оставить NMI watchdog включённым (по умолчанию: отключён для бенчмарков).

  --smt

  Оставить SMT / hyper-threading включённым (по умолчанию: отключён для бенчмарков).

  --turbo

  Оставить turbo boost включённым (по умолчанию: отключён для бенчмарков).

  --swappiness <SWAPPINESS>

  Установить значение swappiness. По умолчанию используется 10.

  --governor <GOVERNOR>

  Установить регулятор масштабирования частоты CPU. По умолчанию используется performance.

  --perf-event-paranoid <PERF_EVENT_PARANOID>

  Установить значение perf_event_paranoid. По умолчанию используется -1.

  --help

  Вывести справку.

Все опции смотрите в справочнике по CLI runner, а сообщения, которыми обмениваются с сервером, — в справочнике по Runner Protocol.

Рабочий процесс Self-Hosted Runner

Как только Runner подключён, вы отправляете бенчмарки так же, как и с любым Bare Metal Runner: соберите и отправьте Image, затем запустите bencher run --image с соответствующим Spec. Диаграмма ниже показывает полный путь, от регистрации Runner до выполнения Job.

Продолжайте: справочник по CLI runner ➡