Bir filo worker’ı çalıştırma

Yedek bir makinede cc_worker çalıştırarak filonuza yürütme kapasitesi ekleyin. Flutter motoru içermeyen saf bir Dart ikili dosyasıdır: bir cc_server ile eşleşir, ana makinenin yeteneklerini bildirir, heartbeat gönderir, kiralanmış işleri çeker, bunları yürütür ve süreç olaylarını geri akıtır. Kalıcı durum tutmaz: bir gözetleyici onu yeniden başlatır ve yeniden kaydolur.

Önce çalışan bir cc_server’a ihtiyacınız var — bkz. Headless bir sunucu çalıştırma.

Eşleştirilmiş bir worker kaydolur, heartbeat gönderir ve kiralanmış işleri bekler. İş göndermek için fleet.submitJob kullanın. Bu sunucudaki ajan gönderimi filo üzerinden yönlendirilmez; bu kılavuzun başarı sinyali, worker’ın filo panelinde taze bir heartbeat ile görünmesidir. Açılışta kaydedilen süreç içi worker’ın runner haritası boştur, bu yüzden ona bırakılan bir iş No local runner for job kind … döndürür.

Önkoşullar

• Dart SDK. Bu depo SDK’sını fvm ile sabitler, bu yüzden komutların başına fvm ekleyin.
• Bu deponun worker makinesinde checkout edilmiş olması.
• Erişilebilir bir cc_server (geliştirme için loopback, üretim için LAN ya da uzak).
• PATH üzerinde git — worker depoları materyalize eder ve git yoklamaları çalıştırır.

1. Adım: İkili dosyayı derleme

cd apps/cc_worker
fvm dart build cli

Bu, ./build/cli/<os_arch>/bundle/bin/cc_worker konumunda kendi kendine yeten bir paket üretir.

2. Adım: Worker’ın kimlik bilgisini üretme

Bir cc_server, yalnızca eşleştirilmiş cihaz kimliği ve ön paylaşımlı anahtar sunan bir worker’ı kabul eder — buna loopback bir sunucu da dahildir. Bunları sunucu makinesinde üretin (pair, sunucu çalışırken çalıştırılabilir; yeni cihaz yeniden başlatma olmadan alınır):

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

Bir Device id ve bir Pairing key yazdırır — --device-id ile --psk / --psk-file / CC_WORKER_PSK seçeneklerinin aldığı değerler bunlardır.

3. Adım: Worker’ı başlatma

Eşleştirilmiş bir sunucuya karşı:

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

Loopback bir sunucuya karşı (yine eşleştirilmiş — cc_server her zaman PSK el sıkışmasını çalıştırır):

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

Bayrak	Açıklama	Varsayılan
--server <url>	cc_server URL’si (ws:///wss://; http(s) ve eksik bir /rpc yolu otomatik dönüştürülür). Zorunlu.	—
--name <name>	Operatöre görünen worker adı.	ana makine adı
--device-id <id>	Sabit eşleştirilmiş cihaz kimliği; worker kimliği olarak da kullanılır.	cc-worker
--psk-file <path>	İlk boş olmayan satırı eşleme anahtarı olan dosya. --psk yerine tercih edilir.	—
--psk <key>	Komut satırında eşleme anahtarı. ps ve kabuk geçmişinde görünür — ikili dosya uyarır.	—
--max-jobs <n>	Bu sürecin eşzamanlı yürüttüğü işler için katı üst sınır (pozitif tam sayı).	4

Anahtar için çözümleme sırası --psk-file → CC_WORKER_PSK → --psk şeklindedir. Her kaynak atlanırsa worker’ın kimlik doğrulama el sıkışması da atlanır; gerçek bir cc_server bu durumda kimliği doğrulanmamış bir worker’ı kabul etmek yerine oturumu reddeder (auth_denied). Bilinmeyen bayraklar bir kullanım hatasıdır (exit 64) — cc_server’ın aksine bu ikili dosya package:args kullanır ve yazım hatalarını yok saymaz.

CC_WORKER_CACHE, worktree materyalizasyon önbelleği dizinini geçersiz kılar (varsayılan: sistem geçici dizini altındaki bir cc_worker_cache dizini).

Worker, fleet.registerWorker ile kaydolur; ardından her 20 saniyede bir heartbeat gönderir ve her 2 saniyede bir kiralama için yoklama yapar. SIGINT/ SIGTERM gelene kadar çalışır; bir çökmeden ya da yeniden başlatmadan sonra yeniden başlayıp kaydolması için onu systemd ya da launchd altına koyun.

Protokol uyumluluğu için bir pencere yok

Filo protokol sürümü sunucununkinden farklı olan bir worker uyumsuz olarak kaydedilir, ona asla bir kiralama sunulmaz ve cc_worker’ın kendisi şu hatayla sonlanır: Incompatible fleet protocol: worker speaks v… server speaks v… Upgrade cc_worker to match the server release. Worker’ı sunucuyla aynı sürümden derleyin.

4. Adım: Filo panelinde doğrulama

Masaüstü ya da web uygulamasında Gözlemlenebilirlik’i açın, Canlı sekmesine geçin ve aşağı kaydırın. İşçiler, kayıtlı her worker’ı platformu, çekirdekleri, yetenek anahtarları ve son heartbeat’i ile listeler; İşler ise aralarında dağıtılan işleri listeler.

Worker’ınızın orada yakın tarihli bir heartbeat ile görünmesi, eşleştirme ve kaydın çalıştığının doğrulamasıdır.

Bir worker’ın kutucuğundan onu boşaltabilir (mevcut işleri bitirir, yeni kiralama almaz), boşaltılan bir worker’ı sürdürebilir, kimlik bilgisini iptal edebilir ya da satırı kaldırabilirsiniz.

Worker ve iş satırları sunucunun global.db dosyasında yaşar — worker’ın kendisi materyalizasyon önbelleğinin ötesinde diske hiçbir şey yazmaz.

Worker’ın duyurdukları

Kayıt sırasında worker yeteneklerini otomatik algılar ve zamanlayıcı işleri bunlarla eşleştirir. Bunları elle yapılandırmazsınız:

• İşletim sistemi ve mimari (macos/linux/windows, arm64/x64) — kesin yoklamalar, uname -m / PROCESSOR_ARCHITECTURE geri dönüşleriyle
• Çekirdekler ve RAM — kesin çekirdek sayısı; RAM yoklanamadığında 0 değerine düşer
• flutter — erişilebilir bir Flutter SDK olduğunda ayarlanır (yalın flutter, sonra fvm flutter); golden render işleri bunu gerektirir
• sandbox — macOS’te native-macos, Linux’ta native-linux. Bu bir yerleştirme ipucudur, bir vaat değil: worker, platformunun sahip olduğu arka ucu duyurur, ama çalıştırdığı işleri onun içine sarmaz. cc_server’ın aksine cc_worker, kiralanmış bir işi doğrudan başlatır
• always-on ve parallel — adanmış bir cc_worker her ikisini de her zaman duyurur, böylece eval partileri ve diğer tek kullanımlık paralel kapasite için uygundur

Algılama elinden gelenin en iyisidir: yoklayamadığı her şey, başlatmayı başarısız kılmak yerine güvenli bir varsayılana düşer.

Worker’ın yürüteceği işler

Kiralama protokolü altı iş türü taşır:

Tür	Ne olduğu
agentRun	Tek bir ajan çalıştırması (gönderim)
pipelineStep	Bir pipeline adımı yürütmesi
codeIndex	Bir depo kod dizini derlemesi
goldenRender	Bir arayüz görsel golden render’ı (flutter gerektirir)
benchmark	Bir performans kıyaslama çalıştırması
evalBatch	Bir eval partisi (parallel kapasitesini tercih eder)

Yürütme, tam bir gömülü ajan çalışma zamanı değil, gerçek bir alt süreç akıtma uygulamasıdır. Bir kiralama repoRemote taşıdığında worker, uzak adres ve SHA ile anahtarlanmış bir önbellek dizinine git clone --depth 1 yapar, ardından git fetch ve git checkout çalıştırır. agentRun için çalışma dizininde, kiralama ortamının CC_JOB_COMMAND değerindeki komutu çalıştırır ve stdout ile stderr’i olay olarak geri akıtır; CC_JOB_COMMAND yoksa, taşıma katmanı yine de uçtan uca denenmiş olsun diye istemi geri yansıtır. Diğer türler, dürüst yoklamalar olarak küçük gerçek komutlar (git rev-parse HEAD, git --version) çalıştırır. Kiralama ortamındaki işe özel kimlik bilgileri her alt sürece enjekte edilir ve hiçbir zaman bir günlüğe yazılmaz.

Olaylar toplanır ve her 250 ms’de bir ya da her 32 olayda bir boşaltılır; her iş bir done olayı ve bir tamamlanma raporuyla biter. Model, heartbeat’ler artı kısa TTL’li kiralamalardır: bir worker bağlantıyı kaybederse kiralaması sona erer ve sunucu işi yeniden deneme için geri toplar. Worker’da kalıcı durum yoktur ve worker’lar arasında uzlaşma ya da iş çalma yoktur.

İlgili kılavuzlar

• Headless bir sunucu çalıştırma
• Uzak bir sunucuya bağlanma
• Bir cihaz eşleştirme

İlgili kavramlar

• Dağıtım ve istemciler