Kör en fleet-worker

Kör cc_worker på en ledig maskin för att lägga till körkapacitet i flottan. Det är en binär i ren Dart – ingen Flutter-motor – som parkopplas med en cc_server, deklarerar värdens kapabiliteter, skickar heartbeat, hämtar leasade jobb, utför dem och strömmar processhändelser tillbaka. Den håller inget varaktigt tillstånd: en övervakare startar om den och den registrerar sig på nytt.

Du behöver en körande cc_server först – se Kör en headless-server.

En parkopplad worker registrerar sig, skickar heartbeat och väntar på leasade jobb. Skicka in arbete med fleet.submitJob. Agentdispatch på den här servern går inte via flottan; framgångssignalen för den här guiden är att workern dyker upp i flottpanelen med en färsk heartbeat. Den worker som körs i samma process och registreras vid start har en tom runner-map, så ett jobb som placeras på den returnerar No local runner for job kind ….

Förutsättningar

Dart SDK. Det här repot låser sin SDK med fvm, så prefixa kommandon med fvm.
Det här repot utcheckat på worker-maskinen.
En nåbar cc_server (loopback för utveckling, LAN eller fjärr i produktion).
git i PATH – workern materialiserar repon och kör git-sonderingar.

Steg 1: Bygg binären

cd apps/cc_worker
fvm dart build cli

Det här skapar ett fristående paket på ./build/cli/<os_arch>/bundle/bin/cc_worker.

Steg 2: Utfärda workerns autentiseringsuppgift

En cc_server accepterar bara en worker som uppvisar ett id för parkopplad enhet och en i förväg delad nyckel – även en loopback-server. Utfärda dem på server-maskinen (pair kan köras medan servern är uppe; den nya enheten plockas upp utan omstart):

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

Den skriver ut ett Device id och en Pairing key – det är vad --device-id och --psk / --psk-file / CC_WORKER_PSK tar.

Steg 3: Starta workern

Mot en parkopplad server:

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

Mot en loopback-server (fortfarande parkopplad – cc_server kör alltid PSK-handskakningen):

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

Flagga	Beskrivning	Standard
`--server <url>`	cc_server-URL (`ws://`/`wss://`; `http(s)` och en saknad `/rpc`-sökväg tvingas till rätt form). Obligatorisk.	—
`--name <name>`	Workerns namn, så som operatören ser det.	värdnamn
`--device-id <id>`	Stabilt id för parkopplad enhet, används också som worker-id.	`cc-worker`
`--psk-file <path>`	Fil vars första icke-tomma rad är parkopplingsnyckeln. Föredras framför `--psk`.	—
`--psk <key>`	Parkopplingsnyckel på kommandoraden. Synlig i `ps` och skalhistoriken – binären varnar.	—
`--max-jobs <n>`	Hårt tak för hur många jobb den här processen kör samtidigt (positivt heltal).	`4`

Upplösningsordningen för nyckeln är --psk-file → CC_WORKER_PSK → --psk. Om du utelämnar alla källor hoppas workerns autentiseringshandskakning över; en riktig cc_server nekar då sessionen (auth_denied) i stället för att acceptera en oautentiserad worker. Okända flaggor är ett användningsfel (exit 64) – till skillnad från cc_server använder den här binären package:args och ignorerar inte felstavningar.

CC_WORKER_CACHE åsidosätter cachekatalogen för worktree-materialisering (standard: en katalog cc_worker_cache under systemets temp-katalog).

Workern registrerar sig med fleet.registerWorker och skickar sedan heartbeat var 20:e sekund och söker efter leases var 2:a sekund. Den körs tills SIGINT/SIGTERM; lägg den under systemd eller launchd så att den startar om och registrerar sig på nytt efter en krasch eller omstart.

Steg 4: Verifiera den i flottpanelen

Öppna Observability i skrivbords- eller webbappen, växla till fliken Live och rulla längst ner. Workers listar varje registrerad worker med plattform, kärnor, kapabilitetsnycklar och senaste heartbeat; Jobb listar jobben som fördelats över dem.

Att din worker dyker upp där med en färsk heartbeat bekräftar att parkopplingen och registreringen fungerade.

Från en workers ruta kan du tömma den (avsluta pågående jobb, ta inga nya leases), återuppta en worker som töms, återkalla dess autentiseringsuppgift eller ta bort raden.

Rader för workers och jobb finns i serverns global.db – workern själv skriver inget till disk utöver materialiseringscachen.

Vad workern annonserar

Vid registreringen identifierar workern automatiskt sina kapabiliteter och schemaläggaren matchar jobb mot dem. Du konfigurerar dem inte för hand:

OS och arkitektur (macos/linux/windows, arm64/x64) – exakta sonderingar, med reservvägar till uname -m / PROCESSOR_ARCHITECTURE
Kärnor och RAM – exakt antal kärnor; RAM degraderar till 0 när det inte går att sondera
flutter – sätts när ett Flutter SDK är nåbart (bart flutter, sedan fvm flutter); golden-render-jobb kräver det
sandbox – native-macos på macOS, native-linux på Linux. Det här är en ledtråd för placeringen, inte ett löfte: workern annonserar den backend som plattformen har, men den lindar inte in jobben den kör i en sådan. Till skillnad från cc_server startar cc_worker ett leasat jobb direkt
always-on och parallel – en dedikerad cc_worker annonserar alltid båda, så den är valbar för eval-batcher och annan tillfällig parallell kapacitet

Identifieringen sker i bästa möjliga mån: allt den inte kan sondera degraderar till ett säkert standardvärde i stället för att starten misslyckas.

Vad workern skulle köra

Lease-protokollet bär sex jobbtyper:

Typ	Vad det är
`agentRun`	En enskild agentkörning (dispatch)
`pipelineStep`	En körning av ett pipelinesteg
`codeIndex`	En byggnad av ett repos kodindex
`goldenRender`	En visuell golden-render av ett gränssnitt (kräver `flutter`)
`benchmark`	En prestandabenchmark-körning
`evalBatch`	En eval-batch (föredrar `parallel`-kapacitet)

Körningen är en riktig implementation med subprocess-strömning, inte en komplett inbäddad agentruntime. När en lease bär repoRemote gör workern git clone --depth 1 till en cachekatalog som nycklas på remote och SHA, sedan git fetch och git checkout. För agentRun kör den kommandot i leasens miljö CC_JOB_COMMAND i arbetskatalogen och strömmar stdout och stderr tillbaka som händelser; utan CC_JOB_COMMAND ekar den prompten så att transporten ändå prövas från ände till ände. De andra typerna kör små riktiga kommandon (git rev-parse HEAD, git --version) som ärliga sonderingar. Autentiseringsuppgifter med jobbomfattning i leasens miljö injiceras i varje subprocess och skrivs aldrig till någon logg.

Händelser samlas i batchar och spolas ut var 250:e ms eller var 32:a händelse; varje jobb avslutas med en done-händelse och en slutföranderapport. Modellen är heartbeat plus leases med kort TTL: om en worker tappar kontakten löper dess lease ut och servern plockar upp jobbet för nytt försök. Det finns inget varaktigt tillstånd på workern och ingen konsensus eller work-stealing mellan workers.

Relaterade guider

Relaterade koncept

Driftsättning och klienter