פריסת קובצי אימג' של קונטיינרים ב-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 Official Images או Docker Sponsored OSS images. כדי להגדיל את הזמינות, 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...).

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

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

המסוף

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

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

כניסה ל-Cloud Run
לוחצים על Deploy container (פריסת מאגר) כדי להציג את הטופס Create service (יצירת שירות).
1. בטופס, בוחרים את אפשרות הפריסה:
  1. אם רוצים לפרוס מאגר באופן ידני, בוחרים באפשרות Deploy one revision from an existing container image (פריסת גרסה אחת מקובץ אימג' של קונטיינר קיים) ומציינים את קובץ האימג' של הקונטיינר.
  2. אם רוצים להגדיר אוטומציה לפריסה רציפה, בוחרים באפשרות Continuously deploy new revisions from a source repository (פריסה רציפה של עדכונים חדשים ממאגר מקור) ופועלים לפי ההוראות לפריסות רציפות.
2. מזינים את שם השירות הנדרש. שמות השירותים צריכים להיות באורך של 49 תווים או פחות, והם צריכים להיות ייחודיים לכל אזור ופרויקט. אי אפשר לשנות את שם השירות אחר כך, והוא גלוי לכולם.
3. בוחרים את האזור שבו רוצים למקם את השירות. בורר האזורים מציין את רמת המחיר, את הזמינות של מיפויים של דומיינים ומדגיש אזורים עם השלכות פליטת הפחמן הנמוכות ביותר.
4. מגדירים חיוב לפי הצורך.
5. בקטע Service scaling (שינוי גודל השירות), אם משתמשים בהתאמה אוטומטית לעומס של Cloud Run שמוגדרת כברירת מחדל, אפשר לציין את מספר המכונות המינימלי. אם משתמשים בהגדלה או הקטנה ידנית של הקיבולת, צריך לציין את מספר המופעים של השירות.
6. מגדירים את ההגדרות של Ingress בטופס לפי הצורך.
7. בקטע אימות, מגדירים את האפשרויות הבאות:
  - אם אתם יוצרים API ציבורי או אתר, בוחרים באפשרות Allow public access. כשבוחרים באפשרות הזו, תפקיד IAM Invoker מוקצה למזהה המיוחד allUser. אפשר להשתמש ב-IAM כדי לערוך את ההגדרה הזו בהמשך, אחרי שיוצרים את השירות.
  - אם רוצים שירות מאובטח שמוגן באמצעות אימות, בוחרים באפשרות דרישת אימות.
לוחצים על Container(s), Volumes, Networking, Security כדי להגדיר הגדרות אופציונליות אחרות בכרטיסיות המתאימות:
כשמסיימים להגדיר את השירות, לוחצים על יצירה כדי לפרוס את האימג' ב-Cloud Run ומחכים שהפריסה תסתיים.
לוחצים על הקישור לכתובת ה-URL שמוצגת כדי לפתוח את נקודת הקצה הייחודית והיציבה של השירות שפרסתם.

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
כדי לפרוס קובץ אימג' של קונטיינר:
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.

יוצרים קובץ service.yaml חדש עם התוכן הבא:
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: IMAGE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVICE: השם של שירות Cloud Run. שמות השירותים צריכים להיות באורך של 49 תווים או פחות, והם צריכים להיות ייחודיים לכל אזור ופרויקט.
- ‫IMAGE: כתובת ה-URL של קובץ אימג' של קונטיינר.
אפשר גם לציין הגדרות נוספות, כמו משתני סביבה או מגבלות זיכרון.
מפעילים את השירות החדש באמצעות הפקודה הבאה:
```
gcloud run services replace service.yaml
```
אם רוצים לאפשר גישה לשירות ללא אימות, אפשר להגדיר את השירות כציבורי.

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, פועלים לפי השלבים הבאים:

בספריית הפרויקט, יוצרים קובץ compose.yaml עם הגדרות השירות.
```
services:
  web:
    image: IMAGE
    ports:
      - "8080:8080"
```
מחליפים את IMAGE בכתובת ה-URL של קובץ אימג' של קונטיינר.

אפשר גם לציין אפשרויות הגדרה נוספות, כמו משתני סביבה, סודות והצמדות של נפחים.
כדי לפרוס את השירותים, מריצים את הפקודה gcloud beta run compose up:
```
gcloud beta run compose up compose.yaml
```
מגיבים y לכל ההנחיות להתקנת הרכיבים הנדרשים או להפעלת ממשקי API.
אופציונלי: הפיכת השירות לציבורי אם רוצים לאפשר גישה לשירות ללא אימות.

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

ספריות לקוח

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

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 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 (ברלין)
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 שומר את העותק הזה של קובץ אימג' של קונטיינר כל עוד הוא נמצא בשימוש בגרסה שמוצגת.

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

המסוף

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

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

כניסה ל-Cloud Run
מאתרים את השירות שרוצים לעדכן ברשימת השירותים ולוחצים על הסמל כדי לפתוח את פרטי השירות.
לוחצים על עריכה ופריסת גרסה חדשה כדי להציג את טופס הפריסה של הגרסה.
1. אם צריך, ספקו את כתובת ה-URL של קובץ האימג' של הקונטיינר החדש שרוצים לפרוס.
2. מגדירים את מאגר התגים לפי הצורך.
3. מגדירים חיוב לפי הצורך.
4. בקטע 'קיבולת', מציינים מגבלות זיכרון ומגבלות מעבד.
5. מציינים את request timeout (זמן קצוב לתפוגת בקשה) ואת concurrency (מקבילות) לפי הצורך.
6. מציינים סביבת הפעלה לפי הצורך.
7. בקטע התאמה אוטומטית לעומס, מציינים את מספר המופעים המינימלי והמקסימלי.
8. אפשר להשתמש בכרטיסיות האחרות לפי הצורך כדי להגדיר את האפשרויות הבאות:
כדי לשלוח את כל התעבורה לגרסה החדשה, בוחרים באפשרות Serve this revision immediately (הצגת הגרסה הזו באופן מיידי). כדי להשיק בהדרגה גרסה חדשה, מבטלים את הסימון בתיבת הסימון הזו. כתוצאה מכך, הפריסה לא שולחת תנועה לגרסה החדשה. פועלים לפי ההוראות במאמר בנושא פריסה הדרגתית אחרי הפריסה.
לוחצים על Deploy (פריסה) וממתינים לסיום הפריסה.

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
כדי לפרוס קובץ אימג' של קונטיינר:
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:

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

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

gcloud run services replace service.yaml

Cloud Code

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

Terraform

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

מבצעים שינוי בקובץ התצורה.
מחילים את ההגדרות של Terraform:
```
terraform apply
```
כדי לאשר שרוצים להחיל את הפעולות שמתוארות, מזינים yes.

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

פיתוח נייטיב

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

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

בספריית הפרויקט, יוצרים קובץ compose.yaml עם הגדרות השירות.
```
services:
  web:
    image: IMAGE
    ports:
      - "8080:8080"
```
מחליפים את IMAGE בכתובת ה-URL של קובץ אימג' של קונטיינר.

אפשר גם לציין אפשרויות הגדרה נוספות, כמו משתני סביבה, סודות והצמדות של נפחים.
כדי לפרוס את השירותים, מריצים את הפקודה gcloud beta run compose up:
```
gcloud beta run compose up compose.yaml
```
מגיבים y לכל ההנחיות להתקנת הרכיבים הנדרשים או להפעלת ממשקי API.
אופציונלי: הפיכת השירות לציבורי אם רוצים לאפשר גישה לשירות ללא אימות.

ספריות לקוח

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

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 זמין באזורים הבאים:

בכפוף לתמחור ברמה 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 (ברלין)
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 את התפקידים הנדרשים, פועלים לפי ההוראות הבאות:

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

כניסה לדף IAM
מסמנים את התיבה Include Google-provided role grants.
מעתיקים את כתובת האימייל של סוכן השירות של Cloud Run. היא כוללת את הסיומת @serverless-robot-prod.iam.gserviceaccount.com
פותחים את הפרויקט שכולל את מאגר התמונות של מאגר המכולות שרוצים להשתמש בו.

כניסה לדף IAM
לוחצים על הוספה כדי להוסיף חשבון משתמש חדש.
בשדה New principals, מדביקים את כתובת האימייל של חשבון השירות שהעתקתם קודם.
בתפריט Select a role, לוחצים על Artifact Registry -> Artifact Registry Reader.
פורסים את קובץ האימג' של הקונטיינר בפרויקט שמכיל את שירות 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, יש קונטיינר ingress אחד שמטפל בכל בקשות ה-HTTPS הנכנסות ביציאת הקונטיינר שאתם מציינים, ויש קונטיינר sidecar אחד או יותר. קובצי העזר לא יכולים להאזין לבקשות HTTP נכנסות ביציאה של קונטיינר ה-Ingress, אבל הם יכולים לתקשר אחד עם השני ועם קונטיינר ה-Ingress באמצעות יציאה של localhost. היציאה של localhost שבה נעשה שימוש משתנה בהתאם למאגרי התגים שבהם אתם משתמשים.

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

קונטיינרים מרובים ב-Cloud Run

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

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

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

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

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

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

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

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

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

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

פריסת שירות עם קונטיינרים מסוג sidecar

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

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

המסוף

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

כניסה ל-Cloud Run
- כדי לפרוס לשירות קיים, מאתרים אותו ברשימת השירותים, לוחצים עליו כדי לפתוח אותו ואז לוחצים על עריכה ופריסה של עדכון חדש כדי להציג את טופס הפריסה של העדכון.
- כדי לפרוס שירות חדש, לוחצים על Deploy container (פריסת קונטיינר) כדי להציג את הטופס Create service (יצירת שירות).
בשירות חדש,
1. מזינים את שם השירות ואת כתובת ה-URL של קובץ האימג' בקונטיינר של ה-Ingress שרוצים לפרוס.
2. לוחצים על Container(s), Volumes, Networking, Security.
בכרטיס עריכת מאגר תגים, מגדירים את מאגר התגים של הכניסה לפי הצורך.
לוחצים על הוספת מאגר תגים ומגדירים מאגר תגים מסוג sidecar שרוצים להוסיף לצד מאגר התגים של ה-ingress. אם ה-sidecar תלוי בקונטיינר אחר בשירות, מציינים זאת בתפריט Container start-up order. חוזרים על השלב הזה לכל קונטיינר sidecar שפורסים.
כדי לשלוח את כל התעבורה לגרסה החדשה, בוחרים באפשרות Serve this revision immediately (הצגת הגרסה הזו באופן מיידי). כדי לבצע השקה הדרגתית, מבטלים את הסימון בתיבת הסימון הזו. התוצאה היא פריסה שבה לא נשלחת תנועה לגרסה החדשה. אחרי הפריסה, פועלים לפי ההוראות במאמר בנושא השקה הדרגתית.
לוחצים על Create (יצירה) כדי ליצור שירות חדש או על Deploy (פריסה) כדי לפרוס שירות קיים, ואז מחכים עד שהפריסה תסתיים.

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
כדי לפרוס כמה מאגרי תגים לשירות, מריצים את הפקודה הבאה:
```
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: היציאה שבה מאזין קונטיינר ה-Ingress לבקשות נכנסות. בניגוד לשירות עם קונטיינר יחיד, בשירות שמכיל קובצי עזר, אין יציאה שמוגדרת כברירת מחדל לקונטיינר של Ingress. צריך להגדיר באופן מפורש את יציאת הקונטיינר עבור קונטיינר הכניסה, ורק לקונטיינר אחד יכולה להיות יציאה חשופה.
- ‫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.
ממתינים עד שהפריסה תסתיים. אחרי שתשלימו את התהליך בהצלחה, תוצג הודעה על כך יחד עם כתובת ה-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: היציאה שבה מאזין קונטיינר ה-Ingress לבקשות נכנסות. בניגוד לשירות עם קונטיינר יחיד, בשירות שמכיל קובצי עזר, אין יציאה שמוגדרת כברירת מחדל לקונטיינר של Ingress. צריך להגדיר באופן מפורש את יציאת הקונטיינר עבור קונטיינר הכניסה, ורק לקונטיינר אחד יכולה להיות יציאה חשופה.
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 מייצג את היציאה שבה מאזין קונטיינר ה-Ingress לבקשות נכנסות. בניגוד לשירות עם קונטיינר יחיד, בשירות שמכיל קונטיינרים מסוג 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.

‫Containers ingress and sidecar can communicate with each other on 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.

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

כדי לבדוק את השינויים באופן מקומי או ב-VM, צריך להעריך את הקוד כשמריצים אותו במרחבי שמות של משתמשים, למשל כשמשתמשים בתכונה userns-remap של Docker, כשמריצים את הקונטיינר ב-rootless Podman או כשפורסים את השינויים האלה ב-VM שמריצות את מערכת ההפעלה שמותאמת לקונטיינרים מבית 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
    ...
  }
}

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

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

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

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

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

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

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

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

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

מאגרי תמונות וקונטיינרים נתמכים

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

המסוף

gcloud

YAML

Terraform

פיתוח נייטיב

ספריות לקוח

API ל-REST

מיקומים של Cloud Run

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

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

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

המסוף

gcloud

YAML

Cloud Code

Terraform

פיתוח נייטיב

ספריות לקוח

API ל-REST

מיקומים של Cloud Run

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

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

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

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

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

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

פריסת שירות עם קונטיינרים מסוג sidecar

המסוף

gcloud

YAML

Terraform

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

סדר הפעלה

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

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

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

העברת נקודות טעינה להגדרות של Cloud Run

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

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

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

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

gcloud

YAML

Terraform

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

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

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