Запустити воркер флоту
Запустіть 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 приймає лише той воркер, який пред’являє ідентифікатор спарованого
пристрою та попередньо спільний ключ — зокрема й на 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> |
Стабільний ідентифікатор спарованого пристрою; він же ідентифікатор воркера. | 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 перевизначає каталог кешу матеріалізації worktree (типово:
каталог cc_worker_cache у системному тимчасовому каталозі).
Воркер реєструється через fleet.registerWorker, далі надсилає heartbeat кожні
20 с і опитує сервер щодо оренд кожні 2 с. Він працює до SIGINT/SIGTERM;
поставте його під systemd або launchd, щоб він перезапускався й реєструвався
заново після збою чи перезавантаження.
Крок 4: Перевірити його в панелі флоту
Розділ із назвою «Крок 4: Перевірити його в панелі флоту»Відкрийте Спостережуваність у настільному чи вебзастосунку, перемкніться на вкладку Наживо та прокрутіть донизу. У розділі Воркери перелічено кожен зареєстрований воркер з його платформою, ядрами, ключами можливостей та останнім heartbeat; у розділі Завдання — завдання, розподілені між ними.
Поява вашого воркера там зі свіжим heartbeat — це підтвердження, що спарювання й реєстрація спрацювали.
З плитки воркера ви можете зупинити прийом (завершити поточні завдання, не брати нових оренд), відновити воркер, який зупинив прийом, відкликати його облікові дані або вилучити рядок.
Рядки воркерів і завдань зберігаються в global.db сервера — сам воркер нічого
не пише на диск, крім кешу матеріалізації.
Що заявляє воркер
Розділ із назвою «Що заявляє воркер»Під час реєстрації воркер автоматично визначає свої можливості, і планувальник зіставляє з ними завдання. Вручну їх налаштовувати не потрібно:
- ОС та архітектура (
macos/linux/windows,arm64/x64) — точне зондування, з відкатом доuname -m/PROCESSOR_ARCHITECTURE - Ядра та RAM — точна кількість ядер; RAM знижується до
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 події; кожне завдання завершується подією завершення та звітом про виконання. Модель — це heartbeat плюс оренди з коротким TTL: якщо воркер втрачає зв’язок, його оренда спливає, і сервер забирає завдання на повторну спробу. На воркері немає довготривалого стану, а між воркерами — ні консенсусу, ні перехоплення роботи.