‫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 Reader (roles/artifactregistry.reader) במאגר Artifact Registry של קובץ האימג' של הקונטיינר שנפרס
אם משתמשים בחשבון שירות חוצה-פרויקטים כדי לפרוס שירות: יצירת אסימונים בחשבון שירות (roles/iam.serviceAccountTokenCreator) בזהות השירות

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

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

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

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

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

המסוף

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

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

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

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

gcloud

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

הפעלת 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, הפקודה deploy תנסה לפרוס מקוד המקור.
  אם אתם יוצרים 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
```
אם קיים קובץ service.yaml, הפקודה gcloud run services replace משתמשת בו כברירת מחדל.
אפשרות נוספת: הגדרת השירות כציבורי אם רוצים לאפשר גישה לשירות ללא אימות.

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 בכתובת ה-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 על פני ה-CLI של gcloud לפני שמתחילים להשתמש בשרת ה-MCP הזה.

כדי להגדיר את שרת ה-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 לנקודת הקצה 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 (מילאנו) רמה נמוכה של CO₂
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 (ורשה, פולין) רמה נמוכה של 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 אפשר להגדיר את האפשרויות הבאות:
בכרטיסייה אבטחה אפשר להגדיר את האפשרויות הבאות:
1. העדפות אימות
2. חשבונות שירות
3. Binary Authorization
4. מפתחות KMS של לקוחות
5. Cloud Run Threat Detection
בכרטיסייה Scaling אפשר להגדיר את הפרטים הבאים:
1. התאמה אוטומטית לעומס או התאמה ידנית לעומס
2. העדפות חיוב
3. זמן קצוב לתפוגת הבקשה ובו-זמניות
לוחצים על הצגת ההבדלים ופריסה מחדש ואז על פריסת השינויים כדי לפרוס את השינויים.

gcloud

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

הפעלת 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.
אופציונלי: הפיכת השירות לציבורי אם רוצים לאפשר גישה לשירות ללא אימות.

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

ספריות לקוח

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

‫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 (מילאנו) רמה נמוכה של CO₂
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 (ורשה, פולין) רמה נמוכה של 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.
פותחים את הפרויקט שבבעלותו נמצא מאגר ה-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 עם קונטיינרים מסוג sidecar, יש קונטיינר כניסה אחד שמטפל בכל בקשות ה-HTTPS הנכנסות ביציאה של הקונטיינר שאתם מציינים, ויש קונטיינר sidecar אחד או יותר. ה-sidecars לא יכולים להאזין לבקשות HTTP נכנסות ביציאת מאגר ה-ingress, אבל הם יכולים לתקשר זה עם זה ועם מאגר ה-ingress באמצעות יציאת localhost. היציאה של localhost שבה נעשה שימוש משתנה בהתאם למאגרי התוכן שבהם אתם משתמשים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

כדי לפרוס שירות חדש עם sidecars:

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

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

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

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

כניסה ל-Cloud Run
כדי לפרוס לשירות קיים, לוחצים על השירות.
לוחצים על הכרטיסייה Containers (מאגרי תגים).
לוחצים על הוספת מאגר תגים ומגדירים מאגר תגים של sidecar שרוצים להוסיף לצד מאגר התגים של הכניסה. אם ה-sidecar תלוי בקונטיינר אחר בשירות, מציינים זאת בתפריט Container start-up order. חוזרים על השלב הזה לכל קובץ sidecar שפורסים.
לוחצים על הצגת ההבדלים ופריסה מחדש.
כדי לשלוח את כל התעבורה לגרסה החדשה, בוחרים באפשרות Serve this revision immediately (הצגת הגרסה הזו באופן מיידי). כדי לבצע השקה מדורגת, מבטלים את הסימון בתיבת הסימון. כתוצאה מכך, מתבצע פריסה שבה לא נשלחת תנועה לגרסה החדשה. אחרי הפריסה, פועלים לפי ההוראות במאמר בנושא פריסה הדרגתית.
לוחצים על פריסת השינויים.

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

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

gcloud run services replace service.yaml

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

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, ורק קונטיינר אחד יכול לחשוף את היציאה.

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

סדר ההפעלה

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

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

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

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

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

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

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

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

אתם יכולים גם להשתמש ב-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

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

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

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

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

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

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

gcloud

YAML

Terraform

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

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

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