Kjør en flåteworker

Kjør cc_worker på en ledig maskin for å legge til utførelseskapasitet i flåten din. Den er en ren-Dart-binær — ingen Flutter-motor — som parer seg med en cc_server, annonserer vertens kapabiliteter, sender heartbeat, henter leide jobber, utfører dem og strømmer prosesshendelser tilbake. Den har ingen varig tilstand: en supervisor starter den på nytt, og den registrerer seg på nytt.

Du trenger en kjørende cc_server først — se Kjør en headless server.

En paret worker registrerer seg, sender heartbeat og venter på leide jobber. Send inn arbeid med fleet.submitJob. Agentutsending på denne serveren går ikke gjennom flåten; suksesssignalet for denne veiledningen er at workeren vises i flåtepanelet med et ferskt heartbeat. Workeren i prosessen som registreres ved oppstart, har et tomt kjørerkart, så en jobb som plasseres på den, returnerer No local runner for job kind ….

Forutsetninger

Dart SDK. Dette repoet låser SDK-en sin med fvm, så kommandoer må prefikses med fvm.
Dette repoet utsjekket på worker-maskinen.
En tilgjengelig cc_server (loopback for utvikling, LAN eller ekstern for produksjon).
git på PATH — workeren materialiserer repoer og kjører git-sonderinger.

Steg 1: Bygg binæren

cd apps/cc_worker
fvm dart build cli

Dette produserer en selvstendig pakke i ./build/cli/<os_arch>/bundle/bin/cc_worker.

Steg 2: Utsted workerens legitimasjon

En cc_server godtar bare en worker som fremviser en id for en paret enhet og en forhåndsdelt nøkkel — også for en loopback-server. Utsted dem på server-maskinen (pair kan kjøres mens serveren er oppe; den nye enheten plukkes opp uten omstart):

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

Den skriver ut en Device id og en Pairing key — det er disse --device-id og --psk / --psk-file / CC_WORKER_PSK tar.

Steg 3: Start workeren

Mot en paret 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 (fortsatt paret — cc_server kjører alltid PSK-håndtrykket):

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

Flagg	Beskrivelse	Standard
`--server <url>`	cc_server-URL (`ws://`/`wss://`; `http(s)` og en manglende `/rpc`-sti tvinges). Påkrevd.	—
`--name <name>`	Operatørvendt workernavn.	vertsnavn
`--device-id <id>`	Stabil id for en paret enhet, brukes også som worker-id.	`cc-worker`
`--psk-file <path>`	Fil der første ikke-tomme linje er paringsnøkkelen. Foretrukket fremfor `--psk`.	—
`--psk <key>`	Paringsnøkkel på kommandolinjen. Synlig i `ps` og skallhistorikken — binæren advarer.	—
`--max-jobs <n>`	Hardt tak på antall jobber denne prosessen utfører samtidig (positivt heltall).	`4`

Rekkefølgen for oppslag av nøkkelen er --psk-file → CC_WORKER_PSK → --psk. Utelater du alle kildene, hoppes workerens autentiseringshåndtrykk over; en ekte cc_server avviser da økten (auth_denied) i stedet for å godta en uautentisert worker. Ukjente flagg er en bruksfeil (exit 64) — i motsetning til cc_server bruker denne binæren package:args og overser ikke skrivefeil.

CC_WORKER_CACHE overstyrer katalogen for hurtiglageret for worktree-materialisering (standard: en cc_worker_cache-katalog under systemets temp-katalog).

Workeren registrerer seg med fleet.registerWorker, sender deretter heartbeat hvert 20. sekund og poller etter leases hvert 2. sekund. Den kjører til SIGINT/SIGTERM; legg den under systemd eller launchd, slik at den starter på nytt og registrerer seg på nytt etter et krasj eller en omstart.

Steg 4: Verifiser den i flåtepanelet

Åpne Observabilitet i skrivebords- eller nettappen, bytt til Live-fanen og rull til bunnen. Workere viser hver registrerte worker med plattform, kjerner, kapabilitetsnøkler og siste heartbeat; Jobber viser jobbene som er fordelt på dem.

At workeren din vises der med et nylig heartbeat, bekrefter at parring og registrering fungerte.

Fra flisen til en worker kan du tømme den (fullføre gjeldende jobber, ikke ta nye leases), fortsette en worker som tømmes, tilbakekalle legitimasjonen dens eller fjerne raden.

Worker- og jobbrader ligger i serverens global.db — workeren selv skriver ingenting til disk utover hurtiglageret for materialisering.

Hva workeren annonserer

Ved registrering oppdager workeren kapabilitetene sine automatisk, og planleggeren matcher jobber mot dem. Du konfigurerer ikke disse for hånd:

OS og arkitektur (macos/linux/windows, arm64/x64) — nøyaktige sonderinger, med fallback til uname -m / PROCESSOR_ARCHITECTURE
Kjerner og RAM — nøyaktig antall kjerner; RAM degraderes til 0 når det ikke kan sondres
flutter — settes når et Flutter-SDK er tilgjengelig (bare flutter, deretter fvm flutter); golden-render-jobber krever det
sandbox — native-macos på macOS, native-linux på Linux. Dette er et plasseringshint, ikke et løfte: workeren annonserer backenden plattformen dens har, men den pakker ikke jobbene den kjører, inn i en. I motsetning til cc_server starter cc_worker en leaset jobb direkte
always-on og parallel — en dedikert cc_worker annonserer alltid begge, så den er kvalifisert for eval-batcher og annen parallell kapasitet til engangsbruk

Oppdagelsen gjøres så godt den kan: alt den ikke klarer å sondre, degraderes til en trygg standard i stedet for å få oppstarten til å feile.

Hva workeren ville utføre

Lease-protokollen bærer seks jobbtyper:

Type	Hva det er
`agentRun`	Én enkelt agentkjøring (utsending)
`pipelineStep`	Utførelse av et pipeline-steg
`codeIndex`	En bygging av en repo-kodeindeks
`goldenRender`	En visuell golden-render av UI (krever `flutter`)
`benchmark`	En ytelsesbenchmark-kjøring
`evalBatch`	En eval-batch (foretrekker `parallel`-kapasitet)

Utførelsen er en ekte underprosess-strømmende implementasjon, ikke en fullstendig innebygd agent-runtime. Når en lease bærer repoRemote, gjør workeren git clone --depth 1 inn i en hurtiglagerkatalog nøklet på remote og SHA, deretter git fetch og git checkout. For agentRun kjører den kommandoen i CC_JOB_COMMAND fra lease-miljøet i arbeidskatalogen og strømmer stdout og stderr tilbake som hendelser; uten CC_JOB_COMMAND ekkoer den prompten, slik at transporten fortsatt blir prøvd ende til ende. De andre typene kjører små, ekte kommandoer (git rev-parse HEAD, git --version) som ærlige sonderinger. Legitimasjon med jobbomfang i lease-miljøet injiseres i hver underprosess og skrives aldri til en logg.

Hendelser samles i batcher og skyves ut hvert 250 ms eller for hver 32. hendelse; hver jobb avsluttes med en ferdig-hendelse og en fullføringsrapport. Modellen er heartbeat pluss leases med kort levealder: hvis en worker mister kontakten, utløper leasen, og serveren rydder opp jobben for nytt forsøk. Det finnes ingen varig tilstand på workeren, og ingen konsensus eller arbeidsstjeling mellom workere.

Relaterte veiledninger

Relaterte konsepter

Drift og klienter