اجرای یک کارگر ناوگان

cc_worker را روی یک ماشین یدکی اجرا کنید تا به ناوگانتان ظرفیت اجرا اضافه شود. این یک باینری خالص Dart است — بدون موتور Flutter — که با یک cc_server جفت می‌شود، توانمندی‌های میزبان را اعلام می‌کند، ضربان می‌فرستد، کارهای اجاره‌ای را می‌کشد، آن‌ها را اجرا می‌کند و رویدادهای فرایند را بازمی‌گرداند. هیچ حالت دیرپایی نگه نمی‌دارد: یک سرپرست آن را دوباره راه‌اندازی می‌کند و از نو ثبت می‌شود.

نخست به یک cc_server در حال اجرا نیاز دارید — اجرای سرور بدون رابط را ببینید.

یک کارگر جفت‌شده ثبت می‌شود، ضربان می‌فرستد و منتظر کارهای اجاره‌ای می‌ماند. کار را با fleet.submitJob ارسال کنید. اعزام عامل روی این سرور از ناوگان نمی‌گذرد؛ نشانهٔ موفقیت در این راهنما این است که کارگر با یک ضربان تازه در پنل ناوگان ظاهر شود. کارگر درون‌فرایندی که هنگام راه‌اندازی ثبت می‌شود نگاشت اجراکنندهٔ خالی دارد، پس کاری که روی آن گذاشته شود No local runner for job kind … را برمی‌گرداند.

پیش‌نیازها

Dart SDK. این مخزن SDK خود را با fvm تثبیت می‌کند، پس فرمان‌ها را با fvm آغاز کنید.
این مخزن روی ماشین کارگر چک‌اوت‌شده باشد.
یک cc_server قابل‌دسترسی (برای توسعه لوپ‌بک، برای تولید LAN یا راه دور).
git روی PATH — کارگر مخزن‌ها را مادی می‌کند و کاوش‌های git اجرا می‌کند.

گام ۱: ساخت باینری

cd apps/cc_worker
fvm dart build cli

این یک بستهٔ خودبسنده در ./build/cli/<os_arch>/bundle/bin/cc_worker تولید می‌کند.

گام ۲: ساخت اعتبارنامهٔ کارگر

یک cc_server تنها کارگری را می‌پذیرد که شناسهٔ دستگاه جفت‌شده و کلید پیش‌اشتراکی ارائه دهد — از جمله یک سرور لوپ‌بک. آن‌ها را روی ماشین سرور بسازید (pair می‌تواند در حالی که سرور بالاست اجرا شود؛ دستگاه جدید بدون راه‌اندازی دوباره شناسایی می‌شود):

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

این فرمان یک Device id و یک Pairing key چاپ می‌کند — همان‌هایی که --device-id و --psk / --psk-file / CC_WORKER_PSK می‌گیرند.

گام ۳: راه‌اندازی کارگر

در برابر یک سرور جفت‌شده:

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

در برابر یک سرور لوپ‌بک (باز هم جفت‌شده — cc_server همیشه دست‌دادن PSK را اجرا می‌کند):

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

فلگ	توضیح	پیش‌فرض
`--server <url>`	نشانی `cc_server` (`ws://`/`wss://`؛ `http(s)` و مسیر غایب `/rpc` به‌اجبار تبدیل می‌شوند). الزامی.	—
`--name <name>`	نام کارگر که اپراتور می‌بیند.	نام میزبان
`--device-id <id>`	شناسهٔ پایدار دستگاه جفت‌شده که به‌عنوان شناسهٔ کارگر هم به کار می‌رود.	`cc-worker`
`--psk-file <path>`	فایلی که نخستین خط ناتهی‌اش کلید جفت‌سازی است. بر `--psk` ترجیح دارد.	—
`--psk <key>`	کلید جفت‌سازی روی خط فرمان. در `ps` و تاریخچهٔ پوسته دیده می‌شود — باینری هشدار می‌دهد.	—
`--max-jobs <n>`	سقف سخت تعداد کارهایی که این فرایند هم‌زمان اجرا می‌کند (عدد صحیح مثبت).	`4`

ترتیب تشخیص کلید --psk-file → CC_WORKER_PSK → --psk است. نادیده‌گرفتن همهٔ منابع، دست‌دادن احراز هویت کارگر را رد می‌کند؛ آن‌گاه یک cc_server واقعی به‌جای پذیرش یک کارگر احرازنشده، نشست را رد می‌کند (auth_denied). فلگ‌های ناشناخته یک خطای کاربرد هستند (exit 64) — برخلاف cc_server، این باینری از package:args استفاده می‌کند و اشتباهات تایپی را نادیده نمی‌گیرد.

CC_WORKER_CACHE پوشهٔ کش مادی‌سازی worktree را بازنویسی می‌کند (پیش‌فرض: پوشه‌ای cc_worker_cache زیر پوشهٔ موقت سیستم).

کارگر با fleet.registerWorker ثبت می‌شود، سپس هر ۲۰ ثانیه ضربان می‌فرستد و هر ۲ ثانیه برای اجاره‌ها بررسی می‌کند. تا SIGINT/SIGTERM اجرا می‌شود؛ آن را زیر systemd یا launchd بگذارید تا پس از سقوط یا راه‌اندازی دوباره، از نو راه‌اندازی و ثبت شود.

گام ۴: راستی‌آزمایی در پنل ناوگان

در اپ رومیزی یا وب مشاهده‌پذیری را باز کنید، به زبانهٔ زنده بروید و تا پایین اسکرول کنید. کارگران هر کارگر ثبت‌شده را همراه با پلتفرم، هسته‌ها، کلیدهای توانمندی و آخرین ضربان فهرست می‌کند؛ کارها کارهای توزیع‌شده میان آن‌ها را فهرست می‌کند.

ظاهر‌شدن کارگر شما با یک ضربان تازه همان تأییدی است که جفت‌سازی و ثبت کار کرده‌اند.

از کاشی یک کارگر می‌توانید آن را تخلیه کنید (کارهای جاری را تمام کند، اجارهٔ تازه‌ای نگیرد)، یک کارگر در حال تخلیه را ازسرگیری کنید، اعتبارنامه‌اش را لغو کنید یا سطرش را بردارید.

سطرهای کارگر و کار در global.db سرور زندگی می‌کنند — خودِ کارگر چیزی فراتر از کش مادی‌سازی روی دیسک نمی‌نویسد.

کارگر چه چیزی اعلام می‌کند

هنگام ثبت، کارگر توانمندی‌های خود را به‌طور خودکار تشخیص می‌دهد و زمان‌بند کارها را با آن‌ها تطبیق می‌دهد. این‌ها را دستی پیکربندی نمی‌کنید:

سیستم‌عامل و معماری (macos/linux/windows، arm64/x64) — کاوش دقیق، با بازگشت به uname -m / PROCESSOR_ARCHITECTURE
هسته‌ها و RAM — تعداد دقیق هسته؛ RAM هرگاه کاوش‌پذیر نباشد به 0 تنزل می‌یابد
flutter — وقتی یک SDK Flutter در دسترس باشد تنظیم می‌شود (flutter تنها، سپس fvm flutter)؛ کارهای رندر طلایی به آن نیاز دارند
sandbox — روی macOS native-macos و روی Linux native-linux. این یک اشارهٔ جای‌گذاری است، نه یک وعده: کارگر بک‌اندی را که پلتفرمش دارد اعلام می‌کند، اما کارهایی را که اجرا می‌کند در آن نمی‌پیچد. برخلاف cc_server، cc_worker یک کار اجاره‌ای را مستقیماً راه‌اندازی می‌کند
always-on و parallel — یک cc_worker اختصاصی همیشه هر دو را اعلام می‌کند، پس واجد شرایط دسته‌های ارزیابی و دیگر ظرفیت موازی یک‌بارمصرف است

تشخیص به‌بهترین‌تلاش است: هر چیزی که نتواند کاوش کند، به‌جای شکست راه‌اندازی، به یک پیش‌فرض ایمن تنزل می‌یابد.

کارگر چه چیزی اجرا می‌کند

پروتکل اجاره شش گونهٔ کار را حمل می‌کند:

گونه	چیست
`agentRun`	یک اجرای منفرد عامل (اعزام)
`pipelineStep`	اجرای یک گام پایپ‌لاین
`codeIndex`	ساخت ایندکس کد یک مخزن
`goldenRender`	یک رندر طلایی بصری رابط کاربری (به `flutter` نیاز دارد)
`benchmark`	اجرای یک محک کارایی
`evalBatch`	یک دستهٔ ارزیابی (ظرفیت `parallel` را ترجیح می‌دهد)

اجرا یک پیاده‌سازی واقعی جریان‌سازی زیرفرایند است، نه یک زمان اجرای کامل عامل جاسازی‌شده. وقتی یک اجاره repoRemote را حمل کند، کارگر git clone --depth 1 را در یک پوشهٔ کش کلیدخورده با remote و SHA انجام می‌دهد، سپس git fetch و git checkout. برای agentRun فرمان موجود در CC_JOB_COMMAND محیط اجاره را در پوشهٔ کار اجرا می‌کند و stdout و stderr را به‌صورت رویداد بازمی‌گرداند؛ بدون CC_JOB_COMMAND پرامپت را بازتاب می‌دهد تا انتقال باز هم سرتاسر آزموده شود. گونه‌های دیگر فرمان‌های کوچک واقعی (git rev-parse HEAD، git --version) را به‌عنوان کاوش‌های صادق اجرا می‌کنند. اعتبارنامه‌های محدود به کار در محیط اجاره به هر زیرفرایند تزریق می‌شوند و هرگز در لاگ نوشته نمی‌شوند.

رویدادها دسته‌دسته می‌شوند و هر ۲۵۰ میلی‌ثانیه یا هر ۳۲ رویداد تخلیه می‌شوند؛ هر کار با یک رویداد پایانی و یک گزارش تکمیل پایان می‌یابد. مدل همان ضربان‌ها به‌علاوهٔ اجاره‌های با TTL کوتاه است: اگر کارگر تماسش را از دست بدهد، اجاره‌اش منقضی می‌شود و سرور کار را برای تلاش دوباره برمی‌دارد. هیچ حالت دیرپایی روی کارگر و هیچ اجماع یا دزدیدن کاری میان کارگرها نیست.

راهنماهای مرتبط

مفهوم‌های مرتبط

استقرار و کلاینت‌ها