הפעלת worker בצי

הריצו את 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.

שלב 1: בניית הבינארי

cd apps/cc_worker
fvm dart build cli

הפקודה מפיקה חבילה עצמאית ב-./build/cli/<os_arch>/bundle/bin/cc_worker.

שלב 2: הנפקת האישור של העובד

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 מקבלים.

שלב 3: הפעלת העובד

מול שרת מצומד:

./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>	כתובת ה-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 עוקף את ספריית המטמון של מימוש עצי העבודה (ברירת מחדל: ספריית cc_worker_cache תחת ספריית הקבצים הזמניים של המערכת).

העובד נרשם עם fleet.registerWorker, ואז שולח פעימה כל 20 שניות ומתחקר אחרי חכירות כל 2 שניות. הוא רץ עד SIGINT/SIGTERM; הניחו אותו תחת systemd או launchd כדי שיופעל מחדש ויירשם שוב אחרי קריסה או אתחול.

אין חלון תאימות פרוטוקול

עובד שגרסת פרוטוקול הצי שלו שונה מזו של השרת נרשם כלא תואם, ולעולם לא מוצעת לו חכירה, ו-cc_worker עצמו נכשל עם Incompatible fleet protocol: worker speaks v… server speaks v… Upgrade cc_worker to match the server release. בנו את העובד מאותה מהדורה של השרת.

שלב 4: אימות בלוח הצי

פתחו את ניטור באפליקציית שולחן העבודה או באפליקציית הווב, עברו ללשונית בזמן אמת וגללו לתחתית. וורקרים מציגה כל עובד רשום עם הפלטפורמה, הליבות, מפתחות היכולות והפעימה האחרונה שלו; עבודות מציגה את המשימות שמחולקות ביניהם.

הופעה של העובד שלכם שם עם פעימה עדכנית היא האישור שהצימוד והרישום עבדו.

מהאריח של העובד תוכלו לבצע ריקון שלו (לסיים את המשימות הנוכחיות ולא לקחת חכירות חדשות), חידוש של עובד מתרוקן, שלילה של האישור שלו או הסרה של השורה.

שורות של עובדים ומשימות יושבות ב-global.db של השרת — העובד עצמו אינו כותב דבר לדיסק מלבד מטמון המימוש.

מה העובד מפרסם

בעת הרישום העובד מזהה אוטומטית את היכולות שלו והמתזמן מתאים אליהן משימות. אתם לא מגדירים אותן ביד:

• מערכת הפעלה וארכיטקטורה (macos/linux/windows, arm64/x64) — בדיקות מדויקות, עם נפילה חזרה אל uname -m / PROCESSOR_ARCHITECTURE
• ליבות וזיכרון — מספר ליבות מדויק; הזיכרון מדווח כ-0 כשאין דרך לבדוק אותו
• flutter — מסומן כשקיים Flutter SDK זמין (flutter ישיר, ואז fvm flutter); משימות רינדור גולדן דורשות אותו
• sandbox — native-macos ב-macOS, native-linux ב-Linux. זהו רמז שיבוץ, לא הבטחה: העובד מפרסם את המנוע שלפלטפורמה שלו יש, אבל הוא אינו עוטף בו את המשימות שהוא מריץ. שלא כמו cc_server, cc_worker מפעיל משימה מוחכרת ישירות
• always-on ו-parallel — cc_worker ייעודי תמיד מפרסם את שניהם, ולכן הוא זכאי לאצוות הערכה ולכושר מקבילי חד־פעמי אחר

הזיהוי הוא כמיטב היכולת: כל מה שאי אפשר לבדוק יורד לברירת מחדל בטוחה במקום להכשיל את העלייה.

מה העובד היה מבצע

פרוטוקול החכירה נושא שישה סוגי משימות:

סוג	מה זה
agentRun	הרצת סוכן אחת (שליחה)
pipelineStep	ביצוע שלב בפייפליין
codeIndex	בנייה של אינדקס קוד למאגר
goldenRender	רינדור גולדן חזותי של ממשק (דורש flutter)
benchmark	הרצת בנצ’מרק ביצועים
evalBatch	אצוות הערכה (מעדיפה כושר parallel)

הביצוע הוא מימוש אמיתי שמזרים תת־תהליכים, לא סביבת הרצה מלאה של סוכן מוטבע. כשהחכירה נושאת repoRemote, העובד מריץ git clone --depth 1 אל ספריית מטמון הממופתחת לפי מרוחק ו-SHA, ואז git fetch ו-git checkout. עבור agentRun הוא מריץ את הפקודה שב-CC_JOB_COMMAND של סביבת החכירה בספריית העבודה, ומזרים את ה-stdout וה-stderr בחזרה כאירועים; בלי CC_JOB_COMMAND הוא מחזיר את ההנחיה כהד כדי שהתעבורה עדיין תיבדק מקצה לקצה. שאר הסוגים מריצים פקודות אמיתיות קטנות (git rev-parse HEAD, git --version) כבדיקות כנות. אישורים שהיקפם הוא המשימה, מסביבת החכירה, מוזרקים לכל תת־תהליך ולעולם אינם נכתבים ליומן.

האירועים נאספים ונשלחים בקבוצות כל 250 מילישניות או כל 32 אירועים; כל משימה מסתיימת באירוע סיום ובדוח השלמה. המודל הוא פעימות בתוספת חכירות בעלות TTL קצר: אם עובד מאבד קשר, החכירה שלו פגה והשרת מחזיר את המשימה לתור לניסיון חוזר. אין מצב עמיד על העובד ואין קונצנזוס או גניבת עבודה בין עובדים.

מדריכים קשורים

• הפעלת שרת ללא ממשק
• התחברות לשרת מרוחק
• שיוך מכשיר

מושגים קשורים

• פריסה ולקוחות