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

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

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

המסוף

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

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

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

בורר האזורים מציין את רמת המחיר, את הזמינות של מיפויים של דומיינים ומדגיש אזורים עם ההשפעה הכי נמוכה על פליטת הפחמן.
בקטע אימות, מגדירים את האפשרויות הבאות:
- אם אתם יוצרים API או אתר ציבורי, בוחרים באפשרות Allow public access (מתן גישה לכולם). כשבוחרים באפשרות הזו, תפקיד IAM Invoker מוקצה למזהה המיוחד allUser. אפשר להשתמש ב-IAM כדי לערוך את ההגדרה הזו בהמשך, אחרי שיוצרים את השירות.
- אם רוצים שירות מאובטח שמוגן באמצעות אימות, בוחרים באפשרות דרישת אימות.
מגדירים חיוב לפי הצורך.
בקטע Service scaling (שינוי גודל השירות), אם משתמשים בהתאמה אוטומטית לעומס של Cloud Run שמוגדרת כברירת מחדל, אפשר לציין את מספר המכונות המינימלי. אם משתמשים בהגדלה או הקטנה ידנית של הקיבולת, צריך לציין את מספר המופעים של השירות.
מגדירים את ההגדרות של 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, פקודת הפריסה תנסה לפרוס מקוד המקור.
  אם אתם יוצרים 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 (מילאנו)
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 שומר את העותק הזה של קובץ אימג' של קונטיינר כל עוד הוא בשימוש בגרסה שמוצגת.

המסוף

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

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

כניסה ל-Cloud Run
לוחצים על השירות שרוצים לעדכן ברשימת השירותים.
בכרטיסייה מאגרי תגים אפשר להגדיר את האפשרויות הבאות:
בכרטיסייה Networking אפשר להגדיר את האפשרויות הבאות:
בכרטיסייה אבטחה אפשר להגדיר את ההגדרות הבאות:
1. העדפות אימות
2. חשבונות שירות
3. Binary Authorization
4. מפתחות KMS של לקוחות
5. Cloud Run Threat Detection
בכרטיסייה שינוי גודל אפשר להגדיר את האפשרויות הבאות:
לוחצים על הצגת ההבדלים ופריסה מחדש ואז על פריסת שינויים כדי לפרוס את השינויים.

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

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

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 אל נקודת הקצה של 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 .

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

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

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

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

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

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

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

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

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

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

כדי לדרוש שכל הפריסות ישתמשו ב-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. חוזרים על השלב הזה לכל קונטיינר sidecar שפורסים.
לוחצים על יצירה.

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

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

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

gcloud

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

הפעלת 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: היציאה שבה מאזין קונטיינר הכניסה לבקשות נכנסות. בניגוד לשירות עם קונטיינר יחיד, בשירות שמכיל sidecars, אין יציאת ברירת מחדל לקונטיינר של הכניסה. צריך להגדיר במפורש את יציאת המאגר עבור מאגר הכניסה, ויכול להיות רק מאגר אחד עם יציאה חשופה.
- ‫SIDECAR_CONTAINER_NAME: שם של קונטיינר ה-sidecar, לדוגמה sidecar.
- ‫SIDECAR_IMAGE: הפניה לקובץ אימג' של קונטיינר sidecar
אם רוצים להגדיר כל מאגר תגים בפקודת הפריסה, צריך לספק את ההגדרה של כל מאגר אחרי הפרמטרים container, לדוגמה:
```
gcloud run deploy SERVICE \
  --container CONTAINER_1_NAME \
  --image='INGRESS_IMAGE' \
  --set-env-vars=KEY=VALUE \
  --port='CONTAINER_PORT' \
  --container SIDECAR_CONTAINER_NAME \
  --image='SIDECAR_IMAGE' \
  --set-env-vars=KEY_N=VALUE_N
```
חשוב: כשמשתמשים בדגל --container, צריך לציין את כל הדגלים שאינם ברמת מאגר התגים לפני הדגלים ברמת מאגר התגים, אחרת פקודת הפריסה תיכשל ותוצג הודעת שגיאה בהתאם. לדוגמה, בפקודה gcloud run services deploy service --execution-environment=gen2 --container app --memory=1G,
צריך להעביר את הדגל --execution-environment לפני הדגל --container.
מחכים שהפריסה תסתיים. אחרי השלמת הפריסה בהצלחה, תוצג הודעה על כך יחד עם כתובת ה-URL של השירות שנפרס.

YAML

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

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

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

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

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

gcloud run services replace service.yaml

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

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

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

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

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

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

gcloud

YAML

Terraform

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

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

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