Spusťte worker flotily

Spusť cc_worker na volném stroji a přidej flotile kapacitu na provádění. Je to binární soubor v čistém Dartu — bez enginu Flutter — který se spáruje s cc_server, ohlásí schopnosti hostitele, posílá heartbeat, stahuje zapůjčené úlohy, provádí je a streamuje události procesu zpátky. Trvalý stav nedrží: dohled ho restartuje a on se zaregistruje znovu.

Nejdřív potřebuješ běžící cc_server — viz Spusťte headless server.

Spárovaný worker se zaregistruje, posílá heartbeat a čeká na zapůjčené úlohy. Práci odešleš přes fleet.submitJob. Odeslání agenta na tomhle serveru flotilou neprochází; znamení, že tenhle návod vyšel, je worker v panelu flotily s čerstvým heartbeatem. Worker v procesu, který se zaregistruje při startu, má prázdnou mapu runnerů, takže úloha položená na něj vrátí No local runner for job kind ….

Předpoklady

SDK Dart. Tenhle repozitář si SDK připíná přes fvm, takže příkazům předřazuj fvm.
Checkout tohohle repozitáře na stroji workera.
Dosažitelný cc_server (loopback pro vývoj, LAN nebo vzdálený stroj pro produkci).
git na PATH — worker materializuje repozitáře a spouští sondy git.

Krok 1: Sestav binární soubor

cd apps/cc_worker
fvm dart build cli

Vznikne samostatný balík v ./build/cli/<os_arch>/bundle/bin/cc_worker.

Krok 2: Vydej workerovi pověření

cc_server přijme jen workera, který předloží id spárovaného zařízení a předem sdílený klíč — i server na loopbacku. Vydej je na stroji serveru (pair může běžet, i když server už běží; nové zařízení se vezme bez restartu):

cc_server pair --data-dir <dir> --device my-worker --label "Build box"

Vypíše Device id a Pairing key — právě ty bere --device-id a --psk / --psk-file / CC_WORKER_PSK.

Krok 3: Spusť workera

Na spárovaný server:

./build/cli/<os_arch>/bundle/bin/cc_worker \
  --server wss://host:9030 --device-id my-worker --psk-file /path/to/worker.psk

Na server na loopbacku (pořád spárovaný — cc_server handshake PSK spouští vždycky):

fvm dart run cc_worker --server ws://localhost:9030 \
  --device-id my-worker --psk-file /path/to/worker.psk

Příznak	Popis	Výchozí
`--server <url>`	URL cc_server (`ws://`/`wss://`; `http(s)` a chybějící cesta `/rpc` se srovnají). Povinné.	—
`--name <name>`	Název workera pro operátora.	název hostitele
`--device-id <id>`	Stabilní id spárovaného zařízení, zároveň id workera.	`cc-worker`
`--psk-file <path>`	Soubor, jehož první neprázdný řádek je párovací klíč. Lepší volba než `--psk`.	—
`--psk <key>`	Párovací klíč na příkazové řádce. Je vidět v `ps` i v historii shellu — binární soubor varuje.	—
`--max-jobs <n>`	Tvrdý strop úloh, které tenhle proces provádí souběžně (kladné celé číslo).	`4`

Klíč se bere v pořadí --psk-file → CC_WORKER_PSK → --psk. Když vynecháš všechny zdroje, worker přeskočí handshake autentizace; skutečný cc_server pak relaci odmítne (auth_denied) a neautentizovaného workera nepřijme. Neznámé příznaky jsou chyba použití (exit 64) — na rozdíl od cc_server tenhle binární soubor používá package:args a překlepy neignoruje.

CC_WORKER_CACHE přepíše adresář cache pro materializaci worktree (výchozí: adresář cc_worker_cache v systémovém dočasném adresáři).

Worker se registruje přes fleet.registerWorker, pak posílá heartbeat každých 20 s a na zapůjčení se ptá každé 2 s. Běží, dokud nedostane SIGINT/SIGTERM; dej ho pod systemd nebo launchd, ať se po pádu nebo restartu znovu spustí a zaregistruje.

Krok 4: Ověř ho v panelu flotily

V desktopové nebo webové aplikaci otevři Observabilita, přepni na záložku Živé a sjeď dolů. Workeři vypíšou každého zaregistrovaného workera s platformou, jádry, klíči schopností a posledním heartbeatem; Úlohy vypíšou úlohy rozdělené mezi ně.

Když se tam tvůj worker objeví s čerstvým heartbeatem, párování i registrace prošly.

Z dlaždice workera ho můžeš Vypustit (dokončí aktuální úlohy a nové zapůjčení nevezme), Obnovit workera ve vypouštění, Odvolat jeho pověření, nebo řádek Odebrat.

Řádky workerů a úloh žijí v serverovém global.db — sám worker na disk nezapíše nic kromě cache materializace.

Co worker ohlašuje

Při registraci worker sám zjistí své schopnosti a plánovač podle nich páruje úlohy. Ručně je nenastavuješ:

OS a architektura (macos/linux/windows, arm64/x64) — přesné sondy, se zálohou na uname -m / PROCESSOR_ARCHITECTURE
Jádra a RAM — přesný počet jader; RAM spadne na 0, když se sonda nepodaří
flutter — nastaví se, když je dosažitelný Flutter SDK (holé flutter, pak fvm flutter); úlohy golden render ho vyžadují
sandbox — native-macos na macOS, native-linux na Linuxu. Je to nápověda pro umístění, ne slib: worker ohlašuje backend, který jeho platforma má, ale úlohy, které spouští, do něj nebalí. Na rozdíl od cc_server spouští cc_worker zapůjčenou úlohu přímo
always-on a parallel — vyhrazený cc_worker ohlašuje vždycky obojí, takže se hodí pro dávky eval a další jednorázovou paralelní kapacitu

Detekce sahá jen tam, kam sonda dosáhne: co neprosonduje, spadne na bezpečný výchozí stav a start kvůli tomu neselže.

Co by worker prováděl

Protokol zapůjčení nese šest druhů úloh:

Druh	Co to je
`agentRun`	Jeden běh agenta (odeslání)
`pipelineStep`	Provedení kroku pipeline
`codeIndex`	Sestavení indexu kódu repozitáře
`goldenRender`	Vizuální golden render rozhraní (vyžaduje `flutter`)
`benchmark`	Běh výkonnostního benchmarku
`evalBatch`	Dávka eval (dává přednost kapacitě `parallel`)

Provádění je skutečné streamování podprocesů, ne plný vestavěný runtime agenta. Když zapůjčení nese repoRemote, worker udělá git clone --depth 1 do adresáře cache klíčovaného remotem a SHA, pak git fetch a git checkout. U agentRun spustí v pracovním adresáři příkaz z CC_JOB_COMMAND v prostředí zapůjčení a stdout i stderr streamuje zpátky jako události; bez CC_JOB_COMMAND prompt jen ozve, aby se transport pořád procvičil od začátku do konce. Ostatní druhy spouštějí malé skutečné příkazy (git rev-parse HEAD, git --version) jako poctivé sondy. Pověření v rozsahu úlohy v prostředí zapůjčení se vloží do každého podprocesu a do logu se nikdy nezapíšou.

Události se dávkují a odesílají každých 250 ms nebo po 32 událostech; každá úloha končí událostí done a hlášením o dokončení. Model je heartbeat plus zapůjčení s krátkým TTL: když worker ztratí spojení, zapůjčení vyprší a server úlohu sebere k novému pokusu. Na workeru není trvalý stav a mezi workery není konsenzus ani kradení práce.

Související návody

Související koncepty

Nasazení a klienti