‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

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

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

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

מאגרי Container Registry וקובצי אימג' נתמכים

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

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

כדאי להשתמש ב-Docker Hub רק כדי לפרוס קובצי אימג' פופולריים של קונטיינרים, כמו קובצי אימג' רשמיים של Docker או קובצי אימג' של Docker בקוד פתוח (OSS) במימון. כדי לשפר את הזמינות, Google ממליצה לפרוס את קובצי האימג' האלה של Docker Hub או GitHub Container Registry באמצעות מאגר מרוחק של 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...).

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

המסוף

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

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

כניסה ל-Cloud Run
לוחצים על Deploy container כדי להציג את הטופס Create service.
בטופס, בוחרים את אפשרות הפריסה.
1. אם רוצים לפרוס קונטיינר באופן ידני, בוחרים באפשרות Deploy one revision from an existing container image ומציינים את קובץ האימג' של הקונטיינר.
2. אם רוצים להגדיר פריסה רציפה אוטומטית, בוחרים באפשרות פריסה רציפה של גרסאות חדשות ממאגר מקור ופועלים לפי ההוראות לפריסות רציפות.
מזינים שם לשירות. שמות השירותים צריכים להיות באורך של עד 49 תווים, וייחודיים לכל אזור ופרויקט. אי אפשר לשנות את שם השירות מאוחר יותר, והוא גלוי לכולם.
בשדה Region, בוחרים את האזור שבו רוצים למקם את השירות.

בורר האזורים מציין את רמת המחיר, את הזמינות של מיפוי הדומיינים ומדגיש אזורים עם ההשלכות הנמוכות ביותר של פליטת פחמן.
בקטע Authentication, קובעים את ההגדרות הבאות:
- אם אתם יוצרים API או אתר ציבוריים, בחרו באפשרות Allow public access. כשבוחרים באפשרות הזו, התפקיד "מפעיל IAM" מוקצה למזהה המיוחד allUser. אחרי שיוצרים את השירות, אפשר להשתמש ב-IAM כדי לערוך את ההגדרה הזו.
- אם רוצים שירות מאובטח שמוגן באמצעות אימות, בוחרים באפשרות Require authentication.
מגדירים את החיוב לפי הצורך.
בקטע Service scaling, אם אתם משתמשים בהתאמה אוטומטית לעומס (scaling) שמוגדרת כברירת מחדל ב-Cloud Run, אתם יכולים לציין את המספר המינימלי והמספר המקסימלי של המכונות, או להגדיר אמצעי בקרה להתאמה לעומס. אם אתם משתמשים בהתאמה ידנית לעומס (scaling), ציינו את מספר המכונות של השירות.
מגדירים את Ingress בטופס לפי הצורך.
לוחצים על Containers, Networking, Security כדי להגדיר הגדרות אופציונליות אחרות בכרטיסיות המתאימות:
כשמסיימים להגדיר את השירות, לוחצים על Create כדי לפרוס את קובץ האימג' ב-Cloud Run וממתינים לסיום הפריסה.
לוחצים על הקישור לכתובת ה-URL שמוצגת כדי לפתוח את נקודת הקצה הייחודית והיציבה של השירות שנפרס.

gcloud

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

הפעלת Cloud Shell

בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.
כדי לפרוס קובץ אימג' של קונטיינר:
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
```
כברירת מחדל, הפקודה 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). כדי להפוך את השירות לפרטי, צריך להסיר את הבית 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 בכתובת ה-URL של קובץ האימג' של הקונטיינר.

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

פריסת השירות

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

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

MCP

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

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

כדי להגדיר את שרת ה-MCP המרוחק של Cloud Run, פועלים לפי ההוראות במדריך שימוש בשרת ה-MCP המרוחק של Cloud Run.
כדי לפרוס את השירות מקובץ אימג' לדוגמה של קונטיינר 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

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

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

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

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

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

ספריות לקוח

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

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

כדי לפרוס שירות חדש, שולחים בקשת HTTP מסוג POST לנקודת הקצה (endpoint) של 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 ביחד בכמה מיקומים יכול להשפיע על זמן האחזור של השירות וגם על העלות.

אפשר להשתמש ב-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 (מילאנו) רמה נמוכה של CO₂
‫europe-west9 (פריז) רמה נמוכה של CO₂
me-west1 (תל אביב)
northamerica-south1 (מקסיקו)
us-central1 (אייווה) רמה נמוכה של CO₂
us-east1 (קרוליינה הדרומית)
us-east4 (צפון וירג'יניה)
us-east5 (קולומבוס)
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 (ורשה, פולין) רמה נמוכה של CO₂
europe-west10 (ברלין)
‫europe-west12 (טורינו) רמה נמוכה של CO₂
‫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 כל עוד גרסה פעילה משתמשת בו.

המסוף

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

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

כניסה ל-Cloud Run
ברשימת השירותים, לוחצים על השירות שרוצים לעדכן.
בכרטיסייה Containers (מאגרי תגים) אפשר לקבוע את ההגדרות הבאות:
בכרטיסייה Networking אפשר להגדיר את האפשרויות הבאות:
בכרטיסייה אבטחה אפשר לקבוע את ההגדרות הבאות:
בכרטיסייה Scaling אפשר להגדיר את הפרטים הבאים:
1. התאמה אוטומטית לעומס או התאמה ידנית לעומס
2. העדפות חיוב
3. זמן קצוב לתפוגת הבקשה ובו-זמניות
לוחצים על View diff & redeploy ואז על Deploy changes כדי לפרוס את השינויים.

gcloud

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

הפעלת Cloud Shell

בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.
כדי לפרוס קובץ אימג' של קונטיינר:
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

כברירת מחדל, הפקודה gcloud run services replace משתמשת בקובץ service.yaml אם הוא קיים.

Terraform

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

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

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

Cloud Code

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

פיתוח נייטיב

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

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

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

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

פריסת השירות

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

ספריות לקוח

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

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

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

לדוגמה, באמצעות 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 (מילאנו) רמה נמוכה של CO₂
‫europe-west9 (פריז) רמה נמוכה של CO₂
me-west1 (תל אביב)
northamerica-south1 (מקסיקו)
us-central1 (אייווה) רמה נמוכה של CO₂
us-east1 (קרוליינה הדרומית)
us-east4 (צפון וירג'יניה)
us-east5 (קולומבוס)
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 (ורשה, פולין) רמה נמוכה של CO₂
europe-west10 (ברלין)
‫europe-west12 (טורינו) רמה נמוכה של CO₂
‫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 .

אימות ההגדרות באמצעות הרצת בדיקה

כדי לאמת את הגדרת השירות בלי לפרוס אותה או לשמור את השינויים, אפשר להשתמש בדגל --dry-run.

כשמציינים את הדגל --dry-run, הפקודה מבצעת את הפעולות הבאות:

מאמת את ההגדרות האישיות.
עוקף את תהליך ה-build אם אתם פורסים מקוד המקור.
לא מגדיר כללי מדיניות של ניהול זהויות והרשאות גישה (IAM).
הדפסת הודעה על אימות מוצלח.

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

gcloud beta run deploy SERVICE \
    --image IMAGE_URL \
    --dry-run

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

‫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.

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

כניסה לדף IAM
לוחצים על Add כדי להוסיף חשבון משתמש חדש.
בשדה New principals, מדביקים את כתובת האימייל של חשבון השירות שהעתקתם קודם.
בתפריט Select a role, לוחצים על Artifact Registry -> Artifact Registry Reader.
פורסים את קובץ האימג' של הקונטיינר בפרויקט שמכיל את שירות Cloud Run.

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

פריסת קובצי אימג' ממאגרים אחרים

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

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

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

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

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

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

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

מאגר מרובה ב-Cloud Run

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

כדי לפרוס שירות חדש עם קונטיינרים מסוג sidecar:

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

כניסה ל-Cloud Run
לוחצים על Deploy container כדי להציג את הטופס Create service.
מזינים את שם השירות ואת כתובת ה-URL של קובץ האימג' של קונטיינר Ingress שרוצים לפרוס.
לוחצים על Containers, Networking, Security.
בכרטיס Edit container, מגדירים את מאגר ה-ingress לפי הצורך.
לוחצים על Add container ומגדירים קונטיינר משני שרוצים להוסיף לצד קונטיינר ה-ingress. אם ה-sidecar תלוי בקונטיינר אחר בשירות, צריך לציין את זה בתפריט Container start-up order. חוזרים על השלב הזה לכל קונטיינר משני שפורסים.
לוחצים על יצירה.

כדי להגדיר שירות קיים עם קובצי עזר:

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

כניסה ל-Cloud Run
כדי לפרוס לשירות קיים, לוחצים על השירות.
לוחצים על הכרטיסייה מאגרי תגים.
לוחצים על Add container ומגדירים קונטיינר משני שרוצים להוסיף לצד קונטיינר ה-ingress. אם ה-sidecar תלוי בקונטיינר אחר בשירות, צריך לציין את זה בתפריט Container start-up order. חוזרים על השלב הזה לכל קונטיינר משני שפורסים.
לוחצים על View diff & redeploy.
כדי לשלוח את כל התנועה לגרסה החדשה, בוחרים באפשרות Serve this revision immediately. כדי להשיק את העדכון בהדרגה, מבטלים את הסימון בתיבה הזו. כתוצאה מכך, מתבצע פריסה שבה לא נשלחת תנועה לגרסה החדשה. אחרי הפריסה, פועלים לפי ההוראות להשקות הדרגתיות.
לוחצים על Deploy changes.

gcloud

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

הפעלת Cloud Shell

בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.
כדי לפרוס כמה קונטיינרים בשירות, מריצים את הפקודה הבאה:
```
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 לבקשות נכנסות. בניגוד לשירות עם קונטיינר יחיד, בשירות שמכיל קונטיינרים של Sidecar אין יציאת ברירת מחדל לקונטיינר של 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 עם קונטיינרים של Sidecar. יוצרים קובץ בשם 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 לבקשות נכנסות. בניגוד לשירות עם קונטיינר יחיד, בשירות שמכיל קונטיינרים של Sidecar אין יציאת ברירת מחדל לקונטיינר של Ingress. צריך להגדיר במפורש את יציאת הקונטיינר של קונטיינר ה-ingress, ורק קונטיינר אחד יכול לחשוף את היציאה.
‫INGRESS_IMAGE: הפניה לקובץ האימג' של הקונטיינר שאמור לקבל בקשות, לדוגמה us-docker.pkg.dev/cloudrun/container/hello:latest.
‫SIDECAR_IMAGE: הפניה לקובץ האימג' של הקונטיינר המשני. כדי לציין כמה קובצי sidecar, מוסיפים עוד רכיבים למערך containers ב-YAML.

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

gcloud run services replace service.yaml

כברירת מחדל, הפקודה 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 אין יציאת ברירת מחדל לקונטיינר ה-ingress. צריך להגדיר במפורש את יציאת הקונטיינר של קונטיינר ה-ingress, ורק קונטיינר אחד יכול לחשוף את היציאה.

תכונות בולטות שזמינות לפריסות עם קונטיינרים מסוג sidecar

סדר ההפעלה

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

אם יש לכם קונטיינרים שתלויים בקונטיינרים אחרים, אתם צריכים להשתמש ב-healthchecks בפריסה. אם אתם משתמשים בבדיקות תקינות, 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. בשירות עם כמה קונטיינרים, אפשר להגדיר רק קונטיינר אחד כקונטיינר Ingress שמטפל בכל הבקשות הנכנסות, וזה חייב להיות הקונטיינר שמוגדר לו 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 בקובץ Docker, כי ברירת המחדל היא להריץ כ-root. כדי להריץ את הקונטיינר, Cloud Run משתמש במשתמש שצוין בקובץ ה-Dockerfile.

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

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

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

מוודאים שקונטיינרים ברמת הבסיס (root) תואמים למרחבי שמות של משתמשים

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

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

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

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

הגדרת פריסה רציפה (CD)

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

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

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

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

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

מאגרי Container Registry וקובצי אימג' נתמכים

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

המסוף

gcloud

YAML

Terraform

פיתוח נייטיב

MCP

ספריות לקוח

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

מיקומים של Cloud Run

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

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

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

המסוף

gcloud

YAML

Terraform

Cloud Code

פיתוח נייטיב

ספריות לקוח

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

מיקומים של Cloud Run

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

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

אימות ההגדרות באמצעות הרצת בדיקה

פריסת קובצי אימג' מפרויקטים אחרים ב- Google Cloud

פריסת קובצי אימג' ממאגרים אחרים

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

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

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

המסוף

gcloud

YAML

Terraform

תכונות בולטות שזמינות לפריסות עם קונטיינרים מסוג sidecar

סדר ההפעלה

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

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

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

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

כשזה אפשרי, כדאי לעבור למשתמש שאינו משתמש Root

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

מוודאים שקונטיינרים ברמת הבסיס (root) תואמים למרחבי שמות של משתמשים

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

gcloud

YAML

Terraform

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

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

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