הגדרת מאגרי עובדים לבנייה (פריסת מקור)

כשפורסים את קוד המקור ב-Cloud Run, קוד המקור הזה מאוחסן בקטגוריה של Cloud Storage. לאחר מכן, Cloud Build יוצר באופן אוטומטי את הקוד שלכם ב<b>קובץ אימג' של קונטיינר</b> ומעביר את התמונה הזו למאגר תמונות. כל בנייה מופעלת על עובד משלה. ‫Cloud Run מייבא את קובץ האימג' שנוצר במהלך הפריסה.

אם רוצים להתאים אישית את מאגר העובדים של גרסת ה-build ש-Cloud Build משתמש בו בהקשר של גרסת build מאובטחת ב-VPC Service Controls, צריך להתאים אישית את מאגר העובדים. הדף הזה רלוונטי למפתחי פלטפורמות שפורסים שירותים או פונקציות של Cloud Run ממקור באמצעות Google Cloud CLI, ומגדירים מאגרי IP פרטיים שמשמשים את Cloud Build. הדגלים של ה-CLI של gcloud לניהול מאגרי עובדי בנייה נתמכים בפריסות של קוד מקור (--source), ולא נתמכים בפריסות של קובץ אימג' של קונטיינר (--image).

לפני שמתחילים

• מפעילים את Cloud Run Admin API ואת Cloud Build APIs.

  תפקידים שנדרשים להפעלת ממשקי API

  כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

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

  אחרי שמפעילים את Cloud Run Admin API, נוצר באופן אוטומטי חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.

התפקידים הנדרשים

אתם או האדמין שלכם צריכים להעניק לחשבון הפריסה ולחשבון השירות של Cloud Build את תפקידי ה-IAM הבאים.

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

כדי לקבל את ההרשאות שדרושות לבנייה ולפריסה ממקור, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

• Cloud Run Source Developer (roles/run.sourceDeveloper) בפרויקט
• Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) בפרויקט
• משתמש בחשבון שירות (roles/iam.serviceAccountUser) בזהות של שירות Cloud Run

לחצו כדי לראות את התפקידים הנדרשים לחשבון השירות של Cloud Build

Cloud Build משתמש אוטומטית בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כחשבון השירות שמוגדר כברירת מחדל ב-Cloud Build כדי לבנות את קוד המקור ואת משאב Cloud Run, אלא אם משנים את ההתנהגות הזו. כדי ש-Cloud Build יוכל לבצע build של המקורות, צריך לבקש מהאדמין להעניק את התפקיד Cloud Run Builder (roles/run.builder) לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine בפרויקט:

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:[e-mail] \
      --role=roles/run.builder
  

מחליפים את PROJECT_NUMBER במספר הפרויקט ואת PROJECT_ID במזהה הפרויקט. Google CloudGoogle Cloudהוראות מפורטות לאיתור מזהה הפרויקט ומספר הפרויקט זמינות במאמר יצירה וניהול של פרויקטים.

הענקת תפקיד ה-builder ב-Cloud Run לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לוקחת כמה דקות עד שהיא מופצת.

הערה:

iam.automaticIamGrantsForDefaultServiceAccounts אילוץ מדיניות הארגון iam.automaticIamGrantsForDefaultServiceAccounts מונע מחשבונות שירות שמוגדרים כברירת מחדל לקבל את התפקיד 'עריכה' באופן אוטומטי. אם יצרתם את הארגון אחרי 3 במאי 2024, האילוץ הזה נאכף כברירת מחדל.

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

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

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

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

כברירת מחדל, ל-Cloud Build יש גישה בלתי מוגבלת לאינטרנט במהלך תהליך ה-build. אם הגדרתם גבולות גזרה של VPC Service Controls (VPC SC) ואתם רוצים להגביל את הגישה של ה-build רק לתלות שמאוחסנת בתוך גבולות הגזרה (לדוגמה, חבילות npm), אתם יכולים להשתמש בתכונה Cloud Build private worker pools.

באופן כללי, כדי להגדיר מאגר פרטי:

1. יוצרים מאגר פרטי של עובדים. איך יוצרים ומנהלים מאגרי עותקים פרטיים?

2. מגדירים את היקף האבטחה של VPC Service Controls. שימוש ב-VPC Service Controls

3. אם מאגר העובדים הפרטי נמצא בפרויקט אחר משירות Cloud Run, צריך להקצות לסוכן השירות של Cloud Run‏ ([e-mail]) את התפקיד משתמש במאגר עובדים של Cloud Build‏ (cloudbuild.workerPoolUser), כדי ששירות Cloud Build יוכל לגשת למאגר העובדים.

   gcloud projects add-iam-policy-binding PRIVATE_POOL_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/cloudbuild.workerPoolUser

   מחליפים את:

   • ‫PROJECT_NUMBER עם מספר הפרויקט שבו השירות פועל.
   • ‫PRIVATE_POOL_PROJECT_ID במזהה הפרויקט שבו נמצא מאגר העובדים. מידע נוסף זמין במאמר בנושא הרצת בנייה במאגר פרטי.

4. פריסת השירות מהמקור לבנייה באמצעות מאגר פרטי:

   gcloud

   כדי לציין מאגר פרטי לבנייה כשפורסים מקוד מקור, משתמשים בדגל --build-worker-pool:

   gcloud run deploy SERVICE \
       --source . \
       --build-worker-pool WORKER_POOL

   מחליפים את:

   • ‫SERVICE בשם השירות.
   • ‫WORKER_POOL בשם של המאגר הפרטי.

   אם אתם פורסים פונקציה, מוסיפים את הדגל --function עם נקודת הכניסה של הפונקציה מקוד המקור.

מחיקת מאגרי עובדים של build

אפשר למחוק מאגרי עובדים של build בשירותים קיימים.

gcloud

כדי לנקות את מאגר העובדים של Cloud Build לצורך פריסות של מקורות, משתמשים בדגל --clear-build-worker-pool:

gcloud run deploy SERVICE \
    --source . \
    --clear-build-worker-pool WORKER_POOL

מחליפים את:

• ‫SERVICE בשם השירות.
• ‫WORKER_POOL בשם המאגר הפרטי שרוצים למחוק.

אם אתם פורסים פונקציה, מוסיפים את הדגל --function עם נקודת הכניסה של הפונקציה מקוד המקור.