פריסת קובצי אימג' של קונטיינרים ב-Cloud Run

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

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

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

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

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

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

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

• ‫Cloud Run Developer (roles/run.developer) בשירות Cloud Run
• משתמש בחשבון שירות (roles/iam.serviceAccountUser) בזהות השירות
• קורא של Artifact Registry (roles/artifactregistry.reader) במאגר Artifact Registry של קובץ האימג' של הקונטיינר שנפרס
• אם משתמשים בחשבון שירות חוצה-פרויקטים כדי לפרוס שירות: יצירת אסימונים בחשבון שירות (roles/iam.serviceAccountTokenCreator) בזהות השירות

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

מאגרי תמונות וקובצי אימג' נתמכים של קונטיינרים

אתם יכולים להשתמש ישירות בקובצי אימג' של קונטיינרים שמאוחסנים ב-Artifact Registry או ב-Docker Hub. ‫Google ממליצה להשתמש ב-Artifact Registry. תמונות Docker Hub נשמרות במטמון למשך שעה אחת לכל היותר.

אפשר להשתמש בתמונות של מאגרי תגים ממאגרי תגים ציבוריים או פרטיים אחרים (כמו JFrog Artifactory,‏ Nexus או GitHub Container Registry) על ידי הגדרה של מאגר תגים מרוחק ב-Artifact Registry.

מומלץ להשתמש ב-Docker Hub רק לפריסת קובצי אימג' פופולריים של קונטיינרים, כמו קובצי אימג' רשמיים של Docker או קובצי אימג' של תוכנות קוד פתוח (OSS) שנתמכות על ידי Docker. כדי להגדיל את הזמינות, Google ממליצה לפרוס את התמונות האלה מ-Docker Hub באמצעות מאגר מרוחק של Artifact Registry.

ב-Cloud Run אין תמיכה בשכבות של קובצי אימג' של קונטיינרים בגודל של יותר מ-9.9GB כשמבצעים פריסה מ-Docker Hub או ממאגר מרוחק של Artifact Registry עם רישום חיצוני.

פריסת שירות חדש

אפשר לציין קובץ אימג' של קונטיינר עם תג (לדוגמה, us-docker.pkg.dev/my-project/container/my-image:latest) או עם תקציר מדויק (לדוגמה, us-docker.pkg.dev/my-project/container/my-image@sha256:41f34ab970ee...).

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

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

המסוף

כדי לפרוס קובץ אימג' של קונטיינר:

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

   כניסה ל-Cloud Run

2. לוחצים על Deploy container (פריסת מאגר) כדי להציג את הטופס Create service (יצירת שירות).

3. בטופס, בוחרים את אפשרות הפריסה.

   1. אם רוצים לפרוס קונטיינר באופן ידני, בוחרים באפשרות Deploy one revision from an existing container image ומציינים את קובץ האימג' של הקונטיינר.

   2. אם רוצים להגדיר אוטומציה לפריסה רציפה, בוחרים באפשרות Continuously deploy new revisions from a source repository (פריסה רציפה של עדכונים חדשים ממאגר מקור) ופועלים לפי ההוראות לפריסות רציפות.

4. מזינים את שם השירות. שמות השירותים צריכים להיות באורך של 49 תווים או פחות, והם צריכים להיות ייחודיים לכל אזור ופרויקט. אי אפשר לשנות את שם השירות אחר כך, והוא גלוי לכולם.

5. בשדה Region, בוחרים את האזור שבו רוצים שהשירות יהיה ממוקם.

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

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

   • אם אתם יוצרים API או אתר ציבורי, בוחרים באפשרות Allow public access (מתן גישה לכולם). כשבוחרים באפשרות הזו, תפקיד IAM Invoker מוקצה למזהה המיוחד allUser. אפשר להשתמש ב-IAM כדי לערוך את ההגדרה הזו בהמשך, אחרי שיוצרים את השירות.
   • אם רוצים שירות מאובטח שמוגן באמצעות אימות, בוחרים באפשרות דרישת אימות.

7. מגדירים חיוב לפי הצורך.

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

9. מגדירים את ההגדרות של Ingress בטופס לפי הצורך.

10. לוחצים על Containers, Networking, Security כדי להגדיר הגדרות אופציונליות אחרות בכרטיסיות המתאימות:

    • בו-זמניות
    • הגדרת מאגר תגים
    • מגבלות על יחידת עיבוד מרכזית (CPU)
    • מגבלות זיכרון
    • זמן קצוב לתפוגה של בקשה
    • Secrets
    • משתני סביבה
    • סביבת הפעלה
    • ‫HTTP/2
    • חשבונות שירות
    • חיבורים ל-Cloud SQL
    • חיבור VPC

11. כשמסיימים להגדיר את השירות, לוחצים על Create כדי לפרוס את האימג' ב-Cloud Run ומחכים שהפריסה תסתיים.

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

gcloud

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

   הפעלת Cloud Shell

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

2. כדי לפרוס קובץ אימג' של קונטיינר:

   1. מריצים את הפקודה הבאה:

      gcloud run deploy SERVICE --image IMAGE_URL

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

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

      אם אתם יוצרים API או אתר ציבורי, אתם צריכים לאפשר גישה ציבורית לשירות שלכם באמצעות הדגל --allow-unauthenticated. הפעולה הזו מקצה את תפקיד ה-IAM‏ Cloud Run Invoker ל-allUsers. אפשר גם לציין --no-allow-unauthenticated כדי למנוע גישה ציבורית. אם לא מציינים את אחד מהדגלים האלה, מוצגת בקשה לאישור כשמריצים את הפקודה deploy.

   2. ממתינים עד שהפריסה תסתיים. אחרי שתשלימו את התהליך בהצלחה, תוצג הודעת הצלחה וכתובת ה-URL של השירות שנפרס.

   שימו לב: כדי לפרוס למיקום אחר מהמיקום שהגדרתם באמצעות המאפיינים run/region gcloud, צריך להשתמש בפקודה הבאה:

   gcloud run deploy SERVICE --region REGION

YAML

אפשר לאחסן את מפרט השירות בקובץ YAML ואז לפרוס אותו באמצעות ה-CLI של gcloud.

1. יוצרים קובץ service.yaml חדש עם התוכן הבא:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: SERVICE
   spec:
     template:
       spec:
         containers:
         - image: IMAGE

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

   • ‫SERVICE: השם של שירות Cloud Run. שמות השירותים צריכים להיות באורך של 49 תווים או פחות, והם צריכים להיות ייחודיים לכל אזור ופרויקט.
   • ‫IMAGE: כתובת ה-URL של תמונת המאגר.

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

2. מפעילים את השירות החדש באמצעות הפקודה הבאה:

   gcloud run services replace service.yaml

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

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

מוסיפים את השורות הבאות למשאב google_cloud_run_v2_service בתצורת Terraform:

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

  resource "google_cloud_run_v2_service" "default" {
    name     = "SERVICE"
    location = "REGION"
    client   = "terraform"

    template {
      containers {
        image = "IMAGE_URL"
      }
    }
  }

  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 האזור
• ‫SERVICE: השם של שירות Cloud Run. שמות של שירותים צריכים להיות באורך של עד 49 תווים, והם צריכים להיות ייחודיים לכל אזור ולכל פרויקט.
• ‫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

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

פיתוח נייטיב

אפשר לאחסן את מפרט ה-Compose בקובץ YAML ואז לפרוס אותו כשירות Cloud Run באמצעות פקודת gcloud אחת.

כדי לפרוס קובץ compose.yaml כשירות Cloud Run, פועלים לפי השלבים הבאים:

1. בספריית הפרויקט, יוצרים קובץ compose.yaml עם הגדרות השירות.

   services:
     web:
       image: IMAGE
       ports:
         - "8080:8080"

   מחליפים את IMAGE_URL בכתובת ה-URL של קובץ אימג' של קונטיינר.

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

פריסת השירות

1. כדי לפרוס את השירותים, מריצים את הפקודה gcloud run compose up:

   gcloud run compose up compose.yaml

2. מגיבים y לכל ההנחיות להתקנת רכיבים נדרשים או להפעלת ממשקי API.

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

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

MCP

אתם יכולים להשתמש בסוכן AI כדי לפרוס את השירות שלכם באמצעות שרת ה-MCP הרשמי של Cloud Run.

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

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

2. כדי לפרוס את השירות מקובץ אימג' לדוגמה של קונטיינר helloworld, מזינים את ההנחיה הבאה לסוכן: Deploy service "helloworld" to Cloud Run from the container image us-docker.pkg.dev/cloudrun/container/hello.

   הסוכן משתמש בכלי deploy_service_from_image כדי לפרוס קובץ אימג' של קונטיינר כשירות Cloud Run.

שימוש בהנחיה /deploy

תצוגה מקדימה

השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות, וגם בתנאים הנוספים למוצרים בגרסת טרום-GA של AI גנרטיבי. השימוש בתכונות בגרסת טרום-GA הוא "כפי שהן" (As is), ויכול להיות שהתמיכה בהן תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

אתם יכולים להשתמש בהנחיה /deploy כדי לפרוס במהירות שירות באמצעות שרת ה-MCP של Cloud Run. יכול להיות שתצטרכו לנווט בתפריט של הצ'אטבוט כדי למצוא את הכלי או ההנחיה שאתם צריכים.

כדי לפרוס את ספריית העבודה הנוכחית ב-Cloud Run, מריצים את ההנחיה /deploy הבאה:

/deploy SERVICE_NAME \
    --project PROJECT_ID \
    --region REGION \

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

• ‫SERVICE_NAME: השם של שירות Cloud Run
• ‫PROJECT_ID: מזהה הפרויקט Google Cloud
• ‫REGION: שם האזור

ספריות לקוח

כדי לפרוס שירות חדש מקוד:

• Go
• Java
• Node.js
• Python
• Ruby
• PHP
• ‎.NET

‫API בארכיטקטורת REST

כדי לפרוס שירות חדש, שולחים בקשת HTTP של POST אל נקודת הקצה service של Cloud Run Admin API.

לדוגמה, באמצעות curl:

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X POST \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services?serviceId=SERVICE

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

• ‫ACCESS_TOKEN: אסימון גישה תקף לחשבון שיש לו הרשאות IAM לפריסת שירותים. לדוגמה, אם אתם מחוברים ל-gcloud, אתם יכולים לאחזר אסימון גישה באמצעות gcloud auth print-access-token. מתוך מופע של קונטיינר ב-Cloud Run, אפשר לאחזר אסימון גישה באמצעות שרת המטא-נתונים של מופע הקונטיינר.
• ‫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 .
• ‫SERVICE: השם של השירות שרוצים לפרוס. שמות השירותים צריכים להיות באורך של עד 49 תווים, והם צריכים להיות ייחודיים לכל אזור ולכל פרויקט.
• ‫REGION: Google Cloud האזור של השירות.
• ‫PROJECT-ID: מזהה הפרויקט ב- Google Cloud .

מיקומים של Cloud Run

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

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

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

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

• asia-east1 (טייוואן)
• asia-northeast1 (טוקיו)
• ‫asia-northeast2 (אוסקה)
• asia-south1 (מומבאי, הודו)
• ‫asia-southeast3 (בנגקוק)
• europe-north1 (פינלנד) רמה נמוכה של CO₂
• europe-north2 (שטוקהולם) רמה נמוכה של CO₂
• europe-southwest1 (מדריד) רמה נמוכה של CO₂
• europe-west1 (בלגיה) רמה נמוכה של CO₂
• europe-west4 (הולנד) רמה נמוכה של CO₂
• europe-west8 (מילאנו)
• europe-west9 (פריז) רמה נמוכה של CO₂
• me-west1 (תל אביב)
• northamerica-south1 (מקסיקו)
• us-central1 (אייווה) רמה נמוכה של CO₂
• us-east1 (דרום קרוליינה)
• ‫us-east4 (צפון וירג'יניה)
• us-east5 (Columbus)
• us-south1 (דאלאס) רמה נמוכה של CO₂
• us-west1 (אורגון) רמה נמוכה של CO₂

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

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

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

אישור

פריסת גרסה חדשה של שירות קיים

אפשר לפרוס עדכון חדש באמצעות מסוף Google Cloud , שורת הפקודה gcloud או קובץ תצורה בפורמט YAML.

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

קובץ האימג' של הקונטיינר מיובא על ידי Cloud Run בזמן הפריסה. ‫Cloud Run שומר את העותק הזה של קובץ אימג' של קונטיינר כל עוד הוא בשימוש בגרסה שמוצגת.

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

המסוף

כדי לפרוס גרסה חדשה של שירות קיים:

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

   כניסה ל-Cloud Run

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

3. לוחצים על עריכה ופריסת גרסה חדשה כדי להציג את טופס הפריסה של הגרסה.

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

   2. מגדירים את מאגר התגים לפי הצורך.

   3. מגדירים חיוב לפי הצורך.

   4. בקטע Resources (משאבים), מציינים memory limits (מגבלות זיכרון) ו-CPU limits (מגבלות מעבד).

   5. מציינים את request timeout (זמן קצוב לתפוגת בקשה) ואת concurrency (מקביליות) לפי הצורך.

   6. מציינים סביבת הפעלה לפי הצורך.

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

   8. אפשר להשתמש בכרטיסיות האחרות לפי הצורך כדי להגדיר:

      • Secrets
      • משתני סביבה
      • ‫HTTP/2
      • חשבונות שירות
      • חיבורים ל-Cloud SQL
      • חיבור VPC

4. כדי לשלוח את כל התעבורה לגרסה החדשה, בוחרים באפשרות Serve this revision immediately (הצגת הגרסה הזו באופן מיידי). כדי להשיק בהדרגה גרסה חדשה, מבטלים את הסימון בתיבת הסימון הזו. כתוצאה מכך, הפריסה לא שולחת תנועה לגרסה החדשה. אחרי הפריסה, פועלים לפי ההוראות במאמר בנושא השקה הדרגתית.

5. לוחצים על פריסה וממתינים לסיום הפריסה.

gcloud

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

   הפעלת Cloud Shell

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

2. כדי לפרוס קובץ אימג' של קונטיינר:

   1. מריצים את הפקודה:

      gcloud run deploy SERVICE --image IMAGE_URL

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

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

      הסיומת של מספר הגרסה מוקצית באופן אוטומטי לגרסאות חדשות. אם רוצים לספק סיומת משלכם לציון מספר הגרסה, משתמשים בפרמטר --revision-suffix של ה-CLI של gcloud.

   2. ממתינים עד שהפריסה תסתיים. אחרי שתשלימו את התהליך בהצלחה, תוצג הודעת הצלחה וכתובת ה-URL של השירות שנפרס.

YAML

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

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

gcloud run services describe SERVICE --format export > service.yaml

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

gcloud run services replace service.yaml

Terraform

מוודאים שהגדרתם את Terraform כמו שמתואר בדוגמה פריסת שירות חדש.

1. מבצעים שינוי בקובץ ההגדרות.

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

   terraform apply

   כדי לאשר שרוצים להחיל את הפעולות שמתוארות, מזינים yes.

   הערה: אלא אם נדרש שינוי בהגדרה, לא נוצרת גרסה חדשה.

Cloud Code

כדי לפרוס גרסה חדשה של שירות קיים באמצעות Cloud Code, אפשר לקרוא את המדריכים ל-IntelliJ ול-Visual Studio Code.

פיתוח נייטיב

אפשר לאחסן את מפרט ה-Compose בקובץ YAML ואז לפרוס אותו כעדכון של שירות Cloud Run באמצעות פקודה אחת של gcloud.

כדי לפרוס קובץ compose.yaml כעדכון של שירות Cloud Run:

1. בספריית הפרויקט, יוצרים קובץ compose.yaml עם הגדרות השירות.

   services:
     web:
       image: IMAGE
       ports:
         - "8080:8080"

   מחליפים את IMAGE_URL בכתובת ה-URL של קובץ אימג' של קונטיינר.

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

פריסת השירות

1. כדי לפרוס את השירותים, מריצים את הפקודה gcloud run compose up:

   gcloud run compose up compose.yaml

2. מגיבים y לכל ההנחיות להתקנת רכיבים נדרשים או להפעלת ממשקי API.

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

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

ספריות לקוח

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

• Go
• Java
• Node.js
• Python
• Ruby
• PHP
• ‎.NET

‫API בארכיטקטורת REST

כדי לפרוס עדכון חדש, שולחים בקשת HTTP של PATCH אל נקודת הקצה של Cloud Run Admin API‏ service.

לדוגמה, באמצעות curl:

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X PATCH \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE

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

• ‫ACCESS_TOKEN: אסימון גישה תקין לחשבון שיש לו הרשאות IAM לפריסת עדכונים. לדוגמה, אם אתם מחוברים ל-gcloud, אתם יכולים לאחזר אסימון גישה באמצעות gcloud auth print-access-token. מתוך מופע של קונטיינר ב-Cloud Run, אפשר לאחזר אסימון גישה באמצעות שרת המטא-נתונים של מופע הקונטיינר.
• ‫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 .
• ‫SERVICE: השם של השירות שאתם פורסים.
• ‫REGION: Google Cloud האזור של השירות.
• ‫PROJECT-ID: מזהה הפרויקט ב- Google Cloud .

מיקומים של Cloud Run

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

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

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

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

• asia-east1 (טייוואן)
• asia-northeast1 (טוקיו)
• ‫asia-northeast2 (אוסקה)
• asia-south1 (מומבאי, הודו)
• ‫asia-southeast3 (בנגקוק)
• europe-north1 (פינלנד) רמה נמוכה של CO₂
• europe-north2 (שטוקהולם) רמה נמוכה של CO₂
• europe-southwest1 (מדריד) רמה נמוכה של CO₂
• europe-west1 (בלגיה) רמה נמוכה של CO₂
• europe-west4 (הולנד) רמה נמוכה של CO₂
• europe-west8 (מילאנו)
• europe-west9 (פריז) רמה נמוכה של CO₂
• me-west1 (תל אביב)
• northamerica-south1 (מקסיקו)
• us-central1 (אייווה) רמה נמוכה של CO₂
• us-east1 (דרום קרוליינה)
• ‫us-east4 (צפון וירג'יניה)
• us-east5 (Columbus)
• us-south1 (דאלאס) רמה נמוכה של CO₂
• us-west1 (אורגון) רמה נמוכה של CO₂

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

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

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

אישור

פריסת תמונות מפרויקטים אחרים Google Cloud

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

במאמר התפקידים הנדרשים מפורטים התפקידים הנדרשים לחשבון הפריסה.

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

1. במסוף Google Cloud , פותחים את הפרויקט של שירות Cloud Run.

   כניסה לדף IAM

2. בוחרים באפשרות Include Google-provided role grants.

3. מעתיקים את כתובת האימייל של סוכן השירות של Cloud Run. היא כוללת את הסיומת @serverless-robot-prod.iam.gserviceaccount.com

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

   כניסה לדף IAM

5. לוחצים על הוספה כדי להוסיף חשבון משתמש חדש.

6. בשדה New principals, מדביקים את כתובת האימייל של חשבון השירות שהעתקתם קודם.

7. בתפריט Select a role, לוחצים על Artifact Registry -> Artifact Registry Reader.

8. פורסים את קובץ האימג' של הקונטיינר בפרויקט שמכיל את שירות Cloud Run.

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

פריסת תמונות ממאגרי תמונות אחרים

כדי לפרוס קובצי אימג' ציבוריים או פרטיים של קונטיינרים שלא מאוחסנים ב-Artifact Registry או ב-Docker Hub, צריך להגדיר מאגר מרוחק של Artifact Registry.

מאגרי Artifact Registry מרחוק מאפשרים לכם:

• פריסת קובץ אימג' של קונטיינר ציבורי – לדוגמה, GitHub Container Registry‏ (ghcr.io).
• פריסת קובצי אימג' של קונטיינרים ממאגרים פרטיים שנדרש בהם אימות – לדוגמה, JFrog Artifactory או Nexus.

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

פריסת כמה קונטיינרים בשירות (sidecars)

בפריסה של Cloud Run עם קונטיינרים מסוג sidecar, יש קונטיינר כניסה אחד שמטפל בכל בקשות ה-HTTPS הנכנסות ביציאה של הקונטיינר שאתם מציינים, ויש קונטיינר sidecar אחד או יותר. הקונטיינרים מסוג sidecar לא יכולים להאזין לבקשות HTTP נכנסות ביציאה של קונטיינר הכניסה, אבל הם יכולים לתקשר אחד עם השני ועם קונטיינר הכניסה באמצעות יציאה של localhost. היציאה של localhost שבה נעשה שימוש משתנה בהתאם למאגרי התגים שבהם אתם משתמשים.

בתרשים הבא, קונטיינר הכניסה מתקשר עם קונטיינר ה-sidecar באמצעות localhost:5000.

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

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

אם אתם משתמשים בחיוב מבוסס-בקשה (ברירת המחדל ב-Cloud Run), מעבד מוקצה ל-sidecar רק בתרחישים הבאים:

• המופע מעבד לפחות בקשה אחת.
• קונטיינר הכניסה מתחיל לפעול.

אם קובץ ה-sidecar צריך להשתמש במעבד מחוץ לעיבוד הבקשות (למשל, לאיסוף מדדים), צריך להגדיר את הגדרת החיוב לחיוב מבוסס-אינסטנס לשירות. מידע נוסף זמין במאמר הגדרות חיוב (שירותים).

אם אתם משתמשים בחיוב לפי בקשה, אתם צריכים להגדיר בדיקת מוכנות להפעלה כדי לוודא שלא מתבצעת הגבלת מהירות של המעבד (CPU throttling) ב-sidecar בזמן ההפעלה.

כדי לדרוש שכל הפריסות ישתמשו ב-sidecar ספציפי, אפשר ליצור מדיניות ארגונית בהתאמה אישית.

תרחישים לדוגמה

תרחישים לדוגמה לשימוש ב-sidecar בשירות Cloud Run:

• מעקב, רישום ביומן ומעקב אחר אפליקציות
• שימוש ב-Nginx, ב-Envoy או ב-Apache2 כפרוקסי לפני קונטיינר האפליקציה
• הוספת מסנני אימות והרשאה (לדוגמה, Open Policy Agent)
• הפעלת שרתי proxy לחיבורים יוצאים, כמו שרת proxy ל-AlloyDB Auth

פריסת שירות עם קונטיינרים של קובצי עזר

אפשר לפרוס כמה קבצים מצורפים לשירות Cloud Run באמצעותGoogle Cloud המסוף, Google Cloud CLI,‏ YAML או Terraform.

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

המסוף

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

   כניסה ל-Cloud Run

   • כדי לפרוס לשירות קיים, מאתרים אותו ברשימת השירותים, לוחצים עליו כדי לפתוח אותו ואז לוחצים על עריכה ופריסה של עדכון חדש כדי להציג את טופס פריסת העדכון.
   • כדי לפרוס שירות חדש, לוחצים על Deploy container (פריסת קונטיינר) כדי להציג את הטופס Create service (יצירת שירות).

2. בשירות חדש,

   1. מזינים את שם השירות ואת כתובת ה-URL של קובץ האימג' של קונטיינר ה-Ingress שרוצים לפרוס.
   2. לוחצים על Containers, Networking, Security (מאגרי מידע, רשתות, אבטחה).

3. בכרטיס Edit container (עריכת מאגר תגים), מגדירים את מאגר התגים של ה-ingress לפי הצורך.

4. לוחצים על הוספת מאגר תגים ומגדירים מאגר תגים של sidecar שרוצים להוסיף לצד מאגר התגים של הכניסה. אם ה-sidecar תלוי בקונטיינר אחר בשירות, מציינים זאת בתפריט Container start-up order. חוזרים על השלב הזה לכל קונטיינר sidecar שפורסים.

5. כדי לשלוח את כל התעבורה לגרסה החדשה, בוחרים באפשרות Serve this revision immediately (הצגת הגרסה הזו באופן מיידי). כדי לבצע השקה הדרגתית, מבטלים את הסימון בתיבת הסימון הזו. כתוצאה מכך, הפריסה מתבצעת בלי שתנועה נשלחת לגרסה החדשה. אחרי הפריסה, פועלים לפי ההוראות במאמר בנושא השקות הדרגתיות.

6. לוחצים על Create (יצירה) כדי ליצור שירות חדש או על Deploy (פריסה) כדי לפרוס שירות קיים, ואז מחכים עד שהפריסה תסתיים.

gcloud

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

   הפעלת Cloud Shell

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

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

   gcloud run deploy SERVICE \
    --container INGRESS_CONTAINER_NAME \
    --image='INGRESS_IMAGE' \
    --port='CONTAINER_PORT' \
    --container SIDECAR_CONTAINER_NAME \
    --image='SIDECAR_IMAGE'

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

   • ‫SERVICE: השם של השירות שאתם פורסים. אפשר להשמיט את הפרמטר הזה לגמרי, אבל אם תשמיטו אותו, תתבקשו להזין את שם השירות.
   • ‫INGRESS_CONTAINER_NAME: שם של מאגר התגים שמקבל בקשות – לדוגמה app.
   • ‫INGRESS_IMAGE: הפניה לקובץ אימג' של קונטיינר שאליו צריך להפנות את הבקשות, לדוגמה us-docker.pkg.dev/cloudrun/container/hello:latest.
   • ‫CONTAINER_PORT: היציאה שבה מאזין קונטיינר הכניסה לבקשות נכנסות. בניגוד לשירות עם קונטיינר יחיד, בשירות שמכיל sidecars, אין יציאת ברירת מחדל לקונטיינר של הכניסה. צריך להגדיר במפורש את יציאת מאגר התגים עבור מאגר התגים של הכניסה, ויכול להיות רק מאגר תגים אחד עם יציאה חשופה.
   • ‫SIDECAR_CONTAINER_NAME: שם של קונטיינר ה-sidecar, לדוגמה sidecar.
   • ‫SIDECAR_IMAGE: הפניה לקובץ אימג' של קונטיינר sidecar

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

   gcloud run deploy SERVICE \
     --container CONTAINER_1_NAME \
     --image='INGRESS_IMAGE' \
     --set-env-vars=KEY=VALUE \
     --port='CONTAINER_PORT' \
     --container SIDECAR_CONTAINER_NAME \
     --image='SIDECAR_IMAGE' \
     --set-env-vars=KEY_N=VALUE_N

   חשוב: כשמשתמשים בדגל --container, צריך לציין את כל הדגלים שלא ברמת הקונטיינר לפני הדגלים ברמת הקונטיינר. אחרת, פקודת הפריסה תיכשל ותוצג הודעת שגיאה בהתאם. לדוגמה, בפקודה gcloud run services deploy service --execution-environment=gen2 --container app --memory=1G,
   צריך להעביר את הדגל --execution-environment לפני הדגל --container.

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

YAML

ההוראות האלה מציגות קובץ YAML בסיסי לשירות Cloud Run עם sidecars. יוצרים קובץ בשם service.yaml ומוסיפים לו את השורות הבאות:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: INGRESS_IMAGE
        ports:
          - containerPort: CONTAINER_PORT
      - image: SIDECAR_IMAGE
      

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

• ‫SERVICE: השם של שירות Cloud Run. שמות השירותים צריכים להיות באורך של עד 49 תווים.
• ‫CONTAINER_PORT: היציאה שבה מאזין קונטיינר הכניסה לבקשות נכנסות. בניגוד לשירות עם קונטיינר יחיד, בשירות שמכיל sidecars, אין יציאת ברירת מחדל לקונטיינר של הכניסה. צריך להגדיר במפורש את יציאת מאגר התגים עבור מאגר התגים של הכניסה, ויכול להיות רק מאגר תגים אחד עם יציאה חשופה.
• ‫INGRESS_IMAGE: הפניה לקובץ אימג' של קונטיינר שאליו צריך להפנות את הבקשות, לדוגמה us-docker.pkg.dev/cloudrun/container/hello:latest.
• ‫SIDECAR_IMAGE: הפניה לקובץ אימג' של קונטיינר sidecar. אפשר לציין כמה קונטיינרים משניים על ידי הוספת עוד רכיבים למערך containers ב-YAML.

אחרי שמעדכנים את קובץ ה-YAML כך שיכלול את קונטיינרי ה-ingress וה-sidecar, פורסים ל-Cloud Run באמצעות הפקודה:

gcloud run services replace service.yaml

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

מוסיפים את השורות הבאות למשאב google_cloud_run_v2_service בתצורת Terraform:

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  ingress = "INGRESS_TRAFFIC_ALL"
  template {
    containers {
      name = "INGRESS_CONTAINER_NAME"
      ports {
        container_port = CONTAINER_PORT
      }
      image = "INGRESS_IMAGE"
      depends_on = ["SIDECAR_CONTAINER_NAME"]
    }
    containers {
      name = "SIDECAR_CONTAINER_NAME"
      image = "SIDECAR_IMAGE"
      }
    }
  }

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

תכונות חשובות שזמינות לפריסות עם קבצים נלווים

סדר הפעלה

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

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

החלפת נתוני קבצים בין קבצי sidecar

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

תקשורת בין קונטיינרים מסוג sidecar

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

לדוגמה, נניח שיש שירות כזה:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example
spec:
  template:
    spec:
      containers:
      - name: ingress
        image: ...
        ports:
          - containerPort: 8080
      - name: sidecar
        image: ...

כל מופע של השירות הזה יפעיל שני קונטיינרים: אחד בשם ingress ואחד בשם sidecar.

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

מאגרי התגים ingress ו-sidecar יכולים לתקשר זה עם זה ב-http://localhost. לדוגמה, אם מאגר התגים sidecar מאזין לבקשות ביציאה 5000, אז מאגר התגים ingress יכול לתקשר איתו ביציאה http://localhost:5000.

מכיוון שהקונטיינרים נקראים בשם, הם יכולים אפילו לתקשר זה עם זה באמצעות שם הקונטיינר. לדוגמה, אם הקונטיינר sidecar מאזין לבקשות ביציאה 5000, הקונטיינר ingress יכול לתקשר עם sidecar באמצעות http://sidecar:5000.

התאמת קונטיינרים ל-Cloud Run

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

העברת נקודות העמסה להגדרות של Cloud Run

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

מעבר למשתמש ללא הרשאת root כשזה אפשרי

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

כדאי להשתמש בהוראה USER בקובץ Dockerfile כדי לעבור לזהות עם פחות הרשאות, כי ברירת המחדל היא הפעלה כמשתמש root. ‫Cloud Run משתמש במשתמש שצוין ב-Dockerfile כדי להריץ את הקונטיינר.

ביקורת על השימוש בקבצים בינאריים של setuid

הפעלת קובצי בינאריים setuid תיכשל אם היא תתבצע מהקונטיינרים שלכם ב-Cloud Run.

אם אתם משתמשים ב-Docker או ב-Podman באופן מקומי, צריך להשתמש בארגומנט --cap-drop=setuid. אפשרות אחרת היא לוודא שהבינאריים שאתם מסתמכים עליהם לא כוללים את הביט setuid.

מוודאים שמכלי הבסיס תואמים למרחבי שמות של משתמשים

כדי לבדוק את השינויים באופן מקומי או במכונה וירטואלית, צריך להעריך את הקוד כשמריצים אותו במרחבי שמות של משתמשים, למשל כשמשתמשים בתכונה userns-remap של Docker, כשמריצים את הקונטיינר ב-rootless Podman או כשפורסים את השינויים האלה במכונות וירטואליות שמריצות את מערכת ההפעלה שמותאמת לקונטיינרים מבית Google עם הארגומנט --userns-remap=default בפקודה docker run.

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

כברירת מחדל, 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
    ...
  }
}

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

אחרי שמפעילים שירות חדש, אפשר:

• השקות הדרגתיות, החזרת גרסאות למצב קודם, העברת תנועה
• הצגת יומני שירות
• מעקב אחרי ביצועי השירות
• הגדרת מגבלות זיכרון
• הגדרה של משתני סביבה
• שינוי של מספר השיחות המקבילות בשירות
• ניהול השירות
• ניהול עדכונים של שירותים
• דוגמה ל-sidecar של OpenTelemetry ב-Cloud Run
• פריסה של תמונות מהימנות בלבד באמצעות Binary Authorization (גרסת טרום-השקה (Preview))

אתם יכולים להשתמש בטריגרים של Cloud Build כדי לבצע אוטומציה של גרסאות ה-build והפריסות של שירותי Cloud Run:

• הגדרת פריסה רציפה

אפשר גם להשתמש ב-Cloud Deploy כדי להגדיר צינור עיבוד נתונים לפריסה רציפה (CD) לפריסת שירותי Cloud Run בכמה סביבות:

• פריסת אפליקציה ב-Cloud Run באמצעות Cloud Deploy