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

כשפורסים את קוד המקור של הפונקציה ב-Cloud Run Functions, קוד המקור מאוחסן בקטגוריה של 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 functions במסוף Google Cloud :
   כניסה לדף Cloud Run functions

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) ואתם רוצים להגביל את הגישה של ה-build רק לתלות שמאוחסנת בתוך גבולות הגזרה, אתם יכולים להשתמש בתכונה Cloud Build private worker pools.

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

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

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

3. אם מאגר העובדים הפרטי נמצא בפרויקט אחר מהפונקציה, צריך להעניק לחשבון השירות של סוכן השירות ([e-mail]) של פונקציות Cloud Run את התפקיד 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 functions overview, בוחרים באפשרות Create function.

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.

ב Google Cloud פרויקטים שנוצרו לפני יולי 2024, ‏ Cloud Build משתמש בחשבון השירות מדור קודם של Cloud Build. חשבון השירות הזה נועד לעזור למשתמשים להפעיל מגוון רחב של תרחישי שימוש, שיכול להיות שהם רחבים מדי לצרכים של הפרויקט שלכם. אם רוצים להעביר את הפרויקטים הקיימים מחשבון השירות הזה, אפשר לבצע את הפעולות הבאות כדי לאבטח עוד יותר את סביבת ה-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 .

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

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

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