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

במדריך הזה מוצגת סקירה כללית של תהליך build של פונקציות שנפרסו באמצעות הפקודה gcloud functions. כדי לקרוא על תהליך build של פונקציות שנפרסו באמצעות הפקודה gcloud run, אפשר לעיין במאמרים הבאים:

• יצירת קונטיינרים ב-Cloud Run
• הגדרת חשבון שירות לבנייה
• הגדרת מאגרי עובדים לבנייה

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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

יתרון מרכזי של תהליך בניית קובץ האימג' בפרויקט המשתמש הוא הגישה ליומני ה-build. אפשר להשתמש ב-gcloud CLI או במסוף 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

כדי לראות את היומנים של הפונקציה בדף Cloud Run:

1. כניסה ל-Cloud Run

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

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

מאגר תמונות

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

כדי לציין מאגר Artifact Registry בניהול עצמי, מריצים את הפקודה הבאה:

gcloud functions deploy FUNCTION_NAME \
   --docker-repository=REPOSITORY \
   [FLAGS...]

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

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

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

הגדרות של ניהול הזהויות והרשאות הגישה:

• הגדרות IAM: מוודאים שלחשבון השירות של ה-Build יש גישה מורשית לקריאה וכתיבה אל REPOSITORY.
• הגדרות רשת: מוודאים שאפשר להגיע אל יעד REPOSITORY מההגדרה הנוכחית של הפרויקט.
• הגדרות של VPC Service Controls: מוודאים שחשבון השירות של ה-build יכול להגיע אל יעד REPOSITORY בתוך גבול הגזרה של VPC-SC.
• מגבלות על מיקום הנתונים: אם מציינים REPOSITORY באזור אחר מזה שבו הפונקציה ממוקמת, הנתונים יועברו בין אזורים.

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

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

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

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

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

3. אם מאגר העובדים הפרטי נמצא בפרויקט אחר מהפונקציה, צריך להעניק לחשבון השירות של סוכן השירות של Cloud Functions‏ ([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 functions deploy FUNCTION_NAME \
      --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 \
   --runtime RUNTIME \
   --clear-build-worker-pool
   [FLAGS...]

מחליפים את FUNCTION_NAME בשם הפונקציה ואת RUNTIME בסביבת זמן הריצה שבה אתם משתמשים.

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

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

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

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

אם השינויים שמתוארים במאמר שינוי בחשבון השירות של Cloud Build משפיעים עליכם, אתם יכולים לבצע אחת מהפעולות הבאות:

• כדאי לעיין בהנחיות של Cloud Build בנושא שינויים בחשבון השירות שמוגדר כברירת מחדל ולהשבית את השינויים האלה.

• מוסיפים את התפקיד 'חשבון Cloud Build' (roles/cloudbuild.builds.builder) לחשבון השירות של Compute Engine שמוגדר כברירת מחדל.

• יוצרים חשבון שירות מותאם אישית של Cloud Build לפריסות של פונקציות.

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

• אתם רוצים יותר שליטה על חשבונות השירות שאתם מוסיפים להיקף של VPC-SC.

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

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

• הארגון שלכם השבית את השימוש בחשבון השירות שמוגדר כברירת מחדל.

בקטעים הבאים מוסבר איך ליצור חשבון שירות מותאם אישית של Cloud Build לפריסת פונקציות.

יצירה של חשבון שירות

יוצרים חשבון שירות חדש כמו שמתואר במאמר יצירת חשבון שירות.

מתן הרשאות

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

• ‫roles/logging.logWriter – נדרש לאחסון יומני בנייה ב-Cloud Logging.
• ‫roles/artifactregistry.writer – חובה לאחסון תמונות של גרסאות build ב-Artifact Registry. כדי להשתמש בהתנהגות שמוגדרת כברירת מחדל, לחשבון השירות צריכה להיות גישה למאגרים בשמות gcf-artifacts ו-cloud-run-source-deploy. אפשר להגדיר את הגישה למאגרים במדיניות IAM של המאגר. אפשר גם לספק מאגר ארטיפקטים משלכם דרך השדה dockerRepository.
• ‫roles/storage.objectViewer – נדרש כדי לאחזר את מקור הפונקציה מקטגוריה של Cloud Storage, וכדי לאחסן תמונות build ב-Container Registry. כדי להשתמש בהתנהגות שמוגדרת כברירת מחדל, לחשבון השירות צריכה להיות גישה למאגרי מידע בשמות run-sources-*, gcf-v2-sources-* ו-gcf-v2-uploads-*. כדי לעשות זאת, אפשר להוסיף תנאי IAM להקצאת התפקיד, כמו (resource.type == "storage.googleapis.com/Object" && (resource.name.startsWith("projects/_/buckets/gcf-v2-sources-") || resource.name.startsWith("projects/_/buckets/gcf-v2-uploads-") || resource.name.startsWith("projects/_/buckets/run-sources-")))

מקצים את התפקידים הבאים באמצעות Google Cloud CLI או מסוףGoogle Cloud .

gcloud projects add-iam-policy-binding PROJECT_ID \
--member=serviceAccount:SA_EMAIL \
    --role=roles/logging.logWriter

gcloud projects add-iam-policy-binding PROJECT_ID \
--member=serviceAccount:SA_EMAIL \
--role=roles/artifactregistry.writer

gcloud projects add-iam-policy-binding PROJECT_ID \
--member=serviceAccount:SA_EMAIL \
--role=roles/storage.objectViewer

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

• ‫PROJECT_ID: מזהה הפרויקטGoogle Cloud .
• SA_EMAIL: כתובת האימייל של חשבון השירות.

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

שיקולים לגבי VPC Service Controls

אם יש לכם גבול גזרה של VPC Service Controls שמגן על הפרויקט ועל Cloud Run Functions API, ואם אתם משתמשים בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine בתור תפקיד Cloud Build Service Account עבור פונקציות Cloud Run, אתם צריכים ליצור את כללי הכניסה הבאים:

• מתן אפשרות לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לגשת לכל השיטות ב-Cloud Storage וב-Cloud Logging APIs.
• מתן אפשרות לחשבון השירות service-[PROJECT_NUMBER]@gcf-admin-robot.iam.gserviceaccount.com לגשת לכל השיטות ב-Cloud Storage וב-Cloud Logging APIs.

פריסת פונקציה עם חשבון שירות בהתאמה אישית

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

• הדגל --build-service-account מציין חשבון שירות ב-IAM שפרטי הכניסה שלו ישמשו לשלב הבנייה. אם לא מספקים חשבון שירות מותאם אישית, הפונקציה משתמשת בחשבון השירות שמוגדר כברירת מחדל בפרויקט עבור Cloud Build.
• אפשר גם להשתמש במאגר פרטי, שאותו מציינים באמצעות הדגל --build-worker-pool.

gcloud functions deploy FUNCTION_NAME \
   --gen2 \
   --region=REGION \
   --project=PROJECT_ID \
   --runtime=RUNTIME \
   --entry-point=CODE_ENTRYPOINT \
   --build-service-account=projects/PROJECT_ID/serviceAccounts/SA_EMAIL \
   --memory=256Mi \
   --trigger-http \
   --source=.

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

• ‫FUNCTION_NAME: השם שנתתם לפונקציה כשפרסתם אותה.
• ‫REGION: השם של Google Cloud האזור שבו רוצים לפרוס את הפונקציה (לדוגמה, us-west1).
• ‫PROJECT_ID: מזהה הפרויקטGoogle Cloud .
• ‫RUNTIME: מזהה זמן הריצה של גרסת זמן ריצה נתמכת להפעלת הפונקציה, לדוגמה, nodejs18.
• ‫CODE_ENTRYPOINT: נקודת הכניסה לפונקציה בקוד המקור. זה הקוד שיופעל כשהפונקציה תרוץ.
• SA_EMAIL: כתובת האימייל של חשבון השירות.

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

נותנים לחשבון השירות ב-Cloud Build גישה למערך של VPC Service Controls

פונקציות Cloud Run משתמשות ב-Cloud Build כדי ליצור קוד מקור בקונטיינר שניתן להפעלה. כדי להשתמש בפונקציות Cloud Run עם VPC Service Controls, צריך להגדיר את חשבון השירות של Cloud Build (בין אם הוא מוגדר כברירת מחדל או בהתאמה אישית) כך שתהיה לו גישה לגבולות גזרה לשירות.

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

חיפוש השם של חשבון השירות

אם אתם משתמשים בחשבון השירות שמוגדר כברירת מחדל ב-Cloud Build, תוכלו למצוא את השם שלו כך:

1. משתמשים בדף IAM במסוף Google Cloud כדי למצוא את חשבון השירות של Cloud Build.

   פתיחת IAM

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

3. חיפוש של cloudbuild.gserviceaccount.com. כתובת האימייל בפורמט [e-mail] היא השם של חשבון השירות.

אם יש לכם חשבון שירות מותאם אישית של Cloud Build, השתמשו בשם הזה במקום.

מעניקים לחשבון השירות גישה לגבולות גזרה לשירות

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