Uruchom workera floty

Uruchom cc_worker na zapasowej maszynie, aby dodać swojej flocie moc obliczeniową. To binarium napisane w czystym Darcie — bez silnika Flutter — które paruje się z cc_server, deklaruje możliwości swojego hosta, wysyła puls, pobiera wydzierżawione zadania, wykonuje je i strumieniuje z powrotem zdarzenia procesów. Nie przechowuje żadnego trwałego stanu: nadzorca uruchamia je ponownie, a ono rejestruje się od nowa.

Najpierw potrzebujesz działającego cc_server — zobacz Uruchom serwer headless.

Sparowany worker rejestruje się, wysyła puls i czeka na wydzierżawione zadania. Pracę zgłaszaj przez fleet.submitJob. Wysyłanie agentów na tym serwerze nie przechodzi przez flotę; sygnałem powodzenia tego poradnika jest pojawienie się workera w panelu floty ze świeżym pulsem. Worker działający w tym samym procesie, zarejestrowany przy starcie, ma pustą mapę modułów wykonawczych, więc zadanie na nim umieszczone zwraca No local runner for job kind ….

Wymagania wstępne

SDK Dart. To repozytorium przypina wersję swojego SDK za pomocą fvm, więc poprzedzaj polecenia przedrostkiem fvm.
To repozytorium sklonowane na maszynie workera.
Osiągalny cc_server (loopback na potrzeby programowania, sieć LAN lub zdalny w środowisku produkcyjnym).
git w zmiennej PATH — worker materializuje repozytoria i uruchamia sondy git.

Krok 1: Zbuduj binarium

cd apps/cc_worker
fvm dart build cli

W wyniku powstaje samodzielny pakiet w ./build/cli/<os_arch>/bundle/bin/cc_worker.

Krok 2: Wystaw poświadczenie workera

cc_server akceptuje tylko workera, który przedstawi identyfikator sparowanego urządzenia i wstępnie współdzielony klucz — także w przypadku serwera loopback. Wystaw je na maszynie serwera (pair może działać, gdy serwer jest uruchomiony; nowe urządzenie zostanie wykryte bez restartu):

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

Wypisuje Device id oraz Pairing key — to właśnie je przyjmują --device-id i --psk / --psk-file / CC_WORKER_PSK.

Krok 3: Uruchom workera

Wobec sparowanego serwera:

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

Wobec serwera loopback (nadal sparowanego — cc_server zawsze przeprowadza uzgadnianie PSK):

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

Flaga	Opis	Domyślnie
`--server <url>`	Adres URL `cc_server` (`ws://`/`wss://`; `http(s)` i brakująca ścieżka `/rpc` są przekształcane). Wymagane.	—
`--name <name>`	Nazwa workera widoczna dla operatora.	nazwa hosta
`--device-id <id>`	Stały identyfikator sparowanego urządzenia, używany także jako identyfikator workera.	`cc-worker`
`--psk-file <path>`	Plik, którego pierwsza niepusta linia to klucz parowania. Preferowany zamiast `--psk`.	—
`--psk <key>`	Klucz parowania podany w wierszu polecenia. Widoczny w `ps` i historii powłoki — binarium ostrzega.	—
`--max-jobs <n>`	Twardy limit liczby zadań wykonywanych współbieżnie przez ten proces (liczba całkowita dodatnia).	`4`

Kolejność ustalania klucza to --psk-file → CC_WORKER_PSK → --psk. Pominięcie wszystkich źródeł powoduje pominięcie uzgadniania uwierzytelniania workera; prawdziwy cc_server odrzuci wtedy sesję (auth_denied), zamiast zaakceptować nieuwierzytelnionego workera. Nieznane flagi to błąd użycia (exit 64) — w odróżnieniu od cc_server to binarium korzysta z package:args i nie ignoruje literówek.

CC_WORKER_CACHE zastępuje katalog pamięci podręcznej materializacji worktree (domyślnie: katalog cc_worker_cache w katalogu tymczasowym systemu).

Worker rejestruje się przez fleet.registerWorker, a następnie co 20 s wysyła puls i co 2 s odpytuje o dzierżawy. Działa do momentu otrzymania SIGINT/SIGTERM; umieść go pod systemd lub launchd, aby po awarii lub restarcie wznowił działanie i zarejestrował się ponownie.

Krok 4: Zweryfikuj go w panelu floty

Otwórz Obserwowalność w aplikacji desktopowej lub webowej, przełącz się na kartę Na żywo i przewiń na sam dół. Sekcja Workerzy wyświetla każdego zarejestrowanego workera wraz z jego platformą, liczbą rdzeni, kluczami możliwości i ostatnim pulsem; sekcja Zadania wyświetla zadania rozdzielone między nich.

Pojawienie się tam Twojego workera z niedawnym pulsem potwierdza, że parowanie i rejestracja się powiodły.

Z kafelka workera możesz go opróżnić (dokończy bieżące zadania, ale nie przyjmie nowych dzierżaw), wznowić workera w stanie opróżniania, odwołać jego poświadczenie lub usunąć wiersz.

Wiersze workerów i zadań znajdują się w pliku global.db serwera — sam worker nie zapisuje na dysku niczego poza pamięcią podręczną materializacji.

Co ogłasza worker

Przy rejestracji worker automatycznie wykrywa swoje możliwości, a harmonogram dopasowuje do nich zadania. Nie konfigurujesz ich ręcznie:

System operacyjny i architektura (macos/linux/windows, arm64/x64) — dokładne sondy, z mechanizmami awaryjnymi do uname -m / PROCESSOR_ARCHITECTURE
Rdzenie i pamięć RAM — dokładna liczba rdzeni; pamięć RAM spada do 0, gdy nie da się jej wykryć
flutter — ustawiana, gdy dostępny jest zestaw Flutter SDK (najpierw samo flutter, potem fvm flutter); zadania renderowania golden wymagają tej możliwości
sandbox — native-macos w systemie macOS, native-linux w systemie Linux. To wskazówka umieszczania, a nie obietnica: worker ogłasza backend, który jego platforma ma, ale nie zamyka w nim uruchamianych zadań. W odróżnieniu od cc_server cc_worker uruchamia wydzierżawione zadanie bezpośrednio
always-on i parallel — dedykowany cc_worker zawsze ogłasza obie, dzięki czemu kwalifikuje się do partii ewaluacyjnych i innej jednorazowej równoległej mocy obliczeniowej

Wykrywanie odbywa się w miarę możliwości: wszystko, czego nie da się wykryć, spada do bezpiecznej wartości domyślnej, zamiast powodować niepowodzenie startu.

Co worker mógłby wykonać

Protokół dzierżawy niesie sześć rodzajów zadań:

Rodzaj	Co to jest
`agentRun`	Pojedyncze uruchomienie agenta (wysłanie)
`pipelineStep`	Wykonanie kroku potoku
`codeIndex`	Zbudowanie indeksu kodu repozytorium
`goldenRender`	Wizualne renderowanie golden interfejsu (wymaga `flutter`)
`benchmark`	Uruchomienie testu wydajnościowego
`evalBatch`	Partia ewaluacyjna (preferuje możliwość `parallel`)

Wykonywanie to prawdziwa implementacja strumieniująca podprocesy, a nie pełne wbudowane środowisko uruchomieniowe agenta. Gdy dzierżawa niesie repoRemote, worker wykonuje git clone --depth 1 do katalogu pamięci podręcznej kluczowanego zdalnym repozytorium i SHA, a następnie git fetch i git checkout. Dla agentRun uruchamia polecenie ze zmiennej CC_JOB_COMMAND środowiska dzierżawy w katalogu roboczym, strumieniując z powrotem stdout i stderr jako zdarzenia; bez CC_JOB_COMMAND powtarza prompt, aby transport nadal był testowany od początku do końca. Pozostałe rodzaje uruchamiają niewielkie prawdziwe polecenia (git rev-parse HEAD, git --version) jako uczciwe sondy. Poświadczenia o zasięgu zadania ze środowiska dzierżawy są wstrzykiwane do każdego podprocesu i nigdy nie trafiają do dziennika.

Zdarzenia są grupowane i opróżniane co 250 ms lub co 32 zdarzenia; każde zadanie kończy się zdarzeniem ukończenia i raportem ukończenia. Model to puls plus dzierżawy o krótkim TTL: jeśli worker straci kontakt, jego dzierżawa wygasa, a serwer odzyskuje zadanie do ponownej próby. Worker nie przechowuje żadnego trwałego stanu, a między workerami nie ma konsensusu ani podkradania pracy.

Powiązane poradniki

Powiązane koncepcje

Wdrażanie i klienci