הערכה אוטומטית של קוד באמצעות ארגז חול לסוכנים ב-GKE

1. מבוא

ב-Codelab הזה נסביר איך פורסים את אפליקציית השופט בתחרות ההאקתון ב-Google Kubernetes Engine ‏ (GKE) ואיך משתמשים בארגז החול לסוכנים של Kubernetes-sigs כדי להריץ עומסי עבודה של סוכנים בצורה בטוחה ומאובטחת.

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

הפעולות שתבצעו:

  • הקצאת שירותי Google Cloud ליעד והגדרת ממשקי API ליעד.
  • מאתחלים את GKE Autopilot ומתקינים את ה-CRD של Agent Sandbox, את ההגדרות של האשכול ואת Sandbox Router.
  • פורסים את Sandbox Gateway, את Sandbox Claim Template ואת Sandbox WarmPool.
  • פורסים את ה-API ל-REST של ה-Backend, את סוכן ה-ADK Judging worker ואת ממשק המשתמש של ה-Frontend ב-React.
  • אפשר להגדיר ניתוב חיצוני מאוזן עומסים ולגשת לפלטפורמה כדי להריץ תהליכי עבודה מאובטחים של שיפוט בארגז חול.

הדרישות

  • דפדפן אינטרנט כמו Chrome.
  • פרויקט ב-Google Cloud שהחיוב בו מופעל.

המשאבים שנוצרו ב-Codelab הזה אמורים לעלות פחות מ-5 $בסך הכול על זמן הריצה.

2. הבעיה: הערכה מאובטחת של קוד לא מהימן

האקתונים הם אירועים מהירים שבהם המשתתפים יוצרים ומגישים פרויקטים – לרוב כולל קוד מקור – לצורך הערכה. הערכה ידנית של הפריטים האלה דורשת זמן ומשאבים רבים. שימוש בסוכני AI כדי להפוך את מתן הציונים לאוטומטי הוא פתרון מבטיח, אבל הוא מציב אתגר אבטחה משמעותי: איך מריצים בבטחה קוד שסופק על ידי המשתתפים, שיכול להיות מלא באגים, זדוני או עתיר משאבים?

הפעלת קוד לא מהימן ישירות בתשתית חושפת אתכם לסיכונים כמו:

  • החדרת קוד: סקריפטים זדוניים עלולים לנסות לגשת למידע אישי רגיש או לשנות אותו.
  • הסלמת הרשאות (privilege escalation): יכול להיות שהקוד ינסה לקבל גישה לא מורשית למערכות אחרות או למשאבי רשת.
  • ניצול לרעה של משאבים: קוד שנכתב בצורה לא טובה או התקפות מניעת שירות (DoS) עלולות לצרוך כמות מוגזמת של מעבד (CPU), זיכרון או רוחב פס ברשת, ולהשפיע על פעולות אחרות.

כדי להפוך את השיפוט בהאקתון לאוטומטי באמצעות AI, אנחנו צריכים דרך להריץ את הקוד שנשלח בסביבה מבודדת לחלוטין משאר המערכת שלנו ומפריטים אחרים שנשלחו.

3. הפתרון: GKE Agent Sandbox

ארגז החול לסוכנים ב-GKE הוא תכונה שנועדה בדיוק למטרה הזו. הוא עוזר לנהל עומסי עבודה מבודדים, מבוססי-מצב ועם עותק יחיד ב-GKE, והוא מותאם לתרחישי שימוש כמו זמני ריצה של סוכני AI שבהם צריך להריץ קוד לא מהימן בצורה מאובטחת ויעילה.

היתרונות המרכזיים של ארגז החול של הסוכן:

  • בידוד ברמת הליבה: מספק בידוד חזק ברמת הליבה לקוד לא מהימן באמצעות טכנולוגיות כמו gVisor, ומונע מהקוד לגשת למערכת המארחת או למאגרי קונטיינרים אחרים.
  • הקצאת משאבים תוך פחות משנייה: הקצאת משאבים מהירה של סביבות ארגז חול (בדרך כלל תוך פחות משנייה), שהיא חיונית להערכת קוד לפי דרישה.
  • הרחבה מובנית בענן: שימוש ביכולות של Kubernetes ובתשתית המנוהלת של GKE.

באמצעות Agent Sandbox, אנחנו יכולים ליצור סביבות מבודדות לפי דרישה לכל פתרון שנשלח להאקתון. סוכן ה-AI שבודק את הקוד יכול להנחות את ארגז החול של הסוכן להריץ בדיקות, לקמפל קוד או לבצע שלבי הערכה אחרים בארגז החול המאובטח הזה, בלי לסכן את השלמות של הפלטפורמה הכוללת. השיטה הזו מספקת דרך יעילה, מאובטחת וניתנת להרחבה לאוטומציה של מתן ציונים בהאקתון.

4. לפני שתתחיל

בחירה או יצירה של פרויקט

מוודאים שאתם עובדים בפרויקט הרצוי ב-Google Cloud:

  1. בוחרים או יוצרים פרויקט: בוחרים פרויקט קיים או יוצרים פרויקט חדש במסוף Google Cloud.
  2. הגדרת הפרויקט הפעיל: רושמים את מזהה הפרויקט כדי להגדיר את Cloud Shell לשימוש בו: 
    gcloud config set project [YOUR_PROJECT_ID]

אימות החיוב

הקפידו לוודא שהחיוב מופעל בפרויקט בענן שלכם ב-Google Cloud. מידע נוסף על האופן שבו עושים את זה זמין במדריך הזה.

הפעלת Cloud Shell

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

הפעלת ממשקי ה-API

מריצים את הפקודה הבאה ב-Cloud Shell כדי להפעיל את כל ממשקי ה-API של Google Cloud שנדרשים להפעלת הפלטפורמה:

gcloud services enable \
  container.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  pubsub.googleapis.com \
  aiplatform.googleapis.com \
  cloudresourcemanager.googleapis.com \
  iam.googleapis.com \
  bigquery.googleapis.com \
  bigqueryconnection.googleapis.com

למה אנחנו מפעילים את ממשקי ה-API האלה: שירותי Google Cloud מושבתים כברירת מחדל כדי למנוע גישה וחיובים לא מורשים. אנחנו מפעילים את ממשקי ה-API הספציפיים האלה כדי להפעיל תזמור קונטיינרים (GKE), אחסון מאובטח של קונטיינרים (Artifact Registry), אריזת build ללא שרת (Cloud Build), תורים אמינים של הודעות (Pub/Sub), שירותי מודלים של AI‏ (Vertex AI), הגדרת פרויקטים (Cloud Resource Manager ו-IAM), ניתוח נתונים ללא שרת (BigQuery) וקישורי AI ברמת מסד הנתונים (BigQuery Connection).

5. הגדרת התשתית

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

שכפול המאגר

משכפלים את המאגר שמכיל את כל שירותי האפליקציות, סקריפטים להגדרה והצהרות של מניפסט Kubernetes:

git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos
git sparse-checkout set codelabs/ai-toolkit-lab-2/hackathon-judge
cd codelabs/ai-toolkit-lab-2/hackathon-judge

הפעלת סקריפט פריסה

ההגדרה הבסיסית של משאבי הענן, מודלים של מסדי נתונים ומדיניות בסיסית של אשכול Kubernetes מתבצעת באופן אוטומטי על ידי סקריפט deploy.sh.

מריצים את הסקריפט:

./deploy.sh

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

אלה פעולות היעד שהסקריפט מבצע:

1. הגדרת תצורת הסביבה

הסקריפט יוצר קובץ הגדרות .env לאחסון פרמטרים של משתנים בפרויקט, ב-GKE, ב-Pub/Sub וב-BigQuery. הוספת הקובץ הזה באופן דינמי מאכלסת את כל הגדרות המניפסט של Kubernetes שבאות אחריו.

למה אנחנו מגדירים את קובץ הסביבה הזה: הקובץ .env מרכז את פרמטרי ההגדרה, כדי להבטיח שהמניפסטים של GKE שאנחנו מפעילים באופן ידני בשלבים הבאים ישתמשו בהגדרות אזוריות, בשמות פרויקטים ובמשאבים זהים, תוך הפרדה מוחלטת בין הגדרת הסביבה לבין קוד המקור.

2. הגדרת פרויקט היעד ב-Google Cloud CLI

הסקריפט מוודא שהכלי gcloud,‏ bq,‏ kubectl ו-envsubst מותקנים, בודק את מצב האימות ונועל את יעדי ההגדרה הפעילים בפרויקט בענן הפעיל שלכם ב-Google Cloud.

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

3. הפעלת ממשקי API של Google Cloud

הסקריפט מבצע בדיקה אידמפוטנטית כדי לאמת ולהפעיל את ממשקי ה-API של שירות Google Cloud (GKE,‏ Artifact Registry,‏ Cloud Build,‏ Pub/Sub,‏ Vertex AI,‏ BigQuery ו-IAM).

למה אנחנו מפעילים ממשקי API של Google Cloud: צריך להפעיל שירותי ענן מנוהלים לפני שאפשר להגיע לנקודות הקצה שלהם או ליצור משאבים. הפעלתם בהתחלה מכינה את שער ה-API האזורי של GCP לטיפול בפקודות הבאות להקצאת משאבים.

4. הקצאת מאגר Docker ב-Artifact Registry

הסקריפט מקצה מאגר תגים של Docker בשם hackathon-judge-repo במיקום היעד שנבחר.

למה אנחנו יוצרים מאגר Artifact Registry: כדי למשוך במהירות תמונות של אפליקציות, אשכולות GKE צריכים גישה מאובטחת למאגרי קונטיינרים פרטיים באותה רשת אזורית. ‫Artifact Registry מספק מארח פרטי ומאובטח לקטלוג, לסריקה ולאחסון של קובצי אימג' לקונטיינרים של Docker.

5. הקצאת אשכול GKE Autopilot

הסקריפט מספק אשכול Autopilot של Google Kubernetes Engine‏ (GKE) בשם hackathon-judge-cluster.

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

6. הגדרת נושאים ומינויים ב-Pub/Sub

הסקריפט מקצה את נושאי ההודעות (judging-tasks ו-judging-results) יחד עם המינויים המתאימים ל-worker ול-API.

למה אנחנו פורסים נושאים ומינויים ב-Pub/Sub: בדיקת קוד שנשלח היא תהליך איטי שדורש הרבה משאבים. שימוש בארכיטקטורה של תור הודעות מפריד בין ממשק ה-API הסינכרוני שפונה למשתמשים לבין צמתי העובדים. הקצה העורפי של ה-API דוחף משימות לנושא judging-tasks, וסוכני העובדים שולפים משימות כשהן זמינות, וכך מונעים חסימה של ה-API ומספקים יכולות של ניסיון חוזר אוטומטי.

7. הגדרה של מערכי נתונים, טבלאות וחיבורי AI ב-BigQuery

הסקריפט יוצר את מערך הנתונים hackathon_judge, מחיל סכימות מבניות של מסד נתונים SQL, טוען רשומות ראשוניות ומעניק את תפקידי ה-AI והאחסון הנדרשים לחשבון השירות של שירות החיבור BigQuery ML.

8. הפעלת תהליכי בנייה של קונטיינרים באמצעות Cloud Build

הסקריפט מפעיל את ההגדרה cloudbuild.yaml כדי לקמפל את ממשק המשתמש של React, את שרת ה-REST של Go, את העובד של Python ADK ואת ארגז החול של FastAPI, לארוז אותם בקובצי אימג' מבודדים של קונטיינר שתויגו באמצעות ה-SHA של ה-commit של Git במאגר הפעיל, ולשמור אותם ב-Artifact Registry.

9. רישום של הגדרות משאבים בהתאמה אישית (CRD) של ארגז החול של הסוכן

הסקריפט מוריד ומירשם את ההגדרות העדכניות של משאבים מותאמים אישית של ארגז החול לסוכנים של Kubernetes-sigs ‏ (manifest.yaml ו-extensions.yaml) כדי להרחיב את היכולות הבסיסיות של GKE.

למה אנחנו מתקינים את התשתית של ארגז החול של הסוכן: באשכולות Kubernetes רגילים אין תמיכה בהקצאה של ארגזי חול מוגנים על פי דרישה. רישום של CRD של ארגז החול לסוכנים מרחיב את רמת הבקרה של GKE, ומאפשר ל-Kubernetes לתזמר באופן מקורי מיקרו-קונטיינרים מאובטחים בתוך ארגז חול באמצעות משאבים בהתאמה אישית (כמו SandboxTemplates ו-SandboxClaims).

10. הגדרת מרחבי שמות, חשבונות שירות ו-Workload Identity

הסקריפט מקצה את מרחב השמות hackathon-judge, רושם חשבונות שירות של Kubernetes‏ (KSA) ומגדיר מיפוי של זהויות עומסי עבודה כדי להעניק תרמילים של GKE הרשאות יעד ב-Google Cloud.

11. פריסת נתב ארגז החול

הסקריפט מחיל את k8s/sandbox_router.yaml המניפסט, מתחיל את הפריסה של נתב ארגז החול והשירות וממתין עד שהם יגיעו לסטטוס תקין.

למה אנחנו פורסים את נתב ארגז החול: נתב ארגז החול הוא שער מרכזי של מישור הבקרה הפנימי. הוא חושף API פשוט שהסוכן של העובד ב-ADK קורא כדי לתבוע, לגשת או לשחרר ארגזי חול מאובטחים, לנהל מיפוי של ניתוב ולהפריד הקצאת פודים ברמת האשכול מלוגיקת האפליקציה.

6. הגדרת שער ארגז החול של הסוכן, טענות ו-WarmPool

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

משתני סביבה של המקור

לפני שמחילים תבניות שדורשות משתני סביבה, צריך להריץ את הסקריפט setup-env.sh כדי לנתח ולייצא את כל המשתנים הנדרשים למעטפת:

source ./setup-env.sh

החלת שער ארגז חול

פריסת השער שהוגדר במיוחד לניתוב תנועה לארגז החול:

kubectl apply -f k8s/sandbox-gateway.yaml

למה אנחנו פורסים את Sandbox Gateway:‏ Sandbox Gateway פועל כבקר כניסה מאובטח ובעל ביצועים גבוהים, שמוקדש רק לניתוב של ארגז החול. היא מבודדת את רשת ארגז החול ומספקת יעד מקומי מאובטח שמאפשר לסוכני העובדים לתקשר עם ארגזי חול שנוספו בלי לחשוף נקודות קצה חיצוניות.

שימוש בתבנית של בקשת גישה לארגז חול

משתמשים ב-envsubst כדי לאכלס את הגדרת תבנית הארגז עם משתני הסביבה הפעילים, ומחילים אותה:

source ./setup-env.sh
envsubst < k8s/sandbox-claim-template.yaml | kubectl apply -f -

למה אנחנו פורסים את תבנית התביעה של ארגז החול: תבנית התביעה של ארגז החול משמשת כתוכנית להגדרת הסביבה. הוא מציין את קובץ האימג' של הקונטיינר להרצה (שמגיע עם חבילה מראש של כלי פיתוח), פרמטרים של הסביבה (מזהה פרויקט GCP), יציאות ומגבלות משאבים (יעדי CPU/זיכרון). הוא מגדיר את GKE להפעיל את מופעי הקונטיינר האלה באמצעות gVisor (סביבת זמן ריצה של gVisor), כדי להבטיח שקוד של משתתפים לא מהימנים יפעל בשכבת בידוד נוספת של וירטואליזציה של ליבת המערכת.

החלת Sandbox WarmPool

מחילים את Sandbox WarmPool כדי לבצע אתחול מראש של ארגזי חול פעילים:

kubectl apply -f k8s/sandbox-warmpool.yaml

מוודאים שהמכונות הווירטואליות במאגר החם במצב המתנה הופעלו בהצלחה:

kubectl get pods -n hackathon-judge -l app=sandbox

למה אנחנו פורסים את Sandbox WarmPool: הקצאת משאבים, תזמון, שליפת תמונות והפעלה של תרמילי קונטיינרים חדשים על פי דרישה יוצרים תקורה משמעותית של הפעלה (זמני הפעלה במצב התחלתי (cold start) של 30 שניות ומעלה). ב-Sandbox WarmPool יש מאגר המתנה של תרמילי ארגז חול פעילים שחוממו מראש (5 עותקים כברירת מחדל). כשסוכן העובד מבקש סביבת הערכה, נתב ארגז החול מקצה מיד פוד שמוכן מראש, וכך מקצר את העיכובים בהפעלה למהירויות של פחות משנייה.

7. פריסת רכיבי אפליקציה

תשתית ארגז החול המאובטחת פעילה באופן מלא, ועכשיו אפשר לפרוס את ה-API המרכזי של ה-Backend, את סוכן העובד, את ממשק האינטרנט של React ואת מיפוי שער הכניסה.

פריסת קצה עורפי

פורסים את הבק-אנד של ה-API בארכיטקטורת REST של כלי התזמור:

source ./setup-env.sh
envsubst < k8s/backend.yaml | kubectl apply -f -

פריסת הסוכן

פריסת סוכן ADK לשיפוט עובדים:

source ./setup-env.sh
envsubst < k8s/agent.yaml | kubectl apply -f -

פריסת הקצה הקדמי

פורסים את ממשק המשתמש האינטראקטיבי באינטרנט:

source ./setup-env.sh
envsubst < k8s/frontend.yaml | kubectl apply -f -

הגדרת שער וניתוב חיצוניים

פריסת שער הכניסה הראשי ומיפוי נתיבי HTTP של כניסה לתנועת לקוחות חיצונית:

kubectl apply -f k8s/gateway.yaml

למה אנחנו פורסים את שער הכניסה החיצוני: השער החיצוני חושף את השירותים שלנו באמצעות Kubernetes Gateway API. הוא מקצה כתובת IP ציבורית עם איזון עומסים וממפה מסלולים על סמך כללי נתיב – מכוון בקשות API בנתיב /api/* אל הבק-אנד של Go וממפה את כל תנועת האינטרנט של הלקוח (/) אל הקצה הקדמי של React, וכך מאבטח את הגישה לאשכול הציבורי.

אימות השקות

חוסמים את ההרצה של מעטפת הפקודות וממתינים עד שכל שלושת פריסות שירות הליבה יגיעו למצב תקין של מוכנות להשקה:

kubectl rollout status deployment/backend -n hackathon-judge --timeout=300s
kubectl rollout status deployment/agent -n hackathon-judge --timeout=300s
kubectl rollout status deployment/frontend -n hackathon-judge --timeout=300s

8. אימות ושימוש באפליקציה

גישה לממשק המשתמש

מאחזרים את כתובת ה-IP הציבורית החיצונית של שער מאזן העומסים הראשי שהוקצה לאחרונה:

כדי לצפות בסטטוס ההקצאה בזמן אמת, מריצים את הפקודה עם הדגל watch ‏ (-w) ומחכים עד שכתובת IP ציבורית תאוכלס בשדה ADDRESS:

kubectl get gateway -n hackathon-judge hackathon-judge-gateway -w

אם ההקצאה בוצעה בהצלחה, הפלט אמור להיראות כך:

NAME                      CLASS    ADDRESS          PROGRAMMED   AGE
hackathon-judge-gateway   gke-l7   34.120.120.120   True         3m

אחרי שרואים כתובת IP ציבורית תקינה בעמודה ADDRESS והסטטוס PROGRAMMED הוא True, לוחצים על Ctrl+C כדי להפסיק את הצפייה.

למה אנחנו מקבלים את הסטטוס Gateway: Gateway API מטפל בתעבורה ציבורית נכנסת. בדיקת הסטטוס של השער מחזירה את כתובת ה-IP החיצונית הציבורית עם איזון העומסים שהוקצתה על ידי מאזן העומסים החיצוני הגלובלי של Google Cloud לאשכול שלנו, שמייצג את הכתובת הציבורית של הפלטפורמה שלנו.

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

שליחת משימות

  • משתמשים בממשק המשתמש של הקצה הקדמי כדי לנווט אל לוח הבקרה ולבחור את ההאקתון.

מרכז הבקרה

  • בכל אחד מהפרויקטים, אפשר ללחוץ על Run Agent כדי שהסוכן יתחיל לשפוט את הפרויקט כולו לפי קריטריון ההערכה.

פרויקטים

צפייה בהשקת ארגז החול

כדי לראות פוד ארגז חול שמוקצה ומסופק באופן דינמי לצורך שיפוט הביצוע, עוקבים אחרי הפודים הפעילים במרחב השמות hackathon-judge:

kubectl get pods -n hackathon-judge -w

כדי לראות את הלוגיקה של ההערכה באמצעות ADK, שלב אחר שלב, צריך לבדוק את הלוגים של ה-pod של סוכן העובד:

kubectl logs -l app=agent -n hackathon-judge

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

9. (אופציונלי) איך זה עובד

ארכיטקטורת ארגז החול של הסוכן

פונקציות ה-AI של BigQuery מצוינות להערכת הצעות מבוססות-טקסט וטענות בקובץ README, אבל כדי לשפוט פרויקט הנדסי צריך לקמפל קוד, להתקין ספריות של צד שלישי ולהריץ חבילות בדיקה אמיתיות.

הפעלת קוד משתמש גולמי יוצר סיכוני אבטחה משמעותיים, כולל פריצה למארח, פריצה למאגר וגישה לא מורשית למשאבים. המסגרת GKE Agent Sandbox מצמצמת את הסיכונים האלה באמצעות תזמור של עומסי עבודה מבודדים בארגז חול, תוך שימוש בווירטואליזציה של gVisor (runsc).

זרימת האינטראקציות עם המערכת

הדיאגרמה שלמטה ממפה איך האלמנטים השונים במערכת מבוססת-האירועים שלנו מתקשרים במהלך ביצוע שיפוט מאובטח בסביבת ארגז חול:

איך הכלים והרכיבים של המעורבות פועלים יחד

  • ממשק משתמש של Front-end ב-React: חושף ממשק אינטראקטיבי שבו משתמשים מגדירים מודלים של קריטריונים, רושמים צוותים, שולחים כתובות URL של פרויקטים ומעיינים בגיליונות סופיים של ציוני דירוג, כולל אי-התאמות מלאות בקבצים ותגובות הנדסיות.
  • ‫Go REST Backend API: מנהל נקודות קצה גלובליות של API. הוא שומר את הגדרות הפרויקט ב-BigQuery ומעביר משימות שיפוט ל-Pub/Sub כדי להפריד בין צינורות של ביצוע חישובים כבדים.
  • ‫Google Pub/Sub: ברוקר מבוסס-הודעות שמחזיק בבטחה הודעות של משימות בתור, ומנהל תקשורת אסינכרונית בין ה-API לבין מופעים פעילים של עובדים.
  • תהליך עבודה של Python ADK (סוכן Supervisor): תהליך עבודה ברקע ששולף משימות מ-Pub/Sub. הוא משתמש בערכה לפיתוח סוכנים (ADK) של Google כדי להפעיל סוכן מפקח ברמה גבוהה, שמקבל הוראה לתזמן את ההערכה. המפקח מפעיל את הכלי הראשי שלו, evaluate_repository, כדי להעביר את הבדיקה של פקודות גולמיות מורכבות.
  • ‫Sandbox Router & Gateway (GKE Control Plane): שער בקרה פנימי שרושם הגדרות סטנדרטיות של משאבים מותאמים אישית של Sandbox‏ (SandboxClaims, SandboxTemplates). הוא מתאם בין רשתות GKE כדי להקצות ולשמור על תרמילים, ומחזיר זרמי חיבור ללקוחות של העובדים.
  • ‫Sandbox WarmPool: כדי למנוע זמני הפעלה ארוכים של קונטיינרים ב-GKE (הפעלות במצב התחלתי של 30 שניות ומעלה), ה-WarmPool שומר על פודים פעילים במצב המתנה. כשמבצעים תביעה על ארגז חול, הנתב ממפה אותו באופן מיידי תוך פחות משנייה, ואז מתזמן את המיחזור שלו אחרי השחרור.
  • בידוד gVisor‏ (runsc): ליבה וירטואלית של סביבת המשתמש שפועלת כגבול מאובטח של ארגז חול. היא מיירטת קריאות למערכת ממרחב המאגר לליבות של צומתי GKE, כדי לוודא שפקודות גולמיות מסוכנות (כמו סקריפטים של המערכת או הגדרות של חבילות) מופעלות בבידוד וירטואלי מוחלט.
  • FastAPI Sandbox Runtime: שרת API בשפת Python קל משקל שפועל בתוך קונטיינר ארגז החול. הוא חושף נקודות קצה מאובטחות (/execute, /upload, /download) שמאפשרות לכלי עובדים חיצוניים לבצע מניפולציות בקבצים ולהפעיל משימות של מעטפת.
  • ‫Gemini CLI (@google/gemini-cli): סקריפט של סוכן אוטונומי שמותקן בארגז החול. כשמפעילים אותו באמצעות דגל זמן הריצה של סביבת הפיתוח (--yolo), הוא משתמש בגיליון הוראות מפורט לדירוג (prompt.md) ובהגדרת קריטריונים (criteria.md) כדי:
    • לנתח באופן דינמי את ההיררכיה של בסיס הקוד (באמצעות כלים כמו tree או ripgrep).
    • התקנה אוטומטית של הדרישות (באמצעות פקודות כמו npm install, ‏ pip install, ‏ go build).
    • מריצים בדיקות פיתוח אמיתיות (כמו npm test או pytest) כדי לאמת את הפונקציונליות.
    • התקשרות למודלים של Vertex AI (באמצעות פרטי הכניסה של שיוך Workload Identity לעומסי עבודה של הקונטיינר) כדי להעריך את הלוגיקה של הקובץ, לבצע בדיקה צולבת של הטענות מול קובץ ה-README, לזהות תכונות רפאים, לתעד בעיות באיכות ולכתוב דוח מובנה של כרטיס ניקוד אל evaluation.json.
  • סביבות פיתוח רגילות: חבילה של node,‏ npm,‏ yarn,‏ pnpm,‏ python,‏ pip,‏ uv,‏ go,‏ gh,‏ git,‏ tree,‏ ripgrep ו-playwright בקובץ אימג' של קונטיינר של ארגז החול, שנותנת לסוכן המשנה האוטונומי סביבת עבודה מלאה לבדיקה.

10. מחיקה

כדי להימנע מחיובים שוטפים בחשבון Google Cloud, מוחקים את המשאבים שנוצרו במהלך ה-codelab הזה.

./destroy.sh

למה אנחנו מנקים משאבים: החיוב ב-Google Cloud מבוסס על מודל של ניצול משאבים. משאבים פעילים כמו אשכולות GKE Autopilot, מאזני עומסים ברשת ודיסקים קשיחים גוררים חיובים שוטפים גם כשהם לא פעילים. הפעלת השלב הזה מוחקת את מרחב השמות של האשכול כדי לנקות את אובייקטי Kubernetes, ומוחקת את המארח של אשכול GKE Autopilot כדי להפסיק באופן מיידי את כל החיובים הבסיסיים.

11. מזל טוב

מעולה! פרסתם בהצלחה את אפליקציית השופט בתחרות ההאקתון עם Agent Sandbox ב-GKE.

הטמעתם פלטפורמת AI מאובטחת ומודרנית מבוססת-אירועים, שיכולה לבדוק ולהעריך בסיס קוד שנשלח ממקורות לא מהימנים, במסגרת מגבלות אבטחה מבודדות של קונטיינרים.

מה למדתם

  • תשתית GKE: איך להקצות GKE Autopilot ושירותי Google Cloud תומכים כמו Pub/Sub ו-BigQuery.
  • הגדרת ארגז חול של סוכן: איך מגדירים הגדרות של משאבים מותאמים אישית, SandboxTemplates,‏ SandboxClaims ו-Sandbox WarmPools עם ביצועים גבוהים.
  • פריסת מיקרו-שירותים: איך להגדיר קישורים של Workload Identity ולפרוס ארכיטקטורת מיקרו-שירותים מרובת רכיבים (Frontend React,‏ REST Go,‏ Worker ADK Agent וארגז חול מבודד).
  • ארגז חול מאובטח: איך משתמשים בקונטיינרים וירטואליים של gVisor כדי להריץ בצורה מאובטחת פקודות של צד שלישי לא מהימן בצמתים של GKE.

השלבים הבאים

מסמכים לדוגמה