פריסת פונקציית Cloud Run

בדף הזה מוסבר איך לפרוס ולשנות פונקציית Cloud Run. במאמר פריסת פונקציה לדוגמה מוסבר איך לפרוס פונקציית Hello World.

בפריסות של פונקציות Cloud Run נעשה שימוש אוטומטי ב-buildpacks של Google Cloud וב-Cloud Build כדי ליצור קובצי אימג' של קונטיינרים מקוד המקור של הפונקציה. אתם לא צריכים להתקין את Docker במכונה או להגדיר חבילות build או Cloud Build.

גם בפריסות של פונקציות Cloud Run משתמשים ב-Artifact Registry כדי לאחסן פריטי מידע שנוצר ולנהל קובצי אימג' של קונטיינרים. ‫Artifact Registry יוצר באופן אוטומטי את מאגר Artifact Registry שנקרא cloud-run-source-deploy, אם עדיין לא נוצר בפרויקט מאגר בשם הזה.

אם יש לכם פונקציות קיימות ואתם צריכים להשתמש בפקודה gcloud functions deploy, ב-Cloud Functions v2 API או בהגדרת google_cloudfunctions2_function Terraform לצורך תאימות לאחור, תוכלו לעיין במאמר פריסת פונקציות באמצעות הפקודה gcloud functions deploy.

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

  1. חשוב לוודא שהגדרתם פרויקט חדש ל-Cloud Run, כמו שמתואר בדף ההגדרה.

  2. מפעילים את Artifact Registry,‏ Cloud Build,‏ Cloud Run Admin API ו-Cloud Logging API:

      gcloud services enable artifactregistry.googleapis.com \
      cloudbuild.googleapis.com \
      run.googleapis.com \
      logging.googleapis.com

    אפשר גם להפעיל את Eventarc API כדי להשתמש בטריגרים של אירועים:

      gcloud services enable eventarc.googleapis.com

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

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

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

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

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

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

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

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@ \
      --role=roles/run.builder

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

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

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

אופציונלי: אם משתמשים ב-Eventarc, מקצים לחשבון השירות את התפקידים הבאים:

מידע נוסף על מתן תפקידים ספציפיים לטריגרים של Eventarc זמין במאמר תפקידים והרשאות ליעדים של Cloud Run.

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

יצירה ופריסה של פונקציה

אפשר לפרוס פונקציית Cloud Run באמצעות מסוף Google Cloud או ה-CLI של gcloud. לוחצים על הכרטיסייה עם ההוראות לשימוש בכלי הרצוי.

המסוף

  1. נכנסים לדף Services של Cloud Run במסוף Google Cloud :

    כניסה ל-Cloud Run

  2. לוחצים על כתיבת פונקציה.

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

  4. ברשימה Region, משתמשים בערך ברירת המחדל או בוחרים את האזור שבו רוצים לפרוס את הפונקציה.

  5. ברשימה Runtime, משתמשים בערך ברירת המחדל או בוחרים גרסת זמן ריצה.

  6. אופציונלי: בקטע Trigger, לוחצים על Add trigger ובוחרים אפשרות. נפתחת החלונית Eventarc trigger, שבה אפשר לשנות את הפרטים הבאים של הטריגר:

    1. בשדה Trigger name, מזינים שם לטריגר או משתמשים בשם ברירת המחדל.

    2. בוחרים סוג טריגר מהרשימה כדי לציין אחד מסוגי הטריגרים הבאים:

      • מקורות Google כדי לציין טריגרים ל-Pub/Sub, ל-Cloud Storage, ל-Firestore ולספקי אירועים אחרים של Google.

      • Custom כדי ליצור אירועים ולהשתמש בהם מקוד האפליקציה. פועלים לפי ההנחיות בחלונית Eventarc trigger כדי ליצור ערוץ. ערוץ הוא משאב שמשמש כצינור להעברת אירועים מותאמים אישית ממפיקים לצרכנים. אירועים בהתאמה אישית מתפרסמים בערוץ, וטריגר של Eventarc נרשם לאירועים האלה.

      • צד שלישי לשילוב עם ספקים שאינם של Google שמציעים מקור Eventarc. מידע נוסף זמין במאמר אירועים של צד שלישי ב-Eventarc.

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

    4. בוחרים סוג אירוע מהרשימה. הגדרת הטריגר משתנה בהתאם לסוג האירוע הנתמך. מידע נוסף זמין במאמר בנושא סוגי אירועים.

    5. בשדה Region, בוחרים מיקום לטריגר Eventarc. באופן כללי, המיקום של טריגר Eventarc צריך להתאים למיקום של המשאב ב- Google Cloud שאתם רוצים לעקוב אחרי האירועים שלו. ברוב התרחישים, כדאי גם לפרוס את הפונקציה באותו אזור. מידע נוסף על מיקומי טריגרים של Eventarc זמין במאמר הסבר על מיקומי Eventarc.

    6. בשדה Service account, בוחרים חשבון שירות. טריגרים של Eventarc מקושרים לחשבונות שירות כדי לשמש כזהות כשמפעילים את הפונקציה. לחשבון השירות של טריגר Eventarc צריכה להיות הרשאה להפעיל את הפונקציה. כברירת מחדל, Cloud Run משתמש בחשבון השירות של Compute Engine שמוגדר כברירת מחדל.

    7. אופציונלי: מציינים את נתיב כתובת ה-URL של השירות שאליו רוצים לשלוח את הבקשה הנכנסת. זהו הנתיב היחסי בשירות היעד שאליו יישלחו האירועים של הטריגר. לדוגמה: /,‏ /route,‏ route ו-route/subroute.

    8. אחרי שממלאים את שדות החובה, לוחצים על שמירת הטריגר.

  7. בקטע אימות, מגדירים את האפשרויות הבאות:

    • אם יוצרים פונקציית HTTP ציבורית, למשל webhook, בוחרים באפשרות Allow public access (מתן גישה ציבורית). כשבוחרים באפשרות הזו, התפקיד "מפעיל IAM" מוקצה למזהה המיוחד allUser. אפשר להשתמש ב-IAM כדי לערוך את ההגדרה הזו בהמשך, אחרי שיוצרים את השירות. אם אין לכם הרשאות (תפקיד אדמין ב-Cloud Run) לבחור באפשרות הזו, השירות יפרוס וידרוש אימות.

    • אם אתם יוצרים פונקציה שמופעלת על ידי אירוע, בחרו באפשרות Require authentication.

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

    1. מגדירים את החיוב לפי הצורך.

    2. בקטע Service scaling (שינוי גודל השירות), אם משתמשים בהתאמה אוטומטית לעומס של Cloud Run שמוגדרת כברירת מחדל, אפשר לציין את מספר המכונות המינימלי. אם משתמשים בהתאמה ידנית של קנה המידה, צריך לציין את מספר המופעים של השירות.

    3. מגדירים את ההגדרות של Ingress control לפי הצורך.

    4. מרחיבים את הקטע Container(s), Volumes, Networking, Security כדי להגדיר הגדרות אופציונליות אחרות בכרטיסיות המתאימות:

  9. לוחצים על Create ומחכים ש-Cloud Run ייצור את השירות באמצעות עדכון placeholder.

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

  11. בכרטיסייה Source, אפשר ללחוץ על Show Payload כדי לראות דוגמה למטען ייעודי (payload) של אירועים נכנסים.

  12. אחרי הפריסה, לוחצים על הלחצן Test (בדיקה) כדי לבדוק את הפונקציה שנוצרה.

gcloud

  1. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. מעדכנים את הרכיבים של gcloud לגרסה העדכנית:

    gcloud components update

  3. מריצים את הפקודה הבאה בספרייה שמכילה את הקוד לדוגמה:

    gcloud run deploy FUNCTION \
       --source . \
       --function FUNCTION_ENTRYPOINT \
       --base-image BASE_IMAGE \
       --region REGION

    מחליפים את:

    • ‫FUNCTION בשם הפונקציה שאתם פורסים. אפשר להשמיט את הפרמטר הזה לגמרי, אבל אם תשמיטו אותו תתבקשו להזין את השם.

    • ‫FUNCTION_ENTRYPOINT עם נקודת הכניסה לפונקציה בקוד המקור. זה הקוד ש-Cloud Run מריץ כשהפונקציה פועלת. הערך של הדגל הזה צריך להיות שם של פונקציה או שם מלא של מחלקה שקיימים בקוד המקור.

    • ‫BASE_IMAGE עם סביבת קובץ האימג' הבסיסי של הפונקציה, כמו nodejs24,‏ python314,‏ go127,‏ java25,‏ dotnet10,‏ ruby40 או php85. פרטים נוספים על תמונות בסיס ועל החבילות שכלולות בכל תמונה זמינים במאמר תמונות בסיס של סביבות זמן ריצה.

    • ‫REGION עם Google Cloud האזור שבו רוצים לפרוס את הפונקציה. לדוגמה, europe-west1.

    אופציונלי:

    • אם יוצרים פונקציית HTTP ציבורית, למשל webhook, צריך לציין את הדגל --allow-unauthenticated. הדגל הזה מקצה את תפקיד ההפעלה של IAM ב-Cloud Run למזהה המיוחד allUser. אפשר להשתמש ב-IAM כדי לערוך את ההגדרה הזו בהמשך, אחרי שיוצרים את השירות. אם אתם יוצרים פונקציה שמופעלת על ידי אירוע או שירות מאומת, אתם יכולים להשמיט את הדגל הזה.

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

  gcloud eventarc triggers create EVENTARC_TRIGGER_NAME \
      --location=EVENTARC_TRIGGER_LOCATION \
      --destination-run-service=FUNCTION \
      --destination-run-region=REGION \
      --event-filters="type=EVENTARC_FILTER_TYPE" \
      --event-filters="EVENTARC_EVENT_FILTER" \
      --service-account=EVENTARC_TRIGGER_SERVICE_ACCOUNT

מחליפים את:

  • ‫EVENTARC_TRIGGER_NAME בשם של טריגר Eventarc.

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

  • FUNCTION בשם של הפונקציה שפרסתם.

  • ‫REGION עם האזור של פונקציית Cloud Run.

  • ‫EVENTARC_FILTER_TYPE עם מסנני האירועים שהטריגר עוקב אחריהם. אירוע שתואם לכל המסננים --event-filtersמפעיל קריאות לפונקציה. לכל טריגר צריך להיות סוג אירוע נתמך בתבנית --event-filters="type=EVENTARC_FILTER_TYPE". אי אפשר לשנות את סוג האירוע הזה אחרי שיוצרים אותו. כדי לשנות את EVENT_FILTER_TYPE, יוצרים טריגר חדש ומוחקים את הטריגר הישן. אפשר גם לחזור על הדגל --event-filters עם מסנן נתמך בפורמט ATTRIBUTE=VALUE כדי להוסיף עוד מסננים.

  • EVENTARC_TRIGGER_SERVICE_ACCOUNT עם חשבון שירות. טריגרים של Eventarc מקושרים לחשבונות שירות כדי לשמש כזהות כשמפעילים את הפונקציה. לחשבון השירות של הטריגר ב-Eventarc צריכה להיות הרשאה להפעיל את הפונקציה. כברירת מחדל, Cloud Run משתמש בחשבון השירות שמוגדר כברירת מחדל של Compute.

Terraform

כדי לנהל פונקציות באמצעות Terraform, צריך ליצור קוד פונקציה בקובץ אימג' של קונטיינר, ואז להגדיר את שירות Cloud Run בהגדרות של Terraform באמצעות המשאב google_cloud_run_v2_service מתוך Google Cloud Platform Provider.

  1. פועלים לפי ההוראות ליצירת פונקציה מאפס כדי ליצור קובץ אימג' של קונטיינר שתואם לעדכוני אבטחה אוטומטיים. מעתיקים את הנתיב המלא של קובץ אימג' של קונטיינר למשתנה IMAGE_URL שבו משתמשים בשלב הבא.

  2. יוצרים קובץ main.tf חדש עם התוכן הזה:

    provider "google" {
  project = "PROJECT-ID"
}

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  client   = "terraform"
  template {
    containers {
      name = "SERVICE"
      image = "IMAGE_URL" # Container image built from your function in the previous step.
      base_image_uri = "BASE_IMAGE"
    }
  }
  build_config{
    function_target = "FUNCTION_TARGET"
    image_uri = "IMAGE_URL"
    base_image = "BASE_IMAGE"
    enable_automatic_updates = true
  }
}
resource "google_cloud_run_v2_service_iam_member" "noauth" {
  location = google_cloud_run_v2_service.default.location
  name     = google_cloud_run_v2_service.default.name
  role     = "roles/run.invoker"
  member   = "allUsers"
}

    מחליפים את:

    • ‫PROJECT-ID במזהה הפרויקט ב- Google Cloud .
    • ‫REGION עם האזור Google Cloud . לדוגמה: europe-west1.
    • ‫SERVICE בשם של שירות Cloud Run. שמות השירותים צריכים להיות באורך של עד 49 תווים, והם צריכים להיות ייחודיים לכל אזור ופרויקט.
    • ‫IMAGE_URL עם הפניה אל קובץ האימג' בקונטיינר שמכיל רק את הפונקציה שבניתם
    • ‫BASE_IMAGE עם סביבת תמונת הבסיס של הפונקציה, כמו nodejs24,‏ python314,‏ go127,‏ java25,‏ dotnet10,‏ ruby40 או php85. למידע נוסף על קובצי אימג' בסיסיים ועל החבילות שכלולות בכל קובץ אימג', קראו את המאמר קובצי אימג' בסיסיים של סביבות זמן ריצה.
    • ‫FUNCTION_TARGET בשם הפונקציה שרוצים להשתמש בה כנקודת הכניסה.

    ההגדרה הזו מאפשרת גישה ציבורית (שווה ערך ל---allow-unauthenticated). כדי להפוך את השירות לפרטי, צריך להסיר את קטע google_cloud_run_v2_service_iam_member.

  3. מאתחלים את Terraform:

    terraform init

  4. מחילים את ההגדרות של Terraform:

    terraform apply

    כדי לאשר את הפעולות שמתוארות, צריך להזין yes.

מיקומים של Cloud Run

‫Cloud Run הוא שירות אזורי, כלומר התשתית שמפעילה את שירותי Cloud Run נמצאת באזור ספציפי ומנוהלת על ידי Google, כך שהיא זמינה באופן יתיר בכל האזורים באותו אזור.

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

‫Cloud Run זמין באזורים הבאים:

בכפוף לתמחור ברמה 1

בכפוף לתמחור ברמה 2

  • africa-south1 (יוהנסבורג)
  • asia-east2 (הונג קונג)
  • asia-northeast3 (סיאול, קוריאה הדרומית)
  • asia-southeast1 (סינגפור)
  • asia-southeast2 (ג'קרטה)
  • ‫asia-south2 (דלהי, הודו)
  • ‫australia-southeast1 (סידני)
  • ‫australia-southeast2 (מלבורן)
  • europe-central2 (ורשה, פולין) סמל של עלה רמה נמוכה של CO2
  • ‫europe-west10 (ברלין)
  • europe-west12 (טורינו) סמל של עלה רמה נמוכה של CO2
  • europe-west2 (לונדון, בריטניה) סמל של עלה רמה נמוכה של CO2
  • ‫europe-west3 (פרנקפורט, גרמניה)
  • europe-west6 (ציריך, שווייץ) סמל של עלה רמה נמוכה של CO2
  • ‫me-central1 (דוחה)
  • me-central2 (דמאם)
  • ‫northamerica-northeast1 (מונטריאול) סמל של עלה רמה נמוכה של CO2
  • northamerica-northeast2 (טורונטו) סמל של עלה רמה נמוכה של CO2
  • ‫southamerica-east1 (סאו פאולו, ברזיל) סמל של עלה רמה נמוכה של CO2
  • southamerica-west1 (סנטיאגו, צ'ילה) סמל של עלה רמה נמוכה של CO2
  • ‫us-west2 (לוס אנג'לס)
  • ‫us-west3 (סולט לייק סיטי)
  • ‫us-west4 (לאס וגאס)

אם כבר יצרתם שירות Cloud Run, אתם יכולים לראות את האזור במרכז הבקרה של Cloud Run במסוףGoogle Cloud .

הפעלת ניסיונות חוזרים של אירועים

‫Eventarc משתמש ב-Pub/Sub כשכבת התעבורה שלו, ויש לו מדיניות ברירת מחדל לניסיונות חוזרים שאולי לא תתאים לפונקציה שלכם.

אחרי שיוצרים טריגר Eventarc, מומלץ מאוד לעדכן את מדיניות הניסיון החוזר ב-Eventarc ולהגדיר נושא להודעות ללא מוצא ב-Pub/Sub.

ציון מאגר תמונות

פריסות של פונקציות Cloud Run משתמשות ב-Artifact Registry כדי לאחסן ארטיפקטים ולנהל קובצי אימג' של קונטיינרים. ‫Artifact Registry יוצר באופן אוטומטי את מאגר Artifact Registry‏ REGION-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy אם בפרויקט שלכם עדיין לא נוצר מאגר בשם הזה.

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

gcloud 

gcloud run deploy FUNCTION \
  --source . \
  --function FUNCTION_ENTRYPOINT \
  --base-image BASE_IMAGE \
  --region REGION \
  --image IMAGE_URL

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

  • ‫FUNCTION בשם הפונקציה שאתם פורסים. אפשר להשמיט את הפרמטר הזה לגמרי, אבל אם תשמיטו אותו, תתבקשו לציין את השם.

  • ‫FUNCTION_ENTRYPOINT עם נקודת הכניסה לפונקציה בקוד המקור. זה הקוד ש-Cloud Run מריץ כשהפונקציה פועלת. הערך של הדגל הזה צריך להיות שם של פונקציה או שם מלא של מחלקה שקיימים בקוד המקור.

  • ‫BASE_IMAGE עם סביבת תמונת הבסיס של הפונקציה, כמו nodejs24,‏ python314,‏ go127,‏ java25,‏ dotnet10,‏ ruby40 או php85. למידע נוסף על קובצי אימג' בסיסיים ועל החבילות שכלולות בכל קובץ אימג', קראו את המאמר קובצי אימג' בסיסיים של סביבות זמן ריצה.

  • REGION באזור שבו רוצים לפרוס את הפונקציה, במקום Google Cloud. לדוגמה, europe-west1.

  • IMAGE_URL בהפניה לנתיב של קובץ האימג' באמצעות מאגר קובצי האימג' של Artifact Registry לבחירתכם, לדוגמה projects/PROJECT_NAME/locations/LOCATION/repositories/REPOSITORY_NAME/FUNCTION. שם התמונה חייב להיות זהה לשם הפונקציה שאתם יוצרים. אם מספקים רק את הנתיב למאגר, התמונה תיצור באמצעות שם הפונקציה FUNCTION.

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

הגדרות IAM בפרויקט Artifact Registry:

  • מוודאים שהגדרתם הרשאות IAM לפריסת תמונות מפרויקטים Google Cloud אחרים:
    • מקצים את התפקיד Artifact Registry Reader‏ (roles/artifactregistry.reader) לסוכן שירות Cloud Run‏ (service-FUNCTION_PROJECT_NUMBER@serverless-robot-prod.) מפרויקט הפונקציה.
    • מקצים את התפקיד Artifact Registry Reader ‏(roles/artifactregistry.reader) לזהות הפריסה:
    • בפריסות שנעשה בהן שימוש ב-Cloud Run API (לדוגמה, gcloud run deploy), צריך להקצות למשתמש או לחשבון השירות שמבצעים את הפריסה את התפקיד Artifact Registry Reader ‏(roles/artifactregistry.reader).
    • לפריסות באמצעות Cloud Functions API (לדוגמה, gcloud functions deploy), מקצים את התפקיד Artifact Registry Reader‏ (roles/artifactregistry.reader) לסוכן השירות של Cloud Functions‏ (service-FUNCTION_PROJECT_NUMBER@gcf-admin-robot.) מפרויקט הפונקציה.
  • מקצים את התפקידים 'קורא Artifact Registry' (roles/artifactregistry.reader) ו'כותב Artifact Registry' (roles/artifactregistry.writer) לחשבון השירות של ה-build (--build-service-account) מפרויקט הפונקציה.

הגדרות רשת:

  • מוודאים שאפשר להגיע לREPOSITORY היעד מהגדרת הפרויקט הנוכחית.

הגדרות של VPC Service Controls:

  • מוודאים שחשבון השירות של ה-build יכול להגיע אל REPOSITORY שבתוך היקף ה-VPC-SC.

מגבלות על מיקום אחסון הנתונים:

  • שימו לב שאם תציינו REPOSITORY באזור שונה מהאזור שבו נמצאת הפונקציה, הנתונים יועברו בין אזורים.

שינוי פונקציה קיימת

אתם יכולים לשנות את ההגדרות או את הקוד של הפונקציה:

שינוי ההגדרות האישיות

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

המסוף

  1. נכנסים לדף Services של Cloud Run במסוף Google Cloud :

    כניסה ל-Cloud Run

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

  3. משנים את הגדרות התצורה בכרטיסיות המתאימות.

  4. לוחצים על View diff & redeploy ואז על Deploy changes כדי לפרוס את השינויים.

gcloud

  1. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

    בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. כדי לעדכן הגדרה אחת או יותר של הגדרת שירות, משתמשים בפקודה gcloud run services update SERVICE עם הגדרות flag בשורת הפקודה של ההגדרה שרוצים לעדכן. מחליפים את SERVICE בשם השירות.

פריסה מחדש של קוד מקור חדש

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

לוחצים על הכרטיסייה עם ההוראות לשימוש בכלי הרצוי.

המסוף

  1. נכנסים לדף Services של Cloud Run במסוף Google Cloud :

    כניסה ל-Cloud Run

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

  3. עוברים לכרטיסייה מקור ולוחצים על עריכת המקור.

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

  5. משנים את Function entry point לפי הצורך.

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

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

  8. לוחצים על שמירה ופריסה מחדש ומחכים עד שהפריסה תסתיים.

gcloud

  1. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

    בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. מריצים את הפקודה הבאה בספרייה שמכילה את קוד המקור של הפונקציה:

    gcloud run deploy FUNCTION \
       --source . \
       --function FUNCTION_ENTRYPOINT \
       --base-image BASE_IMAGE \
       --region REGION

    מחליפים את:

    • ‫FUNCTION בשם הפונקציה שרוצים לשנות.

    • ‫FUNCTION_ENTRYPOINT עם נקודת הכניסה לפונקציה בקוד המקור.

    • ‫BASE_IMAGE עם סביבת תמונת הבסיס של הפונקציה, כמו nodejs24,‏ python314,‏ go127,‏ java25,‏ dotnet10,‏ ruby40 או php85.

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

      • הנתיב המלא של תמונת הבסיס, לדוגמה us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/nodejs24. האפשרות הזו מאפשרת לציין את קובץ האימג' הבסיסי, חבילת מערכת ספציפית במקבץ ואת האזור שממנו קובץ האימג' הבסיסי יורד.
      • הכינוי של הנתיב המלא של קובץ האימג' הבסיסי, למשל google-24/nodejs24 או google-24-full/nodejs24. האפשרות הזו מאפשרת לציין את קובץ האימג' הבסיסי וחבילת מערכת ספציפית במערך.

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

    • ‫REGION עם Google Cloud האזור שבו רוצים לפרוס את הפונקציה. לדוגמה, europe-west1.

    דגלים אופציונליים

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

השבתת בדיקת התקינות של הפריסה

כברירת מחדל, Cloud Run בודק שהפריסה תקינה על ידי הפעלת מכונה והמתנה עד שהבדיקה הראשונית תעבור. אם בדיקת התקינות תיכשל, הגרסה תסומן כלא תקינה והתנועה לא תנותב אליה.

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

gcloud

כדי להשבית את בדיקת התקינות של הפריסה, משתמשים בדגל --no-deploy-health-check:

gcloud run deploy --image IMAGE_URL --no-deploy-health-check

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

  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, צריך ליצור מראש את המאגר REPO_NAME. הפורמט של כתובת ה-URL הוא LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.

אם השבתתם בעבר את בדיקת התקינות של הפריסה, תוכלו להשתמש בפקודה --deploy-health-check כדי להפעיל אותה מחדש.

YAML

כדי להשבית את בדיקת תקינות הפריסה, מוסיפים את ההערה run.googleapis.com/health-check-disabled עם הערך 'true' אל spec.template.metadata.annotations.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/health-check-disabled: 'true'

Terraform

כדי להשבית את בדיקת התקינות של הפריסה, מגדירים את הארגומנט health_check_disabled לערך true בבלוק template.

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  ...
  template {
    health_check_disabled = true
    ...
  }
}

קטגוריית מקור

תהליך הבנייה צריך להיות מסוגל לגשת לקוד המקור ולGoogle Cloud עורך קוד המקור של המסוף. כדי לעשות את זה, מעלים את קוד המקור לקטגוריה של Cloud Storage.

כשפורסים באמצעות ה-CLI של gcloud או מסוף Google Cloud , המערכת מקצה באופן אוטומטי קטגוריה של Cloud Storage ומעלה את קוד המקור. כברירת מחדל, הקוד מאוחסן בקטגוריה בשם run-sources-PROJECT_ID-REGION. הניהול של רשימות בקרת הגישה (ACL) והאובייקטים של המקור בקטגוריה הזו הוא באחריותכם.

אם אתם צריכים להשתמש בקטגוריה ספציפית, למשל כדי להשתמש במפתחות הצפנה בניהול הלקוח (CMEK), קודם אתם צריכים לארוז את קובצי המקור המקומיים בארכיון (כמו קובץ ZIP). לאחר מכן מעלים את הארכיון הזה לקטגוריה. כדי לבצע פריסה מהמיקום המותאם אישית הזה, משתמשים ב-CLI של gcloud עם הדגל --source=gs://BUCKET_NAME/OBJECT_PATH.

המאמרים הבאים

אחרי שפורסים פונקציית Cloud Run חדשה, אפשר: