יצירת משרות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מומלץ להשתמש ב-Docker Hub רק לפריסת קובצי אימג' פופולריים של קונטיינרים, כמו Docker Official Images או Docker Sponsored OSS images. כדי להגדיל את הזמינות, Google ממליצה לפרוס את התמונות האלה מ-Docker Hub באמצעות מאגר מרוחק של Artifact Registry.

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

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

אפשר ליצור עבודה חדשה באמצעות מסוף Google Cloud ,‏ Google Cloud CLI,‏ YAML או Terraform.

המסוף

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

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

כניסה ל-Cloud Run
בתפריט הניווט של Cloud Run, בוחרים באפשרות Jobs (משימות) ולוחצים על Deploy container (פריסת קונטיינר) כדי להציג את הטופס Create job (יצירת משימה).
1. בטופס, מציינים את קובץ אימג' של קונטיינר שמכיל את קוד המשימה או בוחרים מתוך רשימת קונטיינרים שנפרסו בעבר.
2. שם המשימה נוצר אוטומטית מקובץ אימג' של קונטיינר. אפשר לערוך או לשנות את שם המשרה לפי הצורך. אי אפשר לשנות את שם המשרה אחרי שיוצרים אותה.
3. בוחרים את האזור שבו רוצים שהמשרה תהיה ממוקמת. בכלי לבחירת אזור, האזורים עם השלכות פליטת הפחמן הכי נמוכות מסומנים.
4. מציינים את מספר המשימות שרוצים להפעיל בעבודה. כדי שהעבודה תצליח, כל המשימות צריכות להצליח. כברירת מחדל, המשימות מבוצעות במקביל.
לוחצים על Container(s), Volumes, Networking, Security כדי להגדיר מאפיינים נוספים של העבודה.
- בקטע 'קיבולת משימות':
1. בתפריט זיכרון, מציינים את כמות הזיכרון הנדרשת. ברירת המחדל היא המינימום הנדרש, 512MiB.
2. בתפריט CPU, מציינים את כמות המעבד הנדרשת. ברירת המחדל היא המינימום הנדרש, מעבד אחד.
3. בקטע Task timeout (פסק זמן של המשימה), מציינים את משך הזמן המקסימלי בשניות שהמשימה יכולה לפעול, עד 168 שעות (7 ימים). למשימות שמשתמשות במעבדי GPU, הזמן הקצוב לתפוגה המקסימלי הוא שעה אחת. כל משימה חייבת להסתיים תוך הזמן הזה. ברירת המחדל היא 10 דקות.
4. בקטע Number of retries per failed task (מספר הניסיונות החוזרים לכל משימה שנכשלה), מציינים את מספר הניסיונות החוזרים במקרה של כשלים במשימות. ברירת המחדל היא 3 ניסיונות חוזרים.
- בקטע Parallelism (מקביליות):
  1. ברוב המקרים אפשר לבחור באפשרות הפעלת כמה שיותר משימות בו-זמנית.
  2. אם אתם צריכים להגדיר מגבלה נמוכה יותר בגלל מגבלות על הרחבת המשאבים שהעבודה שלכם ניגשת אליהם, אתם צריכים לבחור באפשרות הגבלת המספר המקסימלי של משימות מקבילות ולהזין את מספר המשימות המקבילות בשדה מגבלת מקביליות בהתאמה אישית.
אופציונלי: מגדירים הגדרות אחרות בכרטיסיות המתאימות:
כשמסיימים להגדיר את העבודה, לוחצים על יצירה כדי ליצור את העבודה ב-Cloud Run.
כדי להריץ את העבודה, אפשר לעיין במאמר בנושא הרצת עבודות או הרצת עבודות לפי לוח זמנים.

gcloud

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

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

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

gcloud run jobs create JOB_NAME --image IMAGE_URL OPTIONS

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

gcloud run jobs deploy JOB_NAME --image IMAGE_URL OPTIONS

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

‫JOB_NAME: השם של המשימה שרוצים ליצור. אם לא מציינים את הפרמטר הזה, תתבקשו להזין את שם העבודה כשמריצים את הפקודה.
‫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, פרק הזמן המקסימלי שזמין לתפוגה הוא שעה אחת.
`--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. שמות המשימות צריכים להיות באורך של 49 תווים או פחות, והם צריכים להיות ייחודיים לכל אזור ופרויקט.
- ‫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 לנקודת הקצה 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_NAME

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

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

מיקומים של Cloud Run

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

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

‫Cloud Run זמין באזורים הבאים:

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

asia-east1 (טייוואן)
asia-northeast1 (טוקיו)
‫asia-northeast2 (אוסקה)
asia-south1 (מומבאי, הודו)
‫asia-southeast3 (בנגקוק)
europe-north1 (פינלנד) רמה נמוכה של CO₂
europe-north2 (שטוקהולם) רמה נמוכה של CO₂
europe-southwest1 (מדריד) רמה נמוכה של CO₂
europe-west1 (בלגיה) רמה נמוכה של CO₂
europe-west4 (הולנד) רמה נמוכה של CO₂
europe-west8 (מילאנו)
europe-west9 (פריז) רמה נמוכה של CO₂
me-west1 (תל אביב)
northamerica-south1 (מקסיקו)
us-central1 (אייווה) רמה נמוכה של CO₂
us-east1 (קרוליינה הדרומית)
‫us-east4 (צפון וירג'יניה)
us-east5 (Columbus)
us-south1 (דאלאס) רמה נמוכה של CO₂
‫us-west1 (אורגון) רמה נמוכה של CO₂

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

africa-south1 (יוהנסבורג)
asia-east2 (הונג קונג)
asia-northeast3 (סיאול, קוריאה הדרומית)
asia-southeast1 (סינגפור)
asia-southeast2 (ג'קרטה)
asia-south2 (דלהי, הודו)
australia-southeast1 (סידני)
australia-southeast2 (מלבורן)
europe-central2 (ורשה, פולין)
‫europe-west10 (ברלין)
europe-west12 (טורינו)
europe-west2 (לונדון, בריטניה) רמה נמוכה של CO₂
‫europe-west3 (פרנקפורט, גרמניה)
europe-west6 (ציריך, שווייץ) רמה נמוכה של CO₂
‫me-central1 (דוחה)
me-central2 (דמאם)
northamerica-northeast1 (מונטריאול) רמה נמוכה של CO₂
northamerica-northeast2 (טורונטו) רמה נמוכה של CO₂
southamerica-east1 (סאו פאולו, ברזיל) רמה נמוכה של CO₂
southamerica-west1 (סנטיאגו, צ'ילה) רמה נמוכה של CO₂
‫us-west2 (לוס אנג'לס)
‫us-west3 (סולט לייק סיטי)
‫us-west4 (לאס וגאס)

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

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

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

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

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

המסוף

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

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

כניסה ל-Cloud Run
בתפריט הניווט של Cloud Run, לוחצים על Jobs (משימות) כדי להציג את רשימת המשימות.
לוחצים על המשרה כדי להציג את הדף פרטי המשרה.
לוחצים על Edit.
אם ביצעתם שינויים בקוד של המשימה, צריך לציין את התקציר של תמונת מאגר התגים החדש.
אם רוצים, משנים את מספר המשימות בעבודה.
אופציונלי, לוחצים על Container(s), Volumes, Networking, Security כדי לעדכן מאפיינים נוספים של העבודה:
- בקטע 'קיבולת משימות':
1. בתפריט זיכרון, מציינים את כמות הזיכרון הנדרשת. ברירת המחדל היא המינימום הנדרש, 512MiB.
2. בתפריט CPU, מציינים את כמות המעבד הנדרשת. ברירת המחדל היא המינימום הנדרש, מעבד אחד.
3. בקטע Task timeout (פסק זמן של המשימה), מציינים את משך הזמן המקסימלי בשניות שהמשימה יכולה לפעול, עד 168 שעות (7 ימים). כל משימה צריכה להסתיים בתוך פרק הזמן הזה. ברירת המחדל היא 10 דקות (600 שניות).
4. בקטע Number of retries per failed task (מספר הניסיונות החוזרים לכל משימה שנכשלה), מציינים את מספר הניסיונות החוזרים במקרה של כשלים במשימות. ברירת המחדל היא 3 ניסיונות חוזרים.
- בקטע Parallelism (מקביליות):
  1. ברוב המקרים אפשר לבחור באפשרות הפעלת כמה שיותר משימות בו-זמנית.
  2. אם אתם צריכים להגדיר מגבלה נמוכה יותר בגלל מגבלות על הרחבת המשאבים שהעבודה שלכם ניגשת אליהם, אתם צריכים לבחור באפשרות הגבלת מספר המשימות המקבילות ולהזין את המספר המקסימלי של משימות מקבילות בשדה מגבלת מקביליות מותאמת אישית.
אופציונלי: מגדירים הגדרות אחרות בכרטיסיות המתאימות:
כשמסיימים להגדיר את העבודה, לוחצים על Save כדי ליצור את העבודה ב-Cloud Run ומחכים עד שהיצירה תסתיים.
כדי להריץ את העבודה, אפשר לעיין במאמר בנושא הרצת עבודות או הרצת עבודות לפי לוח זמנים.

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

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

gcloud run jobs update JOB_NAME

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

‫JOB_NAME: השם של המשימה שרוצים לעדכן.

אפשר להחליף את 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_NAME] has been successfully updated.
View details about this job by running `gcloud run jobs describe JOB_NAME`.
See logs for this execution at: https://console.cloud.google.com/logs/viewer?project=PROJECT_ID&resource=cloud_run_revision/service_name/JOB_NAME

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

YAML

אם אתם צריכים להוריד או לראות את ההגדרות של משימה קיימת, אתם יכולים להשתמש בפקודה הבאה כדי לשמור את התוצאות בקובץ YAML:

gcloud run jobs describe JOB --format export > job.yaml

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

מעדכנים את ההגדרה הקיימת של העבודה:
```
gcloud run jobs replace job.yaml
```
כדי להריץ את העבודה, אפשר לעיין במאמר בנושא הרצת עבודות או הרצת עבודות לפי לוח זמנים.

Terraform

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

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

ספריות לקוח

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

API ל-REST

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

לדוגמה, שימוש ב-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_NAME

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

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

קוד לדוגמה

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
כדי לפרוס כמה מאגרי תגים לעבודה, מריצים את הפקודה הבאה:
```
gcloud run jobs create JOB \
 --container JOB_CONTAINER_NAME \
 --image='IMAGE_URL' \
 --container SIDECAR_CONTAINER_NAME \
 --image='SIDECAR_IMAGE'
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫JOB: שם המשימה שרוצים לפרוס. אפשר להשמיט את הפרמטר הזה לגמרי, אבל אם תשמיטו אותו, תתבקשו להזין את שם המשרה.
- ‫JOB_CONTAINER_NAME: שם של קונטיינר המשימה הראשי.
- ‫IMAGE_URL: הפניה לקובץ אימג' של קונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/job:latest.
- ‫SIDECAR_CONTAINER_NAME: שם של קונטיינר ה-sidecar, לדוגמה sidecar.
- ‫SIDECAR_IMAGE: הפניה לקובץ אימג' של קונטיינר sidecar.
אם רוצים להגדיר כל מאגר תגים בפקודת הפריסה, צריך לספק את ההגדרה של כל מאגר תגים אחרי הפרמטרים 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 בסיסי לעבודת Cloud Run עם sidecars. יוצרים קובץ בשם job.yaml עם התוכן הבא:

apiVersion: run.googleapis.com/v1
kind: Job
metadata:
  name: JOB
spec:
  template:
    spec:
      containers:
      - image: IMAGE_URL
      - image: SIDECAR_IMAGE

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

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

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

gcloud run jobs replace job.yaml

Terraform

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

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

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

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

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

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

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

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

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

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

מגבלות

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

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

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

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

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

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

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

המסוף

gcloud

YAML

Terraform

ספריות לקוח

API ל-REST

מיקומים של Cloud Run

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

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

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

המסוף

gcloud

YAML

Terraform

ספריות לקוח

API ל-REST

קוד לדוגמה

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

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

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

המסוף

gcloud

YAML

Terraform

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

מגבלות

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

יצירת משרות