Запустить воркер флота
Запустите cc_worker на запасной машине, чтобы добавить своему флоту мощности для
выполнения заданий. Это бинарник на чистом Dart — без движка Flutter, — который
сопрягается с cc_server, объявляет возможности хоста, отправляет heartbeat,
забирает арендованные задания, выполняет их и транслирует события процессов
обратно. Он не хранит долговременного состояния: супервизор перезапускает его, и
он регистрируется заново.
Сначала вам нужен работающий cc_server — см. Запустить headless-сервер.
Сопряжённый воркер регистрируется, отправляет heartbeat и ждёт арендованных
заданий. Работу отправляйте через fleet.submitJob. Диспетчеризация агентов на
этом сервере не идёт через флот; признак успеха в этом руководстве — появление
воркера в панели флота со свежим heartbeat. Внутрипроцессный воркер,
зарегистрированный при запуске, имеет пустую карту исполнителей, поэтому задание,
помещённое на него, возвращает No local runner for job kind ….
Прежде чем начать
Заголовок раздела «Прежде чем начать»- Dart SDK. В этом репозитории SDK закреплён через fvm, поэтому команды нужно предварять
fvm. - Этот репозиторий, склонированный на машине воркера.
- Доступный по сети
cc_server(loopback для разработки, локальная сеть или удалённый хост для продакшена). gitвPATH— воркер материализует репозитории и выполняет пробыgit.
Шаг 1. Сборка бинарника
Заголовок раздела «Шаг 1. Сборка бинарника»cd apps/cc_workerfvm dart build cliВ результате создаётся автономный бандл по пути ./build/cli/<os_arch>/bundle/bin/cc_worker.
Шаг 2. Выпуск учётных данных воркера
Заголовок раздела «Шаг 2. Выпуск учётных данных воркера»cc_server принимает только воркер, предъявивший id парного устройства и
предварительно распределённый ключ, — включая сервер на loopback. Выпустите их на
машине сервера (pair можно запустить, пока сервер работает; новое устройство
подхватывается без перезапуска):
cc_server pair --data-dir <dir> --device my-worker --label "Build box"Он выводит Device id и Pairing key — именно их принимают --device-id и
--psk / --psk-file / CC_WORKER_PSK.
Шаг 3. Запуск воркера
Заголовок раздела «Шаг 3. Запуск воркера»С сопряжённым сервером:
./build/cli/<os_arch>/bundle/bin/cc_worker \ --server wss://host:9030 --device-id my-worker --psk-file /path/to/worker.pskС сервером на loopback (он всё равно сопряжён — cc_server всегда выполняет
PSK-рукопожатие):
fvm dart run cc_worker --server ws://localhost:9030 \ --device-id my-worker --psk-file /path/to/worker.psk| Флаг | Описание | По умолчанию |
|---|---|---|
--server <url> |
URL cc_server (ws:///wss://; http(s) и отсутствующий путь /rpc приводятся к нужному виду). Обязательно. |
— |
--name <name> |
Имя воркера, видимое оператору. | имя хоста |
--device-id <id> |
Стабильный id парного устройства, он же id воркера. | cc-worker |
--psk-file <path> |
Файл, первая непустая строка которого — ключ сопряжения. Предпочтительнее --psk. |
— |
--psk <key> |
Ключ сопряжения в командной строке. Виден в ps и истории оболочки — бинарник предупреждает об этом. |
— |
--max-jobs <n> |
Жёсткий потолок числа заданий, которые этот процесс выполняет одновременно (положительное целое). | 4 |
Порядок разрешения ключа — --psk-file → CC_WORKER_PSK → --psk. Если не
указан ни один источник, воркер пропускает рукопожатие аутентификации; настоящий
cc_server в этом случае отклоняет сессию (auth_denied), а не принимает
неаутентифицированный воркер. Неизвестные флаги — ошибка использования
(exit 64): в отличие от cc_server, этот бинарник использует package:args и не
игнорирует опечатки.
CC_WORKER_CACHE переопределяет каталог кэша материализации рабочих деревьев (по
умолчанию — каталог cc_worker_cache во временном каталоге системы).
Воркер регистрируется через fleet.registerWorker, затем каждые 20 с отправляет
heartbeat и каждые 2 с опрашивает аренды. Он работает до SIGINT/SIGTERM;
поставьте его под systemd или launchd, чтобы после сбоя или перезагрузки он
перезапускался и регистрировался заново.
Шаг 4. Проверка в панели флота
Заголовок раздела «Шаг 4. Проверка в панели флота»Откройте Наблюдаемость в настольном или веб-приложении, перейдите на вкладку Онлайн и прокрутите вниз. Воркеры перечисляет всех зарегистрированных воркеров с их платформой, ядрами, ключами возможностей и последним heartbeat; Задания перечисляет задания, распределённые между ними.
Появление вашего воркера там со свежим heartbeat подтверждает, что сопряжение и регистрация сработали.
С плитки воркера можно дренировать его (завершить текущие задания и не брать новые аренды), возобновить освобождающийся воркер, отозвать его учётные данные или удалить строку.
Строки воркеров и заданий хранятся в global.db сервера — сам воркер ничего не
пишет на диск, кроме кэша материализации.
Что воркер о себе объявляет
Заголовок раздела «Что воркер о себе объявляет»При регистрации воркер автоматически определяет свои возможности, и планировщик сопоставляет с ними задания. Вручную их настраивать не нужно:
- ОС и архитектура (
macos/linux/windows,arm64/x64) — точные пробы с откатом наuname -m/PROCESSOR_ARCHITECTURE - Ядра и ОЗУ — точное число ядер; объём ОЗУ понижается до
0, когда его не удаётся определить flutter— устанавливается, когда доступен Flutter SDK (сначала обычныйflutter, затемfvm flutter); задания golden-рендера требуют егоsandbox—native-macosв macOS,native-linuxв Linux. Это подсказка для размещения, а не обещание: воркер объявляет бэкенд, который есть у его платформы, но не оборачивает выполняемые задания в него. В отличие отcc_server,cc_workerзапускает арендованное задание напрямуюalways-onиparallel— выделенныйcc_workerвсегда объявляет оба, поэтому он подходит для пакетов eval и другой одноразовой параллельной работы
Обнаружение выполняется по мере возможностей: всё, что не удаётся определить, понижается до безопасного значения по умолчанию, а не приводит к сбою при запуске.
Что воркер стал бы выполнять
Заголовок раздела «Что воркер стал бы выполнять»Протокол аренды переносит шесть видов заданий:
| Вид | Что это |
|---|---|
agentRun |
Один запуск агента (диспетчеризация) |
pipelineStep |
Выполнение шага конвейера |
codeIndex |
Сборка индекса кода репозитория |
goldenRender |
Визуальный golden-рендер интерфейса (требует flutter) |
benchmark |
Запуск теста производительности |
evalBatch |
Пакет eval (предпочитает мощность parallel) |
Выполнение — это настоящая реализация с потоковой трансляцией подпроцессов, а не
полноценная встроенная среда выполнения агентов. Когда аренда несёт repoRemote,
воркер выполняет git clone --depth 1 в каталог кэша с ключом по удалённому
репозиторию и SHA, затем git fetch и git checkout. Для agentRun он выполняет
в рабочем каталоге команду из CC_JOB_COMMAND окружения аренды, транслируя stdout
и stderr обратно в виде событий; если CC_JOB_COMMAND нет, он возвращает промпт
эхом, чтобы транспорт всё равно был проверен от начала до конца. Остальные виды
выполняют небольшие настоящие команды (git rev-parse HEAD, git --version) как
честные пробы. Учётные данные уровня задания из окружения аренды внедряются в
каждый подпроцесс и никогда не попадают в журнал.
События группируются и сбрасываются каждые 250 мс или каждые 32 события; каждое задание завершается событием done и отчётом о выполнении. Модель — это heartbeat плюс аренды с коротким TTL: если воркер теряет связь, его аренда истекает, и сервер забирает задание на повтор. На воркере нет долговременного состояния, а между воркерами нет ни консенсуса, ни перехвата работы.