סקירה כללית של תהליך ה-build

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

שימו לב: הוצאנו משימוש את Container Registry. החל מ-18 במרץ 2025, שירות Container Registry ייסגר, ולא תהיה אפשרות לכתוב קובצי אימג' ב-Container Registry. פרטים על הוצאה משימוש ועל העברה ל-Artifact Registry זמינים במאמר בנושא הוצאה משימוש של Container Registry.

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

הפעלת תהליך build בתוך הפרויקט שלכם אומרת:

• יש לכם גישה ישירה לכל יומני הבנייה.

• אין מכסת זמן build מוגדרת מראש, אבל ל-Cloud Build יש מכסת מקבילות ברירת מחדל משלו.

• אתם יכולים לראות את קובץ האימג' הנוכחי של הקונטיינר ואת קובצי האימג' של הקונטיינרים שנפרסו בעבר, שניהם מאוחסנים ב-Artifact Registry.

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

  • אם יוצרים פונקציה, נוצרת קטגוריית העלאה כדי לאחסן את קוד המקור. שם קטגוריית ההעלאה הוא gcf-uploads-PROJECT_NUMBER-REGION.cloudfunctions.appspot.com.
  • אחרי העלאת הקוד, קוד הפונקציה מאוחסן בקטגוריית מקור נפרדת:
    • אם משתמשים בהצפנה שמוגדרת כברירת מחדל, שם הקטגוריה הוא gcf-sources-PROJECT_NUMBER-REGION.
    • אם הנתונים מוגנים באמצעות CMEK, שם הקטגוריה הוא gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH.
  • אין תקופת שמירה גם בקטגוריית המקור וגם בקטגוריית ההעלאה.

הערה: אם מוחקים בטעות פונקציית Cloud Run, אפשר לשחזר אותה באמצעות קובצי המקור ממאגר gcf-sources. לשם כך, צריך להוריד את קובץ ה-ZIP ולפרוס אותו מחדש. הערה: gcf-sources bucket שומר רק את שתי הגרסאות האחרונות של קוד המקור. כשמבצעים ניקוי, מחיקת הפונקציה והשבתת Cloud Run functions API לא יגרמו למחיקה אוטומטית של דלי gcf-sources. כדי להסיר באופן מלא את כל המשאבים שקשורים לפונקציות Cloud Run, צריך למחוק ידנית את gcf-sourcesהבאקט

.

מאפיינים של תהליך ה-build

תהליך ה-build כולל את המאפיינים הבאים:

• צריך להפעיל את Cloud Build API בפרויקט.

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

• תהליך ה-build כולו מתבצע בהקשר של הפרויקט, ולכן הפרויקט כפוף לתמחור של המשאבים הכלולים:

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

  • למידע על התמחור של Cloud Storage, אפשר לעיין בדף התמחור. ‫Cloud Storage מספק תוכנית בחינם: פרטים נוספים מופיעים במסמך התמחור.

  • למחירון של Artifact Registry, אפשר לעיין בדף תמחור.

  • למחירון של Container Registry (יצא משימוש), אפשר לעיין בדף מחירון.

• תהליך הבנייה כרוך בחיוב, ולכן לפרויקט צריך להיות מצורף חשבון לחיוב ב-Cloud.

הערה: אם אתם משתמשים ב-gcp.resourceLocations במגבלות של מדיניות הארגון, אתם צריכים לכלול את המיקום המתאים של מספר אזורים. לדוגמה, אם אתם מבצעים פריסה באחד מאזורי us, אתם צריכים לכלול את us-locations. כך Cloud Build יכול לגשת לקטגוריית האחסון של Artifact Registry.

הצגת יומני התמונות של ה-build

יתרון מרכזי של תהליך בניית קובץ האימג' בפרויקט המשתמש הוא הגישה ליומני ה-build. אפשר להשתמש ב-CLI של gcloud או במסוף Google Cloud כדי להגיע ליומנים, שזמינים דרך Cloud Logging.

gcloud

1. פורסים את הפונקציה באמצעות gcloud functions deploy הפקודה.

2. כתובת ה-URL של היומנים מוצגת כחלק מהתשובה בחלון המסוף. לדוגמה:

   Deploying function (may take a while - up to 2 minutes)...⠹
   **For Cloud Build Stackdriver Logs**, visit:
   https://console.cloud.google.com/logs/viewer?project=&advancedFilter=resource.type%
   3Dbuild%0Aresource.labels.build_id%3D38d5b662-2315-45dd-8aa2-
   380d50d4f5e8%0AlogName%3Dprojects%2F%
   2Flogs%2Fcloudbuild
   Deploying function (may take a while - up to 2 minutes)...done.

מסוף Google Cloud

1. בחלון Cloud Run functions Overview, לוחצים על שם פונקציית Cloud Run שרוצים לבדוק.
2. לוחצים על הכרטיסייה פרטים.
3. בחלונית General Information, לוחצים על הקישור Container build log כדי לפתוח את החלונית Logs explorer.
4. כדי לראות את הפרטים של רשומה מסוימת ביומן הבנייה, לוחצים על השורה שלה. אם מדובר בערך שגיאה שמשויך לקובץ, הפרטים האלה כוללים את השם, השורה והעמודה של הקובץ.

מאגר תמונות

חשוב: החל מ-18 בפברואר 2025, פריסות של פונקציות Cloud Run (דור ראשון) יעברו לשימוש ב-Artifact Registry, ללא קשר לבחירה הקודמת. השינוי הזה נועד לאפשר סגירה של Container Registry בלי להשפיע על פונקציות מהדור הראשון שעדיין מצביעות על Container Registry.

פונקציות Cloud Run משתמשות ב-Artifact Registry כדי לאחסן את האימג'ים שנבנו מקוד המקור של הפונקציה. התמונות מאוחסנות במאגר בשם REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts.

מאגר ה-Artifact Registry צריך להיות באותו פרויקט כמו הפונקציה. כדי ליצור או לעדכן פונקציה שמבוססת על Artifact Registry:

gcloud

כדי להשתמש ב-Customer managed Artifact Registry, מריצים את הפקודה הבאה:

gcloud functions deploy --no-gen2 FUNCTION \
--docker-repository=REPOSITORY
[FLAGS...]

מחליפים את מה שכתוב בשדות הבאים:

• ‫FUNCTION: השם של הפונקציה.
• ‫REPOSITORY: השם המלא של מאגר Artifact Registry, בפורמט הבא: projects/PROJECT_NAME/locations/LOCATION/repositories/REPOSITORY.

בשביל Google-managed Artifact Registry, משתמשים ב:

gcloud functions deploy --no-gen2 FUNCTION \
--docker-registry=artifact-registry
[FLAGS...]

מסוף Google Cloud

1. נכנסים לדף פונקציות Cloud Run במסוף Google Cloud :
   כניסה לדף פונקציות Cloud Run

2. לוחצים על שם הפונקציה שרוצים להשתמש ב-Artifact Registry בשבילה.

3. לוחצים על Edit.

4. לוחצים על Runtime, build... כדי להרחיב את אפשרויות ההגדרה המתקדמות.

5. לוחצים על Security and Image Repo (מאגר תמונות ואבטחה) בסרגל התפריטים כדי לפתוח את הכרטיסייה 'אבטחה'.

6. בקטע מאגר תמונות, בוחרים אחת מהאפשרויות הבאות, בהתאם לסוג של Artifact Registry שבו אתם משתמשים:

   • Artifact Registry בניהול הלקוח. אפשר להשתמש באפשרות הזו אם הגדרתם מאגר Docker משלכם.
   • ‫Google managed Artifact Registry. אפשר להשתמש באפשרות הזו אם אתם רוצים להשתמש במאגר Docker שמנוהל על ידי Google במקום להגדיר מאגר משלכם.

7. ב-Customer managed Artifact Registry, משתמשים בתפריט הנפתח Artifact registry כדי לבחור את מאגר Artifact Registry הרצוי, או פועלים לפי ההנחיות ויוצרים מאגר חדש.

8. לוחצים על הבא.

9. לוחצים על פריסה.

למידע מפורט על התמחור, ראו תמחור של פונקציות Cloud Run.

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

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

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

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

2. מגדירים את גבולות הגזרה של VPC Service Controls. שימוש ב-VPC Service Controls

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

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

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

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

gcloud

gcloud functions deploy FUNCTION_NAME --no-gen2\
  --runtime RUNTIME \
  --build-worker-pool PRIVATE_POOL_NAME
  [FLAGS...]

כאשר FUNCTION_NAME הוא שם הפונקציה, RUNTIME הוא זמן הריצה שבו אתם משתמשים ו-PRIVATE_POOL_NAME הוא שם המאגר.

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

gcloud functions deploy FUNCTION_NAME --no-gen2 \
  --runtime RUNTIME \
  --clear-build-worker-pool
  [FLAGS...]

כאשר FUNCTION_NAME הוא שם הפונקציה ו-RUNTIME הוא זמן הריצה שבו אתם משתמשים.

מסוף Google Cloud

1. בדף סקירה כללית של פונקציות Cloud Run, בוחרים באפשרות יצירת פונקציה.

2. בקטע Runtime, build... (זמן ריצה, בנייה...), לוחצים על הכרטיסייה Build (בנייה) ומזינים את שם המשאב המלא של המאגר הפרטי בתיבת הטקסט Build worker pools (בניית מאגרי עובדים).

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

אבטחת ה-build באמצעות חשבון שירות בהתאמה אישית

פונקציות Cloud Run לוקחות את קוד המקור ושולחות אותו ל-Cloud Build כדי ליצור קונטיינר. הפונקציה שמוכלת בקונטיינר מאוחסנת ב-Artifact Registry ונפרסת ב-Cloud Run כשירות. כברירת מחדל, Cloud Build מקצה חשבון שירות שיפעל כחשבון הראשי כשמבצעים את ה-build. החל מיולי 2024, בפרויקטים חדשים בארגון נעשה שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לפעול כחשבון הראשי שמריץ את ה-build. לפרטים, ראו שינוי בחשבון השירות שמשמש כברירת מחדל ב-Cloud Build. מטעמי אבטחה, לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine אין הרשאות מספיקות לביצוע ה-build.

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

1. מונעים את השימוש בחשבון השירות מדור קודם של Cloud Build לצורך הבנייה.
2. מונעים את השימוש בחשבון השירות שמוגדר כברירת מחדל בשירות Compute לצורך הבנייה.
3. מגדירים חשבון שירות חדש עם הרשאות בהיקף מתאים לשימוש ב-build.
4. שימוש בחשבון השירות שהוגדר עבור ה-build.

מניעת השימוש בחשבון השירות מדור קודם של Cloud Build לבנייה

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

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

[e-mail].

אתם יכולים להשבית בכוח את השימוש בחשבון השירות הזה על ידי הגדרת האילוץ cloudbuild.useBuildServiceAccount במדיניות הארגון לערך Not Enforced. אפשרות אחרת היא להסיר את כל ההרשאות של התפקיד, וכך להגביל את היכולת שלו לגשת למשאבים של Google Cloud.

מניעת השימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute לצורך בנייה

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

חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine הוא בפורמט [e-mail]. כדי להשבית את השימוש בו כברירת מחדל לבנייה, צריך להגדיר את המדיניות הארגונית cloudbuild.useComputeServiceAccount לערך Not Enforced. לחלופין, השבתה של חשבון השירות הזה תמנע את השימוש בו כדי לגשת למשאבים Google Cloud .

הגדרת חשבון שירות ליצירת פונקציות

כחלק מההגדרה של פונקציה, אפשר לציין חשבון שירות של build כשפורסים את הפונקציה. אם השימוש בחשבון השירות מדור קודם של Cloud Build ובחשבון השירות שמשמש כברירת מחדל ב-Compute Engine נחסם, צריך לציין חשבון שירות של Build כדי לפרוס פונקציה.

במאמר חשבון שירות בהתאמה אישית ל-Cloud Build מוסבר איך להגדיר חשבון שירות של build לשימוש בפונקציה.