Rulează un worker din flotă

Rulează cc_worker pe o mașină disponibilă ca să adaugi capacitate de execuție flotei tale. Este un binar scris în pur Dart — fără motor Flutter — care se asociază cu un cc_server, își declară capabilitățile gazdei, trimite heartbeat-uri, trage joburi concesionate, le execută și transmite înapoi evenimente de proces. Nu păstrează nicio stare durabilă: un supervisor îl repornește, iar el se reînregistrează.

Ai nevoie mai întâi de un cc_server care rulează — vezi Rulează un server headless.

Un worker asociat se înregistrează, trimite heartbeat-uri și așteaptă joburi concesionate. Trimite munca cu fleet.submitJob. Trimiterea agenților pe acest server nu trece prin flotă; semnalul de succes pentru acest ghid este apariția workerului în panoul flotei cu un heartbeat recent. Workerul în proces, înregistrat la pornire, are o hartă de runneri goală, așa că un job plasat pe el returnează No local runner for job kind ….

Cerințe preliminare

Dart SDK. Acest repo își fixează SDK-ul cu fvm, așa că prefixează comenzile cu fvm.
Acest repository clonat pe mașina workerului.
Un cc_server accesibil (loopback pentru dezvoltare, LAN sau remote pentru producție).
git în PATH — workerul materializează repo-uri și rulează sonde git.

Pasul 1: Construiește binarul

cd apps/cc_worker
fvm dart build cli

Aceasta produce un pachet autonom la ./build/cli/<os_arch>/bundle/bin/cc_worker.

Pasul 2: Emite acreditarea workerului

Un cc_server acceptă doar un worker care prezintă un id de dispozitiv asociat și o cheie pre-partajată — inclusiv un server loopback. Emite-le pe mașina server (pair poate rula cât timp serverul este pornit; noul dispozitiv este preluat fără repornire):

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

Afișează un Device id și o Pairing key — acestea sunt valorile pe care le primesc --device-id și --psk / --psk-file / CC_WORKER_PSK.

Pasul 3: Pornește workerul

Cu un server asociat:

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

Cu un server loopback (tot asociat — cc_server rulează mereu handshake-ul PSK):

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

Flag	Descriere	Implicit
`--server <url>`	URL-ul cc_server (`ws://`/`wss://`; `http(s)` și o cale `/rpc` lipsă sunt forțate). Obligatoriu.	—
`--name <name>`	Numele workerului afișat operatorului.	numele gazdei
`--device-id <id>`	Id stabil de dispozitiv asociat, folosit și ca id al workerului.	`cc-worker`
`--psk-file <path>`	Fișier a cărui primă linie nevidă este cheia de asociere. Preferat în locul `--psk`.	—
`--psk <key>`	Cheia de asociere pe linia de comandă. Vizibilă în `ps` și în istoricul shell-ului — binarul avertizează.	—
`--max-jobs <n>`	Plafon dur al joburilor executate concurent de acest proces (întreg pozitiv).	`4`

Ordinea de rezoluție pentru cheie este --psk-file → CC_WORKER_PSK → --psk. Omiterea tuturor surselor sare peste handshake-ul de autentificare al workerului; un cc_server real respinge atunci sesiunea (auth_denied) în loc să accepte un worker neautentificat. Flag-urile necunoscute sunt o eroare de utilizare (exit 64) — spre deosebire de cc_server, acest binar folosește package:args și nu ignoră greșelile de tastare.

CC_WORKER_CACHE suprascrie directorul de cache pentru materializarea worktree-urilor (implicit: un director cc_worker_cache în directorul temporar al sistemului).

Workerul se înregistrează cu fleet.registerWorker, apoi trimite heartbeat-uri la fiecare 20s și interoghează concesiunile la fiecare 2s. Rulează până la SIGINT/SIGTERM; pune-l sub systemd sau launchd ca să repornească și să se reînregistreze după o cădere sau o repornire.

Pasul 4: Verifică-l în panoul flotei

Deschide Observabilitate în aplicația desktop sau web, comută pe fila Live și derulează până jos. Workeri listează fiecare worker înregistrat, cu platforma, nucleele, cheile de capabilități și ultimul heartbeat; Joburi listează joburile distribuite între ei.

Apariția workerului tău acolo, cu un heartbeat recent, este confirmarea că asocierea și înregistrarea au funcționat.

Din plăcuța unui worker poți să-l drenezi (termină joburile curente, nu mai preia concesiuni noi), să reiei un worker aflat în drenare, să-i revoci acreditarea sau să elimini rândul.

Rândurile workerilor și ale joburilor stau în global.db al serverului — workerul însuși nu scrie nimic pe disc în afara cache-ului de materializare.

Ce anunță workerul

La înregistrare, workerul își detectează automat capabilitățile, iar planificatorul potrivește joburile cu ele. Nu le configurezi manual:

Sistemul de operare și arhitectura (macos/linux/windows, arm64/x64) — sonde exacte, cu variante de rezervă uname -m / PROCESSOR_ARCHITECTURE
Nuclee și RAM — număr exact de nuclee; RAM degradează la 0 când nu poate fi sondată
flutter — setată când un SDK Flutter este accesibil (flutter simplu, apoi fvm flutter); joburile de golden-render o cer
sandbox — native-macos pe macOS, native-linux pe Linux. Acesta este un indiciu de plasare, nu o promisiune: workerul anunță backend-ul pe care platforma lui îl are, dar nu înfășoară joburile pe care le rulează într-unul. Spre deosebire de cc_server, cc_worker lansează direct un job concesionat
always-on și parallel — un cc_worker dedicat le anunță mereu pe ambele, așa că este eligibil pentru loturi de eval și pentru alte capacități paralele de unică folosință

Detectarea se face în măsura posibilităților: orice nu poate fi sondat degradează la o valoare implicită sigură, în loc să facă pornirea să eșueze.

Ce ar executa workerul

Protocolul de concesionare transportă șase tipuri de joburi:

Tip	Ce este
`agentRun`	O singură rulare de agent (trimitere)
`pipelineStep`	Execuția unui pas de pipeline
`codeIndex`	O construcție a indexului de cod al unui repo
`goldenRender`	O randare golden vizuală de UI (necesită `flutter`)
`benchmark`	O rulare de benchmark de performanță
`evalBatch`	Un lot de eval (preferă capacitatea `parallel`)

Execuția este o implementare reală care transmite subprocese în flux, nu un runtime complet de agent integrat. Când o concesiune transportă repoRemote, workerul face git clone --depth 1 într-un director de cache cheiat după remote și SHA, apoi git fetch și git checkout. Pentru agentRun rulează comanda din CC_JOB_COMMAND a mediului concesiunii în directorul de lucru, transmite stdout și stderr înapoi ca evenimente; fără CC_JOB_COMMAND ecouiază promptul, astfel încât transportul este totuși exercitat cap-coadă. Celelalte tipuri rulează comenzi reale mici (git rev-parse HEAD, git --version) ca sonde oneste. Acreditările limitate la job din mediul concesiunii sunt injectate în fiecare subproces și nu sunt scrise niciodată într-un jurnal.

Evenimentele sunt grupate și descărcate la fiecare 250ms sau la fiecare 32 de evenimente; fiecare job se încheie cu un eveniment done și un raport de finalizare. Modelul este heartbeat-uri plus concesiuni cu TTL scurt: dacă un worker pierde contactul, concesiunea lui expiră, iar serverul recuperează jobul pentru o nouă încercare. Nu există stare durabilă pe worker și nici consens sau furt de lucru între workeri.

Ghiduri conexe

Concepte conexe

Implementare și clienți