Flotta-worker futtatása

Futtassa a cc_worker-t egy tartalék gépen, hogy végrehajtási kapacitást adjon a flottájához. Ez egy tisztán Dart bináris — Flutter-motor nélkül —, amely párosít egy cc_server-rel, deklarálja a gazdagép képességeit, szívveréseket küld, lízingelt feladatokat húz le, hajt végre, és visszastreameli a folyamateseményeket. Nem tart fenn tartós állapotot: egy felügyelő újraindítja, és az újra regisztrál.

Először egy futó cc_server-re lesz szüksége — lásd a Headless szerver futtatása oldalt.

Egy párosított worker regisztrál, szívveréseket küld, és lízingelt feladatokra vár. A munkát a fleet.submitJob hívással adhatja be. Az ügynökök kiosztása ezen a szerveren nem a flottán keresztül történik; az útmutató sikerjelzése az, hogy a worker friss szívveréssel megjelenik a flotta panelen. Az indításkor regisztrált, folyamaton belüli worker futtatótérképe üres, ezért a rá helyezett feladat a No local runner for job kind … választ adja.

Előfeltételek

A Dart SDK. Ez a repó az fvm eszközzel rögzíti az SDK-verzióját, ezért a parancsok elé írja oda az fvm előtagot.
Ez a repó klónozva a worker gépén.
Egy elérhető cc_server (fejlesztéshez loopback, éles környezetben LAN vagy távoli).
git a PATH-ban — a worker materializálja a repókat, és git próbákat futtat.

1. lépés: A bináris felépítése

cd apps/cc_worker
fvm dart build cli

Ez egy önálló csomagot hoz létre a ./build/cli/<os_arch>/bundle/bin/cc_worker helyen.

2. lépés: A worker hitelesítő adatának kiállítása

A cc_server csak olyan workert fogad el, amely párosítotteszköz-azonosítót és előre megosztott kulcsot mutat be — a loopback szerver esetében is. Ezeket a szerver gépén állítsa ki (pair parancs a szerver futása közben is kiadható; az új eszközt újraindítás nélkül felveszi):

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

Kiír egy Device id és egy Pairing key értéket — ezeket várja a --device-id, valamint a --psk / --psk-file / CC_WORKER_PSK.

3. lépés: A worker elindítása

Párosított szerver esetén:

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

Loopback szerver esetén (szintén párosítva — a cc_server mindig lefuttatja a PSK-kézfogást):

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

Kapcsoló	Leírás	Alapértelmezés
`--server <url>`	cc_server URL (`ws://`/`wss://`; a `http(s)` és a hiányzó `/rpc` útvonal automatikusan átalakításra kerül). Kötelező.	—
`--name <name>`	A kezelő felé megjelenő worker-név.	gazdagép neve
`--device-id <id>`	Állandó párosítotteszköz-azonosító, amelyet a worker azonosítójaként is használ.	`cc-worker`
`--psk-file <path>`	Fájl, amelynek első nem üres sora a párosítási kulcs. Előnyben részesül a `--psk` helyett.	—
`--psk <key>`	Párosítási kulcs a parancssorban. Látható a `ps` kimenetében és a shell előzményeiben — a bináris figyelmeztet rá.	—
`--max-jobs <n>`	Kemény felső korlát arra, hogy ez a folyamat hány feladatot hajt végre egyidejűleg (pozitív egész szám).	`4`

A kulcs feloldási sorrendje: --psk-file → CC_WORKER_PSK → --psk. Ha minden forrást elhagy, a worker kihagyja a hitelesítési kézfogást; egy valódi cc_server ekkor megtagadja a munkamenetet (auth_denied), ahelyett hogy elfogadna egy hitelesítés nélküli workert. Az ismeretlen kapcsolók használati hibát okoznak (exit 64) — a cc_server-rel ellentétben ez a bináris a package:args csomagot használja, és nem hagyja figyelmen kívül az elgépeléseket.

A CC_WORKER_CACHE felülírja a worktree-k materializálási gyorsítótárának könyvtárát (alapértelmezés: egy cc_worker_cache könyvtár a rendszer ideiglenes könyvtára alatt).

A worker a fleet.registerWorker hívással regisztrál, majd 20 másodpercenként szívverést küld, és 2 másodpercenként lízingeket kérdez le. SIGINT/SIGTERM hatására áll le; tegye systemd vagy launchd alá, hogy összeomlás vagy újraindítás után magától újrainduljon és újra regisztráljon.

4. lépés: Ellenőrzés a flotta panelen

Nyissa meg a Megfigyelhetőség nézetet az asztali vagy a webes alkalmazásban, váltson az Élő fülecskére, és görgessen a legaljára. A Workerek felsorolja az összes regisztrált workert a platformjával, magjaival, képességkulcsaival és az utolsó szívverésével; a Feladatok pedig a köztük szétosztott feladatokat.

Az, hogy a worker friss szívveréssel megjelenik ott, visszaigazolja, hogy a párosítás és a regisztráció sikerült.

Egy worker csempéjén kiürítheti a workert (befejezi az aktuális feladatokat, és nem vesz fel új lízinget), folytathatja a kiürítés alatt álló workert, visszavonhatja a hitelesítő adatait, vagy eltávolíthatja a sort.

A worker- és feladatsorok a szerver global.db adatbázisában élnek — maga a worker a materializálási gyorsítótáron kívül semmit nem ír a lemezre.

Mit hirdet a worker

Regisztrációkor a worker automatikusan felderíti a képességeit, és az ütemező ezekhez illeszti a feladatokat. Ezeket nem kell kézzel beállítania:

Operációs rendszer és architektúra (macos/linux/windows, arm64/x64) — pontos próbák, visszaeséssel a uname -m / PROCESSOR_ARCHITECTURE értékre
Magok és RAM — pontos magszám; a RAM 0-ra esik vissza, ha nem kérdezhető le
flutter — akkor van beállítva, ha egy Flutter SDK elérhető (először sima flutter, majd fvm flutter); a golden renderelési feladatok megkövetelik
sandbox — native-macos macOS-en, native-linux Linuxon. Ez elhelyezési támpont, nem ígéret: a worker azt a háttérrendszert hirdeti, amivel a platformja rendelkezik, de a futtatott feladatokat nem csomagolja bele egybe sem. A cc_server-rel ellentétben a cc_worker közvetlenül indítja a lízingelt feladatot
always-on és parallel — egy dedikált cc_worker mindig mindkettőt hirdeti, így alkalmas kiértékelési kötegekre és más, eldobható párhuzamos kapacitásra

A felderítés a lehetőségekhez mérten történik: ami nem kérdezhető le, az biztonságos alapértelmezésre esik vissza, ahelyett hogy megbuktatná az indulást.

Mit hajtana végre a worker

A lízingprotokoll hat feladatfajtát hordoz:

Fajta	Mi ez
`agentRun`	Egyetlen ügynökfuttatás (kiosztás)
`pipelineStep`	Egy pipeline-lépés végrehajtása
`codeIndex`	Egy repó kódindexének felépítése
`goldenRender`	UI vizuális golden renderelés (`flutter` szükséges)
`benchmark`	Teljesítményteszt futtatása
`evalBatch`	Egy kiértékelési köteg (a `parallel` kapacitást részesíti előnyben)

A végrehajtás valódi, alfolyamatokat streamelő implementáció, nem egy teljes beágyazott ügynökfuttató. Amikor egy lízing repoRemote értéket hordoz, a worker git clone --depth 1 parancsot futtat egy távoli elérési úttal és SHA-val kulcsolt gyorsítótár-könyvtárba, majd git fetch és git checkout parancsot hajt végre. agentRun esetén a lízing környezetében lévő CC_JOB_COMMAND parancsot futtatja a munkakönyvtárban, és eseményként streameli vissza a stdout és stderr kimenetet; CC_JOB_COMMAND nélkül visszhangozza a promptot, hogy a szállítás így is végig legyen gyakorolva. A többi fajta kis, valódi parancsokat futtat (git rev-parse HEAD, git --version) őszinte próbaként. A lízing környezetében lévő, feladathoz kötött hitelesítő adatokat minden alfolyamatba beinjektálja, és soha nem írja naplóba.

Az események kötegekben gyűlnek, és 250 ms-onként vagy 32 eseményenként íródnak ki; minden feladat egy kész eseménnyel és egy befejezési jelentéssel zárul. A modell a szívverésekből és rövid élettartamú lízingekből áll: ha egy worker elveszíti a kapcsolatot, a lízingje lejár, és a szerver begyűjti a feladatot újrapróbálkozásra. A workeren nincs tartós állapot, és a workerek között nincs konszenzus és nincs feladatlopás sem.

Kapcsolódó útmutatók

Kapcsolódó fogalmak

Telepítés és kliensek