יצירת משרות

בדף הזה מוסבר איך ליצור ולעדכן משימות של 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 הבאים:

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

מאגרי Container Registry ותמונות נתמכים

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

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

כדאי להשתמש ב-Docker Hub רק לפריסת קובצי אימג' פופולריים של קונטיינרים, כמו קובצי אימג' רשמיים של Docker או קובצי אימג' של תוכנת קוד פתוח (OSS) בחסות Docker. כדי להשיג זמינות גבוהה יותר, Google ממליצה לפרוס את התמונות האלה מ-Docker Hub או מ-GitHub Container Registry באמצעות מאגר מרוחק של Artifact Registry.

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

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

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

המסוף

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

  1. במסוף Cloud de Confiance , נכנסים לדף Cloud Run jobs:

    כניסה לדף Cloud Run jobs

  2. לוחצים על Deploy container כדי להציג את הטופס Create job.

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

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

  5. בשדה Region, משתמשים בערך ברירת המחדל.

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

  7. לוחצים על Containers, Networking, Security כדי להגדיר מאפיינים נוספים של המשימה.

  8. בקטע Edit container (עריכת מאגר התגים), אפשר להגדיר את ההגדרות הבאות בכרטיסיות המתאימות:

  9. בקטע Task capacity (קיבולת המשימות), מציינים את הפרטים הבאים:

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

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

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

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

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

gcloud

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

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

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

    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.

  2. מחכים עד שיצירת העבודה תסתיים. בסיום התהליך תופיע הודעת אישור.

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

YAML

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

  1. יוצרים קובץ job.yaml חדש עם התוכן הזה:

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

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

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

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

    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

כדי ליצור משימה, שולחים POST בקשת HTTP אל נקודת הקצה (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

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

מיקומי Cloud Run

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

  1. במסוף Cloud de Confiance , נכנסים לדף Cloud Run jobs:

    כניסה לדף Cloud Run jobs

  2. לוחצים על המשרה כדי להציג את הדף פרטי המשרה.

  3. לוחצים על הצגה ועריכה של הגדרות המשימה.

  4. אופציונלי: משנים את מספר המשימות במשימה לפי הצורך.

  5. אופציונלי: לוחצים על Containers, Networking, Security כדי לעדכן מאפיינים נוספים של המשימה:

  6. בקטע Task capacity (קיבולת המשימות), מציינים את הפרטים הבאים:

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

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

  7. בקטע Parallelism, בוחרים באפשרות Run as many tasks concurrently as possible אם צריך להגדיר מגבלה נמוכה יותר בגלל אילוצי התאמה לעומס (scaling) במשאבים שאליהם המשימה ניגשת, או בוחרים באפשרות Limit the maximum number of concurrent tasks ומציינים את מספר המשימות בו-זמנית בשדה Custom parallelism limit.

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

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

gcloud

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

    הפעלת Cloud Shell

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

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

    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.

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

    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.s3nscloud.fr/logs/viewer?project=PROJECT_ID&resource=cloud_run_revision/service_name/JOB
  4. כדי להריץ את העבודה, אפשר לעיין במאמרים בנושא הרצת עבודות או הרצת עבודות לפי לוח זמנים.

YAML

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

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

    gcloud run jobs replace job.yaml

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

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

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: מזהה הפרויקט ב- Cloud de Confiance .
  • ‫REGION: Cloud de Confiance האזור של המשימה.
  • ‫JOB: השם של המשימה שרוצים לעדכן.

קוד לדוגמה

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

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

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

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

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

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

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

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

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

המסוף

  1. במסוף Cloud de Confiance , נכנסים לדף Cloud Run jobs:

    כניסה לדף Cloud Run jobs

  2. כדי לפרוס למשרה קיימת, לוחצים על משרות. מאתרים את המשימה ברשימת המשימות ולוחצים עליה כדי לפתוח אותה. לאחר מכן לוחצים על View and edit configuration (הצגה ועריכה של ההגדרות) כדי להציג את הטופס לעריכת המשימה.

  3. כדי ליצור משימה חדשה, לוחצים על Deploy container (פריסת קונטיינר). צריך לספק את כתובת ה-URL של קובץ אימג' של קונטיינר ואת שם הג'וב.

  4. לוחצים על Containers, Networking, Security.

  5. בכרטיס Edit container (עריכת מאגר), מגדירים את מאגר המשימות הראשי לפי הצורך.

  6. לוחצים על Add container (הוספת מאגר תגים) ומגדירים מאגר תגים מסוג sidecar שרוצים להוסיף לצד מאגר התגים הראשי של המשימה. אם ה-sidecar תלוי בקונטיינר אחר בשירות, מציינים זאת בתפריט הנפתח Container start-up order. חוזרים על השלב הזה לכל קובץ sidecar שפורסים.

  7. לוחצים על Create לשירות חדש או על Update למשימה קיימת, וממתינים לסיום הפריסה.

gcloud

  1. מפעילים את Cloud Shell במסוף Cloud de Confiance .

    הפעלת Cloud Shell

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

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

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

YAML

  1. אם אתם יוצרים משרה חדשה, דלגו על השלב הזה. אם אתם מעדכנים משימה קיימת, אתם צריכים להוריד את הגדרת ה-YAML שלה:

    gcloud run jobs describe JOB --format export > job.yaml
  2. מעדכנים את המאפיינים 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.
  3. יוצרים או מעדכנים את המשימה באמצעות הפקודה הבאה:

    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.

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

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