הוספת ביצועים של תהליכי עבודה לתור באמצעות Cloud Tasks

אתם יכולים להשתמש ב-Cloud Tasks כדי להוסיף תהליך עבודה לתור ולהפעיל אותו באופן אסינכרוני.

שירות Cloud Tasks כולל את אמצעי הבקרה הבאים:

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

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

מידע נוסף זמין במאמר הסבר על Cloud Tasks.

שימו לב לנקודות הבאות:

  • כדאי לבסס את הגבלת הקצב על המגבלה של Workflows עבור בקשות כתיבה ב-Execution API. אם צריך, אפשר לבקש לשנות את רוב המכסות במסוף Google Cloud . מידע נוסף על התאמות של מכסת השימוש

  • שירות Cloud Tasks נועד לספק מסירה של 'לפחות פעם אחת', אבל Workflows לא מבטיח עיבוד של בקשות כפולות מ-Cloud Tasks בדיוק פעם אחת.

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

לפני שמתחילים

  1. אם עדיין אין לכם תהליך עבודה שאתם רוצים להוסיף לתור, אתם יכולים ליצור תהליך עבודה.

  2. מפעילים את Cloud Tasks API, אם הוא עדיין לא מופעל.

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    להפעלת ה-API

הוספת משימה לתור לביצוע תהליך עבודה

  1. יוצרים חשבון שירות כדי ש-Cloud Tasks יוכל לשלוח בקשות אל Workflows API:

    gcloud iam service-accounts create SERVICE_ACCOUNT_NAME

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

  2. כדי לאפשר לחשבון המשתמש שיריץ את הפקודות של Cloud Tasks לפעול כחשבון שירות לניהול זהויות והרשאות גישה (IAM), צריך להקצות תפקיד שמאפשר לחשבון המשתמש להתחזות לחשבון השירות.

  3. נותנים לחשבון השירות החדש את התפקיד workflows.invoker כדי שלחשבון תהיה הרשאה להפעיל את תהליך העבודה:

    gcloud projects add-iam-policy-binding PROJECT_NAME \
    --member serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com \
    --role roles/workflows.invoker

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

    • ‫PROJECT_NAME: השם של Google Cloud הפרויקט.
    • ‫SERVICE_ACCOUNT_NAME: השם של חשבון השירות שיצרתם קודם.

  4. אם עדיין אין לכם תור של Cloud Tasks, צרו תור.

  5. יוצרים משימה שמכוונת לנקודת הקצה של ה-HTTP של זרימת העבודה, באמצעות חשבון השירות שיצרתם קודם לאימות:

    gcloud tasks create-http-task \
    --queue="QUEUE_ID" \
    --url="https://workflowexecutions.googleapis.com/v1/projects/PROJECT_NAME/locations/REGION_NAME/workflows/WORKFLOW_NAME/executions" \
    --body-content="{\"argument\": \"DOUBLE_ESCAPED_JSON_STRING\"}" \
    --oauth-service-account-email="SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com"

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

    • ‫QUEUE_ID: המזהה שהקציתם לתור של Cloud Tasks. לדוגמה: my-queue.
    • ‫PROJECT_NAME: השם של Google Cloudהפרויקט.
    • ‫REGION_NAME: האזור שבו נמצא תהליך העבודה, למשל us-central1.
    • ‫WORKFLOW_NAME: השם של תהליך העבודה שרוצים ליצור לו משימה.
    • ‫DOUBLE_ESCAPED_JSON_STRING: קידוד JSON של הארגומנטים שמעבירים. המירכאות הכפולות בתוך המחרוזת המצוטטת מסומנות בתו בריחה באמצעות לוכסנים הפוכים (\). לדוגמה: --body-content="{\"argument\": \"{\\\"foo\\\": \\\"bar\\\"}\"}"
    • ‫SERVICE_ACCOUNT_NAME: השם של חשבון השירות שיצרתם קודם.

    המשימה נוצרת ונוספת לתור של Cloud Tasks. המשימה נשארת בתור עד שהביצוע של תהליך העבודה מתחיל ומוחזר קוד סטטוס 2xx של HTTP. בשלב הזה, Cloud Tasks מחשיב את המשימה כהושלמה.

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