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

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

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

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 עם הרשאות לא מספיקות לבניית פונקציה.

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

אם השינויים שמתוארים במאמר שינוי בחשבון השירות של 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 API.
• מתן אפשרות לחשבון השירות 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: מזהה זמן הריצה של גרסת זמן ריצה נתמכת להרצת הפונקציה.
• ‫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, השתמשו בשם הזה במקום.

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

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