גבולות בין פרויקטים

גבולות ניהול בין פרויקטים (או גבולות) מאפשרים לכם לגלות, לנהל ולפקח על סוכני AI, שרתי Model Context Protocol‏ (MCP) וכלים בכמה פרויקטים ב- Google Cloud . כברירת מחדל, Agent Registry פועל בתוך פרויקט ניהול אחד, אבל אם מגדירים גבול ניהול ב-Resource Manager, פרויקט ניהול מרכזי יכול לצבור סוכנים, שרתי MCP וכלים בפרויקטים חברים מבוזרים. כדי לתכנן טופולוגיות של כמה פרויקטים שניתנות להתאמה לעומס, חשוב להבין איך גבולות הניהול מגדירים את התפקידים בפרויקט, את צבירת המשאבים ואת בקרת הגישה.

כדי להגדיר גבול ניהול, קראו את המאמר הגדרת גבול ניהול למספר פרויקטים.

מודל גבולות

אתם מגדירים גבול ניהול בתיקייה או בארגון במנהל המשאבים:

  • גבול ברמת התיקייה או הארגון: כברירת מחדל, אם יוצרים גבול בתיקייה או בארגון בלי להגדיר מסנן תגים, הגבול כולל את כל הפרויקטים הצאצאים באותה תיקייה או באותו ארגון בתור פרויקטים חברים.
  • גבולות שמסוננים לפי תגים (אופציונלי): אם רוצים לחלק פרויקטים צאצאים בתיקייה או בארגון לכמה גבולות, אפשר לסנן את החברות בגבולות באמצעות תגים של מנהל המשאבים. לדוגמה, אפשר להפריד בין סביבות prod ו-dev. מצרפים תגים לGoogle Cloud פרויקטים שרוצים לכלול בכל גבול. אם לפרויקט צאצא בתיקייה או בארגון יש תג שתואם למסנן הגבולות, הפרויקט הזה הופך לפרויקט חבר בגבול הניהול.

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

  • רישום דינמי ואוטומטי: סביבות ענן משנות פרויקטים לעיתים קרובות. כשמתייגים פרויקט בערך תג רשום, כמו env=prod, הפרויקט נכלל באופן אוטומטי כפרויקט חבר בגבול של Agent Registry, בלי שצריך לעדכן ידנית את הגדרות הגבול.
  • הפרדה מהיררכיות של תיקיות: מבני התיקיות של מנהל המשאבים בדרך כלל מאורגנים למטרות חיוב או למטרות עסקיות. התגים מפרידים בין הגדרות הגבולות לבין ההיררכיות הפיזיות של התיקיות, ומאפשרים לכם להגדיר היקפי ניהול של תיקיות חוצות בתיקיית הורה או בארגון.
  • ירושה וסקלביליות: תגים שמוחלים על ארגון או תיקייה מועברים באופן אוטומטי בהיררכיית המשאבים לתיקיות ולפרויקטים הצאצאים. מודל ההעברה בירושה הזה מאפשר לכם לרשום ענפים שלמים של עץ המשאבים באמצעות הקצאת תג אחת.
  • ניהול מרכזי: התגים כפופים להרשאות מרכזיות של ניהול זהויות והרשאות גישה (IAM). אם תשתמשו בתגים כדי להגדיר גבולות ניהול, תוכלו למנוע ממשתמשים בודדים להוסיף או להסיר פרויקטים מהגבול באופן שרירותי.

ארכיטקטורה ומשאבים עיקריים

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

  • הגדרת גבולות (משאב BoundaryConfig): משאב הגדרה בארגון או בתיקייה ב-Resource Manager, שקובע את כללי החלוקה לגבולות באותה תיקייה או באותו ארגון. אם לא מגדירים מפתח תג במשאב BoundaryConfig, הארגון או התיקייה תומכים בגבול אחד שכולל את כל הפרויקטים הצאצאים. כדי לחלק פרויקטים צאצאים לכמה גבולות שמסוננים לפי תגים, המשאב BoundaryConfig מציין את מפתח התג של המשאב היחיד, כמו 123456789012/env, שמשמש להערכת החברות בפרויקט באותה תיקייה או באותו ארגון.

  • ‫Boundary (משאב Boundary): גבולות של פרויקטים ששייכים לארגון או לתיקייה. בלי מסנן תגים, הגבול כולל את כל הפרויקטים הצאצאים בארגון או בתיקייה ההורה. כשמגדירים מפתח תג במשאב ההורה BoundaryConfig, המשאב Boundary מציין מסנן של ערך תג, כמו env=prod, ופרויקטים צאצאים שיורשים את ערך התג הזה או מצרפים אותו שייכים לגבול באופן אוטומטי. בגלל שבמשאב BoundaryConfig של ההורה יש מפתח תג אחד, ולפרויקט יכול להיות רק ערך תג אפקטיבי אחד לכל מפתח תג, פרויקט יכול להשתייך לכל היותר לגבול אחד לכל תיקיית הורה או ארגון הורה.

  • הגדרת יכולת (משאב CapabilityConfig): משאב שמוגדר בארגון, בתיקייה או בפרויקט. ברמת הארגון או התיקייה, היא מקשרת גבול אחד או יותר לפרויקט ניהול ייעודי ומציינת את יכולות הניהול שמופעלות בגבולות האלה. ברמת הפרויקט, הוא מאפשר יכולות ניהול לפרויקט עצמאי אחד ללא גבולות. ב-Agent Registry, מגדירים את היכולת AGENT_MANAGEMENT (ב-Google Cloud CLI: ‏agent-management), שמאפשרת גילוי רכיבים מרכזי, סיכום חיפושים ופיקוח על פרויקטים שונים ב-Agent Registry, ומפעילה באופן אוטומטי את agentregistry.googleapis.com בפרויקט הניהול.

למידע נוסף על המשאבים האלה של מנהל המשאבים, קראו את הסקירה הכללית על גבולות ויכולות הניהול.

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

תרשים שממחיש איך המשאבים של Cloud Resource Manager מקשרים בין פרויקטים חברים לפרויקט ניהול מרכזי.
איור 1. ארכיטקטורה של גבול ניהול בין פרויקטים, שמחבר פרויקטים חברים לפרויקט ניהול מרכזי.

ניהול של כמה פרויקטים

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

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

פרויקט ניהול

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

ב-Agent Registry, פרויקט הניהול מבצע את הפונקציות הבאות:

  • קישור גבולות ויכולות: משויך לגבול אחד או יותר ב-Resource Manager באמצעות משאב CapabilityConfig כשהיכולת AGENT_MANAGEMENT מופעלת. איך מגדירים גבולות ניהול
  • חיפוש וגילוי מרכזיים: משמש כפרויקט היעד לבקשות חיפוש ורשימות בפרויקטים שונים, ומאפשר לתזמנים, למפתחים ולאפליקציות לקוח לקיים אינטראקציה עם סוכנים, שרתי MCP וכלים שמתגלים באופן אוטומטי בכל הפרויקטים החברים בגבול.
  • רישום משאבים ברמת גבולות הניהול: מארח משאבים שנרשמו באופן ידני ב-Service, כמו סוכנים בהתאמה אישית, שרתי MCP חיצוניים ונקודות קצה, ומשאבים ב-Binding כשרוצים שהמשאבים האלה יהיו גלויים בכל גבולות הניהול.
  • ניהול מרכזי של ממשקי API, חיובים ומכסות: ריכוז של הפעלת Agent Registry API, הקצאת מכסות וחיובים לפעולות גילוי ופיקוח ברמת הגבול.

כשמגדירים משאב CapabilityConfig בתיקייה או בארגון ב-Resource Manager, אפשר להקצות את פרויקט הניהול באחת מהדרכים הבאות:

  • פרויקט ניהול בניהול עצמי: אתם מגדירים פרויקטGoogle Cloud קיים שאתם מנהלים, על ידי העברת הדגל --management-project כשאתם יוצרים את המשאב CapabilityConfig. הפרויקט חייב להיות ישירות באותה תיקיית הורה או באותו ארגון כמו המשאב CapabilityConfig, והוא לא יכול לשמש כפרויקט ניהול של משאב CapabilityConfig אחר. אם תמחקו את המשאב CapabilityConfig, מנהל המשאבים ישמור את הפרויקט בניהול עצמי ויחזיר אותו למצב של פרויקט רגיל.
  • פרויקט ניהול שמנוהל על ידי Google: משמיטים את הדגל --management-project כשיוצרים את המשאב CapabilityConfig, ומנהל המשאבים יוצר ומנהל באופן אוטומטי פרויקט חדש בתיקיית ההורה או בארגון ההורה. לפרויקט שנוצר יש קידומת של מזהה פרויקט google-mpf או google-mpo. אם תמחקו את המשאב CapabilityConfig, מנהל המשאבים ימחק את הפרויקט הזה שמנוהל על ידי Google.

בשני המקרים, יצירת המשאב CapabilityConfig באמצעות agent-management מפעילה באופן אוטומטי את agentregistry.googleapis.com בפרויקט הניהול.

פרויקטים של חברים

פרויקטים חברים הם הפרויקטים ב- Google Cloud ששייכים לגבול ניהול. הם יכולים להיות כל הפרויקטים הצאצאים בתיקיית ההורה או בארגון ההורה של הגבול, או הפרויקטים הצאצאים שתואמים למסנן אופציונלי של תגי גבול, כמו env=prod. סוכנים, שרתי MCP וכלים שמתגלים באופן אוטומטי פועלים בפרויקטים של חברים.

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

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

רישום ואוסף נתונים

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

משאבים שזוהו ונרשמו באופן אוטומטי

ההיקף של משאב בגבולות הניהול תלוי באופן שבו הוא רשום:

  • סוכנים ושרתי MCP שמתגלים באופן אוטומטי: משאבים נתמכים שנפרסים בפרויקטים חברים, כמו מנועי חשיבה רציונלית של Agent Runtime, שירותי Cloud Run ופריסות GKE, נקלטים באופן אוטומטי בפרויקט החבר שבו הם נפרסים ונצברים בפרויקט הניהול.

  • משאבים וקישורים שנרשמו ידנית: משאבי Service שנרשמו ידנית, כמו סוכנים בהתאמה אישית, שרתי MCP חיצוניים, נקודות קצה ומשאבי Binding, מוגדרים ברמת הפרויקט שבו הם נוצרו:

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

  • מיומנויות, בעלי תוכן דיגיטלי ואפליקציות AI עצמאיים: משאבים עצמאיים בהתאמה אישית של Skill,‏ SkillRevision,‏ Publisher ו-AiApplication מוגדרים ברמת הפרויקט שבו הם נוצרו, ולא נצברים בפרויקטים החברים בגבול הניהול. רושמים מיומנויות עצמאיות בהתאמה אישית ואפליקציות מבוססות-AI בפרויקט שבו הסוכנים או המפתחים צריכים לגלות אותן. סקילים עצמאיים שמנוהלים על ידי Google ניתנים לגילוי בכל פרויקט באופן אוטומטי.

אוסף שאילתות מרכזי

ההיקף של המיקומים ב-Agent Registry תלוי בשאלה אם אתם שולחים שאילתה לפרויקט פיקוח עצמאי, או לפרויקט חבר או לפרויקט ניהול בגבולות הניהול:

  • פרויקטים עצמאיים של ניהול ופרויקטים חברים: שאילתות במיקום שנתמך ב-Agent Registry, כמו us-central1,‏ europe-west1,‏ us,‏ eu או global, מחזירות רק משאבים במיקום הזה לאותו פרויקט, בלי סיכום של כמה פרויקטים.

  • פרויקט ניהול: כשמפעילים משאב CapabilityConfig עם agent-management בפרויקט ניהול, יש תמיכה באוסף נתונים מצטברים בפרויקטים שונים בכל המיקומים שנתמכים ב-Agent Registry. כששולחים שאילתה לגבי מיקום בפרויקט הניהול, המשאבים נאספים באותו מיקום בפרויקט הניהול ובכל הפרויקטים החברים בגבולות הניהול. האוסף הזה לא כולל משאבים ממיקומים שונים:

    • אזורים יחידים: שאילתות באזור יחיד, כמו us-central1 או europe-west1, צוברות סוכנים ושרתי MCP שזוהו באופן אוטומטי ונפרסו באותו אזור יחיד בפרויקט הניהול ובפרויקטים החברים בו, לצד משאבי Service ו-Binding שנוצרו באותו אזור בפרויקט הניהול.
    • מספר אזורים: שאילתות במספר אזורים, כמו us או eu, צוברות סוכנים ושרתי MCP שזוהו באופן אוטומטי ונפרסו במספר האזורים הזה בפרויקט הניהול ובפרויקטים החברים בו. שאילתות במספר אזורים לא צוברות משאבים שנפרסו באזורים בודדים.
    • גלובלי: שאילתות במיקום global צוברות סוכנים ושרתי MCP שזוהו באופן אוטומטי ונפרסו ב-global בפרויקט הניהול ובפרויקטים החברים בו, לצד משאבי Service ו-Binding שנוצרו ב-global בפרויקט הניהול. שאילתות ב-global לא צוברות משאבים שנפרסו במספר אזורים או באזורים בודדים.

כשמציגים, מחפשים או מאחזרים רכיבים של סוכנים במיקום מסוים בפרויקט הניהול, Agent Registry מבצע את הפעולות הבאות:

  1. מזהה את כל הפרויקטים החברים שמשויכים לפרויקט הניהול באמצעות המשאב הפעיל CapabilityConfig.
  2. השאילתה מחפשת סוכנים ושרתי MCP שזוהו אוטומטית במיקום הזה בפרויקט הניהול ובכל פרויקט חבר, לצד משאבי Service שנוצרו במיקום הזה בפרויקט הניהול ונרשמו ידנית.
  3. הוא צובר משאבים תואמים לקבוצת תוצאות מאוחדת.
  4. השירות מחזיר לכם את התוצאות המצטברות.

אם כמה גבולות מצורפים לאותו משאב CapabilityConfig, ‏Agent Registry צובר פרויקטים של חברים מכל הגבולות המצורפים לאותו מרשם של פרויקט ניהול. כדי לצמצם את הרשימה או את תוצאות החיפוש בפרויקט הניהול לפרויקט חבר יחיד, מעבירים את --filter="project_id=MEMBER_PROJECT_ID". אם שתי סביבות דורשות הרשאות גישה נפרדות, צריך ליצור פרויקט נפרד לניהול משאבים ב-CapabilityConfig לכל גבול.

בחיפוש בפרויקט יחיד ובחיפוש בכמה פרויקטים משתמשים באותן שיטות API. היקף החיפוש תלוי בשאלה אם הפרויקט המטורגט הוא פרויקט חבר או פרויקט ניהול.

שמות של משאבים בתחום ניהול אחר

כשמצרפים רכיב לפרויקט חבר, Agent Registry מקצה לו מזהה, כמו AGENT_ID או SERVER_ID. כשמציגים, מחפשים או מקבלים רכיב מעבר לגבולות הניהול, Agent Registry שומר על המזהה של הרכיב הזה ומעצב את שם המשאב המשויך על סמך הפרויקט שבו משתמשים:

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

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

סוג המשאב בקש כתובת אתר שם המשאב המשויך
Agent projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/agents/AGENT_ID projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/agents/AGENT_ID
projects/MEMBER_PROJECT_ID/locations/LOCATION/agents/AGENT_ID projects/MEMBER_PROJECT_ID/locations/LOCATION/agents/AGENT_ID
שרת MCP projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID
projects/MEMBER_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID projects/MEMBER_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID

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

תצוגה חזותית של טופולוגיה וזרימת תנועה

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

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

  • מתאם הפניות בזמן ריצה: מתאם בין מזהה הסוכן הלוגי לבין ההפניה בזמן ריצה הפיזית שלו. ההתאמה הזו מאפשרת למפעילים לעקוב אחרי סוכן ב-Agent Registry ישירות למנוע החשיבה הרציונלית הבסיסי של Agent Runtime, לשירות Cloud Run או לפריסת GKE.
  • קישורים בין פרויקטים: מציג קישורים בין סוכני ניהול בפרויקט אחד לבין שרתי MCP או כלים במורד הזרם בפרויקט אחר.
  • אימות היקף: עוזר לאדמינים לוודא שהתקשורת של הנציג תואמת להיקפים של VPC Service Controls, ומנותבת דרך נקודות קצה ייעודיות של Agent Gateway.

בקרת גישה

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

במשאבים שנמצאים בגבולות הניהול, ההגבלות של VPC Service Controls חלות רק על אינטראקציות של Agent Registry בפרויקט הניהול. ב-Agent Registry אפשר לגלות סוכנים ושרתי MCP בכל הפרויקטים שחברים בגבולות הניהול, גם אם הפרויקטים האלה לא נמצאים באותם גבולות גזרה לשירות כמו פרויקט הניהול.

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

המאמרים הבאים