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

יצירת משרות

בדף הזה מוסבר איך ליצור ולעדכן משימות של 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) במשימה ב-Cloud Run
משתמש בחשבון שירות (roles/iam.serviceAccountUser) בזהות השירות
‫Artifact Registry Reader (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 , ה-CLI של gcloud,‏ YAML,‏ Terraform, ספריות לקוח או API בארכיטקטורת REST:

המסוף

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

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

כניסה לדף Cloud Run jobs
לוחצים על Deploy container (פריסת מאגר תגים) כדי להציג את הטופס Create job (יצירת משימה).
בטופס, מציינים את קובץ האימג' של הקונטיינר שמכיל את קוד המשימה או בוחרים מתוך רשימת קונטיינרים שנפרסו בעבר.
שם המשימה נוצר אוטומטית מקובץ האימג' בקונטיינר. אפשר לערוך את שם המשרה לפי הצורך בטופס. אחרי ששולחים את הטופס, אי אפשר לערוך את שם המשרה.
בשדה Region (אזור), בוחרים את האזור של העבודה. בורר האזורים מסמן אזורים עם ההשפעה הכי נמוכה על פליטת הפחמן.
מציינים את מספר המשימות שיופעלו בעבודה. כדי שהעבודה תצליח, כל המשימות צריכות להצליח. כברירת מחדל, המשימות מבוצעות במקביל.
לוחצים על Containers, Networking, Security כדי להגדיר מאפיינים נוספים של העבודה.
בקטע Edit container (עריכת מאגר תגים), אפשר להגדיר את ההגדרות הבאות בכרטיסיות המתאימות:
בקטע Task capacity מציינים את הפרטים הבאים:
1. בשדה Task timeout (זמן קצוב לתפוגת משימה), מציינים את משך הזמן המקסימלי בשניות שהמשימה יכולה לפעול, עד 168 שעות (7 ימים). למשימות שמשתמשות במעבדי GPU, הזמן הקצוב לתפוגה המקסימלי הוא שעה אחת. כל משימה חייבת להסתיים תוך פרק הזמן הזה. ברירת המחדל היא 10 דקות.
2. בשדה Number of retries per failed task (מספר הניסיונות החוזרים לכל משימה שנכשלה), מציינים את מספר הניסיונות החוזרים במקרה של כשלים במשימות. ברירת המחדל היא 3 ניסיונות חוזרים.
בקטע מקביליות, בוחרים באפשרות הפעלת כמה שיותר משימות בו-זמנית אם צריך להגדיר מגבלה נמוכה יותר בגלל מגבלות על שינוי הגודל של המשאבים שהגישה אליהם מוגדרת בעבודת ה-ETL, או בוחרים באפשרות הגבלת המספר המקסימלי של משימות בו-זמנית ומציינים את מספר המשימות בו-זמנית בשדה מגבלת מקביליות מותאמת אישית.
כשמסיימים להגדיר את העבודה, לוחצים על 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, הזמן הקצוב לתפוגה המקסימלי הוא שעה אחת.
`--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) של Cloud Run Admin API‏ jobs.

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

כניסה לדף Cloud Run jobs
לוחצים על המשרה כדי להציג את הדף פרטי המשרה.
לוחצים על הצגה ועריכה של הגדרות העבודה.
אופציונלי: משנים את מספר המשימות בעבודה לפי הצורך.
אופציונלי: לוחצים על Containers, Networking, Security (מאגרי נתונים, רשתות, אבטחה) כדי לעדכן מאפיינים נוספים של העבודה:
בקטע Task capacity (קיבולת המשימות), מציינים את הפרטים הבאים:
1. בשדה Task timeout (זמן קצוב לתפוגת משימה), מציינים את משך הזמן המקסימלי בשניות שהמשימה יכולה לפעול, עד 168 שעות (7 ימים). למשימות שמשתמשות במעבדי GPU, הזמן הקצוב לתפוגה המקסימלי הוא שעה אחת. כל משימה חייבת להסתיים תוך פרק הזמן הזה. ברירת המחדל היא 10 דקות.
2. בשדה Number of retries per failed task (מספר הניסיונות החוזרים לכל משימה שנכשלה), מציינים את מספר הניסיונות החוזרים במקרה של כשלים במשימות. ברירת המחדל היא 3 ניסיונות חוזרים.
בקטע מקביליות, בוחרים באפשרות הפעלת כמה שיותר משימות בו-זמנית אם צריך להגדיר מגבלה נמוכה יותר בגלל מגבלות על שינוי הגודל של המשאבים שהגישה אליהם מוגדרת בעבודת ה-ETL, או בוחרים באפשרות הגבלת המספר המקסימלי של משימות בו-זמנית ומציינים את מספר המשימות בו-זמנית בשדה מגבלת מקביליות מותאמת אישית.
כשמסיימים להגדיר את העבודה, לוחצים על Update כדי לשנות את העבודה ב-Cloud Run ומחכים עד ליצירת העבודה.
כדי להריץ את העבודה, אפשר לעיין במאמרים בנושא הרצת עבודות או הרצת עבודות לפי לוח זמנים.

gcloud

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

הפעלת Cloud Shell

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

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

gcloud run jobs update JOB

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

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

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

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

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

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

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

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

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

שימוש נפוץ ב-Sidecars נעשה בתרחישים הבאים:

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

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

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

המסוף

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

כניסה לדף Cloud Run jobs
כדי לפרוס למשרה קיימת, לוחצים על משרות. מאתרים את המשרה ברשימת המשרות ולוחצים עליה כדי לפתוח אותה. לאחר מכן לוחצים על View and edit configuration (הצגה ועריכה של ההגדרות) כדי להציג את הטופס לעריכת המשימה.
כדי ליצור משימה חדשה, לוחצים על Deploy container (פריסת קונטיינר). מזינים את כתובת ה-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: השם של המשימה ב-Cloud Run.
- ‫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 שלה:
```
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: הפניה לקובץ אימג' של קונטיינר sidecar.
יוצרים או מעדכנים את העבודה באמצעות הפקודה הבאה:
```
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"
  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.

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

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

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

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

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

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

המסוף

gcloud

YAML

Terraform

ספריות לקוח

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

מיקומי Cloud Run

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

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

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

המסוף

gcloud

YAML

Terraform

ספריות לקוח

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

קוד לדוגמה

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

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

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

המסוף

gcloud

YAML

Terraform

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

מגבלות

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

יצירת משרות