Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

יצירת משרות

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

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

מומלץ להשתמש ב-Docker Hub רק לפריסת קובצי אימג' פופולריים של קונטיינרים, כמו Docker Official Images או Docker Sponsored OSS images. כדי להשיג זמינות גבוהה יותר, Google ממליצה לפרוס את התמונות האלה מ-Docker Hub או מ-GitHub Container Registry באמצעות מאגר מרוחק של 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. בשדה Region, בוחרים את האזור שבו רוצים למקם את העבודה. האזורים שמסומנים בבורר האזורים הם אלה שבהם ההשפעה על פליטת הפחמן היא הנמוכה ביותר.
4. מציינים את מספר המשימות שרוצים להפעיל בעבודה. כדי שהעבודה תצליח, כל המשימות צריכות להצליח. כברירת מחדל, המשימות מבוצעות במקביל.
לוחצים על Containers, Networking, Security כדי להגדיר מאפיינים נוספים של העבודה.
בקטע Edit container (עריכת מאגר תגים), אפשר להגדיר את ההגדרות הבאות בכרטיסיות המתאימות:
בקטע קיבולת המשימות:
1. בקטע Task timeout (פסק זמן של משימה), מציינים את משך הזמן המקסימלי בשניות שהמשימה יכולה לפעול, עד 168 שעות (7 ימים). למשימות שמשתמשות במעבדי GPU, הזמן הקצוב לתפוגה המקסימלי הוא שעה אחת. כל משימה חייבת להסתיים תוך פרק הזמן הזה. ברירת המחדל היא 10 דקות.
2. בקטע מספר הניסיונות החוזרים לכל משימה שנכשלה, מציינים את מספר הניסיונות החוזרים במקרה של כשלים במשימות. ברירת המחדל היא 3 ניסיונות חוזרים.
בקטע מקביליות:
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 ואז לפרוס אותו באמצעות gcloud CLI.

יוצרים קובץ 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
```
אם קיים קובץ job.yaml, הפקודה gcloud run jobs replace משתמשת בו כברירת מחדל.

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 אל נקודת הקצה (endpoint) של Cloud Run Admin API‏ jobs.POST

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

‫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.
אם ביצעתם שינויים בקוד של המשימה, צריך לציין את תקציר התמונה של מאגר התגים החדש.
אם רוצים, משנים את מספר המשימות בעבודה.
אופציונלית, לוחצים על Containers, Networking, Security כדי לעדכן מאפיינים נוספים של המשימה:
בקטע קיבולת המשימות:
1. בקטע Task timeout (פסק זמן של משימה), מציינים את משך הזמן המקסימלי בשניות שהמשימה יכולה לפעול, עד 168 שעות (7 ימים). כל משימה צריכה להסתיים בתוך פרק הזמן הזה. ברירת המחדל היא 10 דקות (600 שניות).
2. בקטע מספר הניסיונות החוזרים לכל משימה שנכשלה, מציינים את מספר הניסיונות החוזרים במקרה של כשלים במשימות. ברירת המחדל היא 3 ניסיונות חוזרים.
בקטע מקביליות:
1. ברוב המקרים אפשר לבחור באפשרות הפעלת כמה שיותר משימות בו-זמנית.
2. אם אתם צריכים להגדיר מגבלה נמוכה יותר בגלל מגבלות על שינוי הגודל של המשאבים שהעבודה ניגשת אליהם, אתם יכולים לבחור באפשרות הגבלת מספר המשימות המקבילות ולהזין את המספר המקסימלי של משימות מקבילות בשדה מגבלת מקבילות מותאמת אישית.
כשמסיימים להגדיר את העבודה, לוחצים על Update כדי לשנות את העבודה ב-Cloud Run ומחכים עד ליצירת העבודה.
כדי להריץ את העבודה, אפשר לעיין במאמרים בנושא הרצת עבודות או הרצת עבודות לפי לוח זמנים.

gcloud

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

הפעלת Cloud Shell

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

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

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
```
אם קיים קובץ job.yaml, הפקודה gcloud run jobs replace משתמשת בו כברירת מחדל.
כדי להריץ את העבודה, אפשר לעיין במאמרים בנושא הרצת עבודות או הרצת עבודות לפי לוח זמנים.

Terraform

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

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

ספריות לקוח

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

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

כדי לעדכן עבודה, שולחים בקשת HTTP לנקודת הקצה של Cloud Run Admin API jobs.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 לעבודת Cloud Run באמצעותGoogle Cloud המסוף, Google Cloud CLI או YAML.

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

המסוף

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

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

gcloud

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

הפעלת 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: שם המשימה שרוצים לפרוס. אפשר להשמיט את הפרמטר הזה לגמרי, אבל אם תשמיטו אותו תתבקשו להזין את שם המשרה.
- ‫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

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

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.

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

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

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

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

פריסת משימה עם קונטיינרים של קובץ עזר

המסוף

gcloud

YAML

Terraform

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

מגבלות

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

יצירת משרות