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

יצירת משרות

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

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

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

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

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

כברירת מחדל, כל משימה פועלת למשך 10 דקות לכל היותר. אפשר לשנות את ערך ברירת המחדל על ידי שינוי ההגדרה של הזמן הקצוב לתפוגה של המשימה, עד 168 שעות (7 ימים). במשימות שמשתמשות במעבדי GPU, הזמן הקצוב המקסימלי לתפוגה הוא 12 שעות.

אין זמן קצוב לתפוגה מפורש להרצת משימה: אחרי שכל המשימות הושלמו, הרצת המשימה הושלמה.

המשימות משתמשות בסביבת ההפעלה מהדור השני.

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

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

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

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

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

יצירת משימה חדשה

אפשר ליצור משימה חדשה באמצעות מסוף Google Cloud , ה-CLI של gcloud,‏ YAML,‏ Terraform, ספריות לקוח או ה-API בארכיטקטורת REST:

המסוף

כדי ליצור משימה חדשה:

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

כניסה לדף Cloud Run jobs
לוחצים על Deploy container כדי להציג את הטופס Create job.
בטופס, מציינים את קובץ האימג' של הקונטיינר שמכיל את קוד המשימה, או בוחרים מתוך רשימה של קונטיינרים שנפרסו בעבר.
שם המשימה נוצר באופן אוטומטי מקובץ האימג' של הקונטיינר. אפשר לערוך את שם המשימה בטופס לפי הצורך. אחרי ששולחים את הטופס, אי אפשר לערוך את שם המשרה.
בשדה Region, בוחרים את האזור של המשימה. בכלי לבחירת אזור מודגשים האזורים עם ההשלכות הנמוכות ביותר של פליטת פחמן.
מציינים את מספר המשימות שרוצים להריץ במשימה. כדי שהמשימה תצליח, כל המשימות צריכות להצליח. כברירת מחדל, המשימות מופעלות במקביל.
לוחצים על Containers, Networking, Security כדי להגדיר מאפיינים נוספים של המשימה.
בקטע Edit container, אפשר לקבוע את ההגדרות הבאות בכרטיסיות המתאימות:
בקטע Task capacity, מציינים את הפרטים הבאים:
1. בשדה Task timeout, מציינים את משך הזמן המקסימלי בשניות שהמשימה יכולה לפעול, עד 168 שעות (7 ימים). למשימות שמשתמשות ב-GPU, הזמן הקצוב המקסימלי הוא 12 שעות. כל משימה צריכה להסתיים בפרק הזמן הזה. ברירת המחדל היא 10 דקות.
2. בשדה Number of retries per failed task, מציינים את מספר הניסיונות החוזרים במקרה של משימות שנכשלו. ברירת המחדל היא 3 ניסיונות חוזרים.
בקטע Parallelism, בוחרים באפשרות Run as many tasks concurrently as possible אם צריך להגדיר מגבלה נמוכה יותר בגלל אילוצי התאמה לעומס (scaling) במשאבים שהמשימה ניגשת אליהם, או בוחרים באפשרות Limit the maximum number of concurrent tasks ומציינים את מספר המשימות בו-זמנית בשדה Custom parallelism limit.
כשמסיימים להגדיר את המשימה, לוחצים על Create כדי ליצור את המשימה ב-Cloud Run.
כדי להריץ את המשימה, קראו את המאמר הרצת משימות או הרצת משימות לפי לוח זמנים.

gcloud

כדי להשתמש בשורת הפקודה, צריך להגדיר את ה-CLI של gcloud.

כדי ליצור משימה חדשה:

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

gcloud run jobs create JOB --image IMAGE_URL OPTIONS

לחלופין, אפשר להשתמש בפקודת הפריסה:

gcloud run jobs deploy JOB --image IMAGE_URL OPTIONS

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

‫JOB: השם של המשימה ב-Cloud Run.
‫IMAGE_URL: הפניה לקובץ האימג' של הקונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/job:latest.

‫OPTIONS (אופציונלי): כל אחת מהאפשרויות הבאות:

אפשרות	תיאור
`--tasks`	אפשר להזין מספרים שלמים שגדולים מ-1 או שווים לו. ברירת המחדל היא 1, והערך המקסימלי הוא 10,000. לכל משימה מוקצים משתני הסביבה `CLOUD_RUN_TASK_INDEX` עם ערך בין 0 למספר המשימות פחות 1, וגם `CLOUD_RUN_TASK_COUNT`, שהוא מספר המשימות.
`--max-retries`	מספר הפעמים שבהן המערכת מנסה להפעיל מחדש משימה שנכשלה. אם משימה כלשהי נכשלת מעבר למגבלה הזו, המשימה כולה מסומנת כנכשלה. לדוגמה, אם הערך הוא 1, המערכת תנסה להפעיל מחדש משימה שנכשלה פעם אחת, כך שיהיו שתי הפעלות בסך הכול. ערך ברירת המחדל הוא 3. אפשר להזין מספרים שלמים מ-0 עד 10.
`--task-timeout`	אפשר להזין משך זמן כמו "2s". ברירת המחדל היא 10 דקות, והמקסימום הוא 168 שעות (7 ימים). במשימות שמשתמשות ב-GPU, הזמן הקצוב המקסימלי לתפוגה הוא 12 שעות.
`--parallelism`	המספר המקסימלי של משימות שאפשר להריץ במקביל. כברירת מחדל, המשימות יתחילו לפעול במקביל כמה שיותר מהר. בקטע מקביליות מפורט טווח הערכים.
`--execute-now`	אם מגדירים את זה, ביצוע המשימה מתחיל מיד אחרי שהמשימה נוצרת. שווה ערך לקריאה ל-`gcloud run jobs create` ואחריה ל-`gcloud run jobs execute`.

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

הרשימה המלאה של האפשרויות שזמינות כשיוצרים משימה מופיעה במסמכי התיעוד של שורת הפקודה gcloud run jobs create.

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

YAML

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

יוצרים קובץ job.yaml חדש עם התוכן הבא:
```
apiVersion: run.googleapis.com/v1
kind: Job
metadata:
  name: JOB
spec:
  template:
    spec:
      template:
        spec:
          containers:
          - image: IMAGE_URL
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫JOB: השם של המשימה ב-Cloud Run.
- ‫IMAGE_URL: הפניה לקובץ האימג' של הקונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/job:latest.
אפשר גם לציין הגדרות נוספות, כמו משתני סביבה או מגבלות זיכרון.
מריצים את הפקודה הבאה כדי לפרוס את המשימה החדשה:
```
gcloud run jobs replace job.yaml
```

Terraform

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

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

resource "google_cloud_run_v2_job" "default" {
  name     = "cloud-run-job"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    template {
      containers {
        image = "us-docker.pkg.dev/cloudrun/container/job:latest"
      }
    }
  }
}

ספריות לקוח

כדי ליצור משימה מקוד:

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

כדי ליצור משימה, שולחים בקשת HTTP מסוג POST לנקודת הקצה (endpoint) של jobs ב-Cloud Run Admin API.

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

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

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

‫ACCESS_TOKEN: אסימון גישה תקין לחשבון עם הרשאות IAM ליצירת משימות. לדוגמה, אם אתם מחוברים ל-gcloud, אתם יכולים לאחזר אסימון גישה באמצעות gcloud auth print-access-token. מתוך מכונה של קונטיינר ב-Cloud Run, אתם יכולים לאחזר אסימון גישה באמצעות שרת המטא-נתונים של המכונה של הקונטיינר.
‫IMAGE_URL: הפניה לקובץ האימג' של הקונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/job:latest.
‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
‫REGION: האזור של המשימה, Google Cloud .
‫JOB: שם המשימה שרוצים ליצור.

מיקומים של 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 .

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

עדכון משרה קיימת

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

אפשר לעדכן משימה קיימת באמצעות מסוף Google Cloud , ה-CLI של gcloud, ‏YAML, ‏Terraform, ספריות לקוח או ה-API בארכיטקטורת REST:

המסוף

כדי לעדכן משימה קיימת:

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

כניסה לדף Cloud Run jobs
לוחצים על המשימה כדי להציג את הדף Job details.
לוחצים על הצגה ועריכה של הגדרות המשימה.
אופציונלי: משנים את מספר המשימות במשימה לפי הצורך.
אופציונלי: לוחצים על Containers, Networking, Security כדי לעדכן מאפיינים נוספים של המשימה:
בקטע Task capacity, מציינים את הפרטים הבאים:
1. בשדה Task timeout, מציינים את משך הזמן המקסימלי בשניות שהמשימה יכולה לפעול, עד 168 שעות (7 ימים). למשימות שמשתמשות ב-GPU, הזמן הקצוב המקסימלי הוא 12 שעות. כל משימה צריכה להסתיים בפרק הזמן הזה. ברירת המחדל היא 10 דקות.
2. בשדה Number of retries per failed task, מציינים את מספר הניסיונות החוזרים במקרה של משימות שנכשלו. ברירת המחדל היא 3 ניסיונות חוזרים.
בקטע Parallelism, בוחרים באפשרות Run as many tasks concurrently as possible אם צריך להגדיר מגבלה נמוכה יותר בגלל אילוצי התאמה לעומס (scaling) במשאבים שהמשימה ניגשת אליהם, או בוחרים באפשרות Limit the maximum number of concurrent tasks ומציינים את מספר המשימות בו-זמנית בשדה Custom parallelism limit.
כשמסיימים להגדיר את המשימה, לוחצים על Update כדי לשנות את המשימה ב-Cloud Run ומחכים עד שהמשימה תיווצר.
כדי להריץ את המשימה, קראו את המאמר הרצת משימות או הרצת משימות לפי לוח זמנים.

gcloud

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

הפעלת Cloud Shell

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

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

gcloud run jobs update JOB

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

‫JOB: השם של המשימה ב-Cloud Run.

‫OPTIONS (אופציונלי): עם האפשרויות הבאות:

אפשרות	תיאור
`--tasks`	אפשר להזין מספרים שלמים ששווים ל-1 או גדולים ממנו. ברירת המחדל היא 1, והערך המקסימלי הוא 10,000. לכל משימה מוקצים משתני הסביבה `CLOUD_RUN_TASK_INDEX` עם ערך בין 0 למספר המשימות פחות 1, וגם `CLOUD_RUN_TASK_COUNT`, שהוא מספר המשימות.
`--max-retries`	מספר הפעמים שבהן המערכת מנסה להפעיל מחדש משימה שנכשלה. אם משימה כלשהי נכשלת מעבר למגבלה הזו, המשימה כולה מסומנת כנכשלה. לדוגמה, אם הערך הוא 1, המערכת תנסה להפעיל מחדש משימה שנכשלה פעם אחת, כך שיהיו שני ניסיונות בסך הכול. ערך ברירת המחדל הוא `3`. אפשר להזין מספרים שלמים מ-0 עד 10.
`--task-timeout`	אפשר להזין משך זמן כמו "2s". ברירת המחדל היא 10 דקות, והמקסימום הוא 168 שעות (7 ימים).
`--parallelism`	המספר המקסימלי של משימות שאפשר להריץ במקביל. כברירת מחדל, המשימות יתחילו כמה שיותר מהר, במקביל. בקטע מקביליות מפורט טווח הערכים.

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

הרשימה המלאה של האפשרויות שזמינות כשיוצרים משימה מופיעה במסמכי התיעוד של שורת הפקודה gcloud run jobs create.

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

Job [JOB] has been successfully updated.
View details about this job by running `gcloud run jobs describe JOB`.
See logs for this execution at: https://console.cloud.google.com/logs/viewer?project=PROJECT_ID&resource=cloud_run_revision/service_name/JOB

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

YAML

אם אתם צריכים להוריד או להציג את ההגדרות של משימה קיימת, הריצו את הפקודה הבאה כדי לשמור את התוצאות בקובץ YAML:
```
gcloud run jobs describe JOB --format export > job.yaml
```
משנים את מאפייני הצאצא של spec.template לפי הצורך, ואז פורסים מחדש באמצעות הפקודה הבאה:
```
gcloud run jobs replace job.yaml
```
כברירת מחדל, הפקודה gcloud run jobs replace משתמשת בקובץ job.yaml אם הוא קיים.
כדי להריץ את המשימה, קראו את המאמר הרצת משימות או הרצת משימות לפי לוח זמנים.

Terraform

משנים את הגדרות המשימה בקובץ main.tf באמצעות הפקודה terraform apply. הוראות מפורטות ל-Terraform זמינות עבור:

מידע נוסף זמין באפשרויות של שורת הפקודה terraform apply.

ספריות לקוח

כדי לעדכן משימה קיימת באמצעות קוד:

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

כדי לעדכן משימה, שולחים בקשת HTTP מסוג PATCH לנקודת הקצה (endpoint) של jobs ב-Cloud Run Admin API.

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

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

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

‫ACCESS_TOKEN: טוקן גישה תקין לחשבון עם הרשאות IAM לעדכון משימות. לדוגמה, אם אתם מחוברים ל-gcloud, אתם יכולים לאחזר אסימון גישה באמצעות gcloud auth print-access-token. מתוך מכונה של קונטיינר ב-Cloud Run, אתם יכולים לאחזר אסימון גישה באמצעות שרת המטא-נתונים של המכונה של הקונטיינר.
‫IMAGE_URL: הפניה לקובץ האימג' של הקונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/job:latest.
‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
‫REGION: האזור של המשימה, Google Cloud .
‫JOB: שם המשימה שרוצים לעדכן.

קוד לדוגמה

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

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

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

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

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

בדרך כלל משתמשים ב-sidecars בתרחישים הבאים:

אחזור מדדים בהתאמה אישית ממשימות Cloud Run ושליחה שלהם לקצה עורפי לבחירתכם באמצעות סוכני איסוף, כמו Prometheus או Opentelemetry.
לאפשר לאפליקציות בלי לוגיקה מובנית של Hashicorp Vault להשתמש בסודות סטטיים ודינמיים שמקורם ב-Vault באמצעות Vault sidecar.

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

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

המסוף

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

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

gcloud

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

הפעלת Cloud Shell

בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.
כדי לפרוס כמה קונטיינרים במשימה, מריצים את הפקודה הבאה:
```
gcloud run jobs create JOB \
 --container JOB_CONTAINER_NAME \
 --image='IMAGE_URL' \
 --container SIDECAR_CONTAINER_NAME \
 --image='SIDECAR_IMAGE'
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫JOB: השם של המשימה ב-Cloud Run.
- ‫JOB_CONTAINER_NAME: שם לקונטיינר הראשי של המשימה.
- ‫IMAGE_URL: הפניה לקובץ האימג' של הקונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/job:latest.
- ‫SIDECAR_CONTAINER_NAME: שם לקונטיינר המשני (sidecar), לדוגמה sidecar.
- ‫SIDECAR_IMAGE: הפניה לקובץ האימג' של הקונטיינר המשני.
כדי להגדיר כל קונטיינר בפקודת הפריסה, צריך לספק את ההגדרות של כל קונטיינר אחרי הפרמטרים של container, לדוגמה:
```
gcloud run jobs create JOB \
  --container CONTAINER_1_NAME \
  --image='IMAGE_URL' \
  --set-env-vars=KEY=VALUE \
  --container SIDECAR_CONTAINER_NAME \
  --image='SIDECAR_IMAGE' \
  --set-env-vars=KEY_N=VALUE_N
```
חשוב: כשמשתמשים בדגל --container, צריך לציין את כל הדגלים שהם לא ברמת הקונטיינר לפני הדגלים שהם ברמת הקונטיינר. אחרת, פקודת הפריסה תיכשל ותופיע הודעת שגיאה בהתאם.
מחכים עד שהפריסה של המשימות תסתיים. בסיום, תוצג הודעה שהפעולה בוצעה בהצלחה.

YAML

אם אתם יוצרים משימה חדשה, דלגו על השלב הזה. אם אתם מעדכנים משימה קיימת, הורידו את הגדרת ה-YAML שלה:
```
gcloud run jobs describe JOB --format export > job.yaml
```
מעדכנים את המאפיינים של containers::
```
apiVersion: run.googleapis.com/v1
kind: Job
metadata:
  name: JOB
spec:
  template:
    spec:
      containers:
      - image: IMAGE_URL
      - image: SIDECAR_IMAGE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫JOB: השם של המשימה ב-Cloud Run.
- ‫IMAGE_URL: הפניה לקובץ האימג' של הקונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/job:latest.
- ‫SIDECAR_IMAGE: הפניה לקובץ האימג' של הקונטיינר המשני.
יוצרים או מעדכנים את המשימה באמצעות הפקודה הבאה:
```
gcloud run jobs replace job.yaml
```
כברירת מחדל, הפקודה gcloud run jobs replace משתמשת בקובץ job.yaml אם הוא קיים.

Terraform

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

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

resource "google_cloud_run_v2_job" "default" {
  name     = "JOB"
  location = "europe-west1"

  template {
    template {
      containers {
        name = "CONTAINER_NAME"
        image = "IMAGE_URL"
      }
      containers {
        name = "SIDECAR_CONTAINER_NAME"
        image = "SIDECAR_IMAGE_URL"
      }
    }
  }
}

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

‫JOB: השם של המשימה ב-Cloud Run.
‫CONTAINER_NAME: שם הקונטיינר.
‫IMAGE_URL: הפניה לקובץ האימג' של הקונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/job:latest.
‫SIDECAR_CONTAINER_NAME: השם של הקונטיינר המשני (sidecar).
‫SIDECAR_IMAGE_URL: הפניה לקובץ האימג' של הקונטיינר המשני.

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

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

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

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

מגבלות

אם המשימה מתחברת למכונות של Cloud SQL באמצעות התכונה המובנית של Cloud Run, עיינו בבעיה המוכרת בנושא חיבורים מובנים של Cloud SQL.

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

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

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

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

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

יצירת משימה חדשה

המסוף

gcloud

YAML

Terraform

ספריות לקוח

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

מיקומים של Cloud Run

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

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

עדכון משרה קיימת

המסוף

gcloud

YAML

Terraform

ספריות לקוח

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

קוד לדוגמה

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

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

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

המסוף

gcloud

YAML

Terraform

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

מגבלות

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

יצירת משרות