סקירה כללית על פונקציות Cloud Run

כשפורסים פונקציית Cloud Run, המערכת מתאמת באופן אוטומטי את שירותי Google Cloud הבסיסיים, כולל Cloud Storage, ‏ Cloud Build ו-Artifact Registry, כדי לארוז ולהריץ את הקוד. הבנת האינטראקציות האלה בין השירותים עוזרת להגדיר את ההרשאות הנדרשות לניהול זהויות והרשאות גישה (IAM), לעקוב אחרי יחסי התלות בין המשאבים ולפתור בעיות בפריסה או ב-build.

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

כדאי להכיר את המושגים שקשורים לפונקציות Cloud Run ולפריסת קוד מקור, שמפורטים במדריך אפשרויות פריסה ומודל משאבים ב-Cloud Run.

סקירה כללית של הארכיטקטורה

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

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

שליחת קריאה ל-Cloud Run Admin API ממסוף Google Cloud .
תרשים 1. המשתמש מכין את קוד המקור של הפונקציות ופורס אותו ב-Cloud Run.

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

  • אם פרסתם את הפונקציה באמצעות Cloud Run Admin API, יקרו הדברים הבאים:

    1. קוד המקור שלכם מועלה לקטגוריה של Cloud Storage שאין לה תקופת שמירה.

      1. אם משתמשים בהצפנה שמוגדרת כברירת מחדל, שם הקטגוריה נוצר באופן אוטומטי ונקרא run-sources-PROJECT_ID-REGION.
      2. אם אתם מגינים על הנתונים באמצעות מפתחות הצפנה בניהול הלקוח (CMEK), שם הקטגוריה לא נוצר באופן אוטומטי ואתם צריכים לספק שם לקטגוריה.

    2. קוד המקור נשלח ל-Cloud Build, שבו חבילות ה-buildpack של Google Cloud ו-Functions Framework יוצרות קובץ אימג' של קונטיינר. חשוב לזכור שחשבון השירות של Cloud Build יוצר את קובץ האימג' של הקונטיינר. כברירת מחדל, ב-Cloud Run נעשה שימוש בסוג המכונה e2-standard-2 שסופק על ידי Cloud Build.

    3. קובץ האימג' של הקונטיינר מועלה ל-Artifact Registry דרך קטגוריה שנוצרת באופן אוטומטי בשם REGION-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy.

    4. האימג' נפרס ב-Cloud Run כשירות.

    5. אפשר להפעיל את הפונקציה באמצעות Eventarc,‏ Pub/Sub או טריגרים אחרים של HTTP.

  • אם פרסתם את הפונקציה באמצעות Cloud Functions API (v2), יקרו הדברים הבאים:

    1. קוד המקור שלכם מועלה לקטגוריה של Cloud Storage שאין לה תקופת שמירה.

      שם הקטגוריה נוצר באופן אוטומטי, והוא מבוסס על הפורמט הבא:

      1. אם אתם משתמשים בהצפנה שמוגדרת כברירת מחדל, שם הקטגוריה הוא gcf-v2-sources-PROJECT_NUMBER-REGION.
      2. אם אתם מגינים על הנתונים באמצעות CMEK, הקטגוריה נקראת gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH.

    2. קוד המקור נשלח ל-Cloud Build, שבו חבילות ה-buildpack של Google Cloud ו-Functions Framework יוצרות קובץ אימג' של קונטיינר. חשוב לזכור שחשבון השירות של Cloud Build יוצר את קובץ האימג' של הקונטיינר. כברירת מחדל, ב-Cloud Run נעשה שימוש בסוג המכונה e2-standard-2 שסופק על ידי Cloud Build.

    3. קובץ האימג' של הקונטיינר מועלה ל-Artifact Registry דרך קטגוריה שנוצרת באופן אוטומטי בשם REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts.

    4. האימג' נפרס ב-Cloud Run כשירות.

    5. אפשר להפעיל את הפונקציה באמצעות Eventarc,‏ Pub/Sub או טריגרים אחרים של HTTP.

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