העברת אירועים מ-Cloud Storage ל-Workflows

רגילה

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

האירועים מועברים בפורמט CloudEvents באמצעות בקשת HTTP. שירות Workflows ממיר את האירוע לאובייקט JSON (בהתאם למפרט CloudEvents) ומעביר את האירוע להרצת זרימת העבודה כארגומנט של זמן הריצה של זרימת העבודה. צריך לוודא שגודל האירוע לא חורג ממגבלת המשאבים. אירועים שגדולים מהגודל המקסימלי של ארגומנטים ב-Workflows לא יפעילו את הביצוע של תהליך העבודה.

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

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

הכנות ליצירת טריגר

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

המסוף

1. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.

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

   כניסה לדף לבחירת הפרויקט

2. מפעילים את ממשקי ה-API‏ Eventarc,‏ Eventarc Publishing,‏ Workflows ו-Workflow Executions.

   הפעלת ממשקי ה-API

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

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

   1. נכנסים לדף Service Accounts במסוף Google Cloud .

      לדף Service accounts

   2. בוחרים את הפרויקט הרצוי.

   3. כותבים שם בשדה Service account name. השדה Service account ID ימולא במסוף Google Cloud בהתאם לשם הזה.

      כותבים תיאור בשדה Service account description. לדוגמה, Service account for event trigger.

   4. לוחצים על Create and continue.

   5. כדי לספק גישה מתאימה, ברשימה Select a role בוחרים את תפקידי ניהול הזהויות והגישה (IAM) שרוצים להקצות לחשבון השירות. מידע נוסף זמין במאמר תפקידים והרשאות ליעדים של כלי Workflows.

      כדי להוסיף עוד תפקידים, לוחצים על Add another role ומוסיפים אותם אחד אחרי השני.

   6. לוחצים על Continue.

   7. כדי לסיים את יצירת החשבון, לוחצים על סיום.

5. נותנים לסוכן השירות של Cloud Storage את התפקיד 'פרסום הודעות ב-Pub/Sub'. בדרך כלל זה הנתיב [e-mail]. אפשר לאחזר את כתובת האימייל של סוכן השירות של Cloud Storage.

   1. נכנסים לדף IAM במסוף Google Cloud .

      כניסה לדף IAM

   2. בשורה של סוכן השירות של Cloud Storage, לוחצים על Edit principal. (אם סוכן השירות לא מופיע ברשימה, עוברים לשלב הבא). נפתחת החלונית עריכת הגישה.

      1. לוחצים על Add another role ואז מחפשים את התפקיד Pub/Sub Publisher.
      2. בוחרים את התפקיד.
      3. לוחצים על Save.

   3. אם סוכן השירות לא מופיע ברשימה, לוחצים על Grant access (מתן גישה). נפתחת החלונית הענקת גישה.

      1. בשדה New principals, מזינים את כתובת האימייל של סוכן השירות.
      2. ברשימה Select a role, מחפשים את התפקיד Pub/Sub Publisher.
      3. בוחרים את התפקיד.
      4. לוחצים על שמירה.

gcloud

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

   הפעלת Cloud Shell

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

2. מפעילים את ממשקי ה-API‏ Eventarc,‏ Eventarc Publishing,‏ Workflows ו-Workflow Executions:

   gcloud services enable eventarc.googleapis.com \
       eventarcpublishing.googleapis.com \
       workflows.googleapis.com \
       workflowexecutions.googleapis.com

3. אם רלוונטי, מפעילים את ממשק ה-API שקשור לאירועים הישירים. לדוגמה, כדי להפעיל את האפשרות storage.googleapis.com לאירועים, צריך להזין את הערך Cloud Storage events.

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

   1. יוצרים את חשבון השירות:

      gcloud iam service-accounts create SERVICE_ACCOUNT_NAME

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

   2. מעניקים את התפקידים או ההרשאות הנדרשים לניהול זהויות והרשאות גישה (IAM). למידע נוסף, אפשר לעיין במאמר בנושא תפקידים והרשאות ליעדים של Workflows.

5. אם אתם יוצרים טריגר לאירוע ישיר של Cloud Storage, צריך להעניק את התפקיד pubsub.publisher לחשבון השירות של Cloud Storage:

   SERVICE_ACCOUNT="$(gcloud storage service-agent --project=PROJECT_ID)"
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member="serviceAccount:${SERVICE_ACCOUNT}" \
       --role="roles/pubsub.publisher"
   

יצירת טריגר

אפשר ליצור טריגר Eventarc עם תהליך עבודה שפריסתו הושלמה כמקבל האירוע באמצעות Google Cloud CLI ‏ (gcloud או Terraform) או דרך מסוף Google Cloud .

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

המסוף

1. נכנסים לדף Triggers ב-Eventarc במסוף Google Cloud .

   כניסה לדף Triggers

2. לוחצים על Create trigger (יצירת ביטוי להפעלה).
3. מקלידים Trigger name.

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

4. בשדה Trigger type, בוחרים באפשרות Google sources.
5. ברשימה Event provider בוחרים באפשרות Cloud Storage.

   שימו לב: יכול להיות שבשם ספק האירועים שמופיע בGoogle Cloud מסמכי התיעוד המשויכים לא מופיעה הקידומת Cloud או Google Cloud. לדוגמה, במסוף, Memorystore for Redis נקרא Google Cloud Memorystore for Redis.

6. ברשימה סוג האירוע, מתוך האירועים ישירים, בוחרים סוג אירוע:
   • ‫google.cloud.storage.object.v1.archived: האירוע נשלח כשגרסה פעילה של אובייקט הופכת לגרסה לא עדכנית. מידע נוסף זמין במאמר בנושא ניהול גרסאות של אובייקטים.
   • ‫google.cloud.storage.object.v1.delete: האירוע נשלח כשמתבצעת מחיקה רכה של אובייקט. מידע נוסף זמין במאמר בנושא מחיקה רכה.
   • ‫google.cloud.storage.object.v1.finalized: האירוע נשלח כשנוצר אובייקט חדש (או כשמתבצעת החלפה של אובייקט קיים ונוצרת גנרציה חדשה של האובייקט הזה) בדלי.
   • ‫google.cloud.storage.object.v1.metadataUpdated: האירוע נשלח כש[המטא-נתונים](/storage/docs/metadata) של אובייקט קיים משתנים.
7. ברשימה סוג התוכן של נתוני האירועים, בוחרים את הקידוד של מטען הייעודי (payload) של האירוע.

   עבור אירועים ישירים מ- Cloud Storage, הערך צריך להיות application/json.

8. מציינים או מחפשים את המזהה הייחודי הגלובלי של הקטגוריה ב-Cloud Storage.

   הקטגוריה של Cloud Storage צריכה להיות באותוGoogle Cloud פרויקט ובאותו אזור או אזור גיאוגרפי נרחב יותר כמו הטריגר של Eventarc.

9. בוחרים Region.

   טריגרים של Cloud Storage ל-Eventarc זמינים במיקומים של אזור יחיד, שני אזורים ומספר אזורים. שימו לב שהקטגוריה של Cloud Storage והטריגר של Eventarc חייבים להיות שייכים לאותו פרויקט ולאותו אזור או לאותם אזורים. Google Cloud

   חשוב: מכיוון ש-Eventarc Standard משתמש ב-Pub/Sub כשכבת התעבורה שלו, טריגרים של Cloud Storage עלולים להיכשל אם אירוע של Cloud Storage מגיע מאזור שלא מורשה על ידי מדיניות אחסון ההודעות של Pub/Sub, ואם נאכפות פעולות במעבר ("enforceInTransit": true). כשיוצרים טריגר של Cloud Storage במיקום רב-אזורי, צריך לוודא שמדיניות אחסון ההודעות מאפשרת את כל אזורי המקור במיקום הרב-אזורי הזה. מידע נוסף מופיע במאמר הגדרת מדיניות אחסון הודעות.

   האירועים מועברים באמצעות התראות Pub/Sub מ-Cloud Storage. יכול להיות שרישום של יותר מדי התראות לאותה קטגוריה יגרום לחריגה ממגבלת ההתראות לקטגוריה, כפי שמצוין בשגיאה Cloud Storage bucket ...: Pub/Sub notification limit reached. אפשר להגדיר עד 10 הגדרות של התראות להפעלה של אירוע ספציפי בקטגוריה מסוימת. מידע נוסף על מכסות ומגבלות זמין בדף מכסות ומגבלות ב-Cloud Storage.

10. בוחרים את חשבון השירות שיפעיל את השירות או את תהליך העבודה.

    אפשר גם ליצור חשבון שירות חדש.

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

11. ברשימה Event destination, בוחרים באפשרות Workflows.
12. בוחרים תהליך עבודה.
    

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

    מידע נוסף מופיע במאמר בנושא יצירת טריגר לזרימות עבודה.

13. אפשר גם ללחוץ על הוספת תווית. תוויות הן צמדי מפתח/ערך שעוזרים לכם לארגן אתGoogle Cloud המשאבים. מידע נוסף זמין במאמר מהן תוויות?
14. לוחצים על יצירה.

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

gcloud

gcloud eventarc triggers create TRIGGER \
    --location=LOCATION \
    --destination-workflow=DESTINATION_WORKFLOW  \
    --destination-workflow-location=DESTINATION_WORKFLOW_LOCATION \
    --event-filters="type=EVENT_FILTER_TYPE" \
    --event-filters="bucket=BUCKET" \
    --service-account="SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com"

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

• ‫TRIGGER: המזהה של הטריגר או מזהה מלא.
• ‫LOCATION: המיקום של טריגר Eventarc, שזמין במיקומים של אזור יחיד, שני אזורים ומספר אזורים. אי אפשר ליצור טריגר Eventarc.global שימו לב שהקטגוריה של Cloud Storage והטריגר של Eventarc חייבים להיות שייכים לאותו Google Cloud פרויקט ואזור. מידע נוסף זמין במאמר בנושא מיקומי Eventarc.
  חשוב: מכיוון ש-Eventarc Standard משתמש ב-Pub/Sub כשכבת התעבורה שלו, טריגרים של Cloud Storage עלולים להיכשל אם אירוע של Cloud Storage מגיע מאזור שלא מורשה על ידי מדיניות אחסון ההודעות של Pub/Sub, ואם נאכפות פעולות במעבר ("enforceInTransit": true). כשיוצרים טריגר של Cloud Storage במיקום רב-אזורי, צריך לוודא שמדיניות אחסון ההודעות מאפשרת את כל אזורי המקור במיקום הרב-אזורי הזה. מידע נוסף מופיע במאמר הגדרת מדיניות אחסון הודעות.
• ‫DESTINATION_WORKFLOW: המזהה של תהליך העבודה שנפרס ומקבל את האירועים מהטריגר. תהליך העבודה יכול להיות בכל אחד מהמיקומים שנתמכים ב-Workflows, והוא לא חייב להיות באותו מיקום כמו הטריגר. עם זאת, תהליך העבודה חייב להיות באותו פרויקט כמו הטריגר.
• ‫DESTINATION_WORKFLOW_LOCATION (אופציונלי): המיקום שבו מופעל תהליך העבודה של היעד. אם לא מציינים זאת, ההנחה היא שתהליך העבודה נמצא באותו מיקום כמו הטריגר.
• ‫EVENT_FILTER_TYPE: המזהה של אירוע Cloud Storage. יכול להיות אחד מהערכים הבאים:
  • ‫google.cloud.storage.object.v1.finalized: האירוע נשלח כשנוצר אובייקט חדש בקטגוריה (או כשמתבצעת החלפה של אובייקט קיים ונוצרת גרסה חדשה של האובייקט הזה)
  • ‫google.cloud.storage.object.v1.archived: האירוע נשלח כשגרסה פעילה של אובייקט הופכת לגרסה לא עדכנית. מידע נוסף זמין במאמר בנושא ניהול גרסאות של אובייקטים.
  • ‫google.cloud.storage.object.v1.deleted: האירוע נשלח כשאובייקט נמחק באופן זמני. מידע נוסף זמין במאמר בנושא מחיקה רכה.
  • ‫google.cloud.storage.object.v1.metadataUpdated: האירוע נשלח כשהמטא-נתונים של אובייקט קיים משתנים.
• ‫BUCKET: המזהה הייחודי הגלובלי של קטגוריית Cloud Storage.
• ‫SERVICE_ACCOUNT_NAME: השם של חשבון השירות שמנוהל על ידי המשתמש.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud

הערות:

• באירועים ישירים מ- Cloud Storage, הקידוד של מטען הייעודי (payload) של האירוע הוא application/json.
• חובה להשתמש בדגלים הבאים:
  • --event-filters="type=EVENT_FILTER_TYPE"
  • --event-filters="bucket=BUCKET"
• אחרי שיוצרים טריגר, אי אפשר לשנות אותו.EVENT_FILTER_TYPE כדי להגדיר סוג אירוע אחר, צריך ליצור טריגר חדש.
• הדגל --service-account משמש לציון כתובת האימייל בחשבון השירות בניהול זהויות והרשאות גישה (IAM) שמשויך לטריגר.
• האירועים מועברים באמצעות התראות Pub/Sub מ-Cloud Storage. יכול להיות שרישום של יותר מדי התראות לאותה קטגוריה יגרום לחריגה ממגבלת ההתראות לקטגוריה, כפי שמצוין בשגיאה Cloud Storage bucket ...: Pub/Sub notification limit reached. אפשר להגדיר עד 10 הגדרות של התראות לקטגוריה, כך שהן יופעלו כשמתרחש אירוע ספציפי. מידע נוסף על מכסות ומגבלות אפשר למצוא בדף המכסות והמגבלות של Cloud Storage.
• לכל טריגר יכולים להיות כמה מסנני אירועים, מופרדים בפסיקים בדגל אחד --event-filters=[ATTRIBUTE=VALUE,...] או שאפשר לחזור על הדגל כדי להוסיף עוד מסננים. רק אירועים שתואמים לכל המסננים נשלחים ליעד. אין תמיכה בתווים כלליים לחיפוש ובביטויים רגולריים.
• הקטגוריה של Cloud Storage צריכה להיות באותו Google Cloudפרויקט ואזור או אזור גיאוגרפי נרחב יותר שכולל מספר אזורים כמו הטריגר של Eventarc.
• כברירת מחדל, מינויים ל-Pub/Sub שנוצרו עבור Eventarc נשמרים ללא קשר לפעילות ולא פג תוקפם. במאמר מאפייני מינוי מוסבר איך לשנות את משך הזמן של חוסר הפעילות.

דוגמה:

gcloud eventarc triggers create helloworld-trigger \
    --location=us-central1 \
    --destination-workflow=my-workflow \
    --destination-workflow-location=europe-west4 \
    --event-filters="type=google.cloud.storage.object.v1.finalized" \
    --event-filters="bucket=my-project-bucket" \
    --service-account="${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"

הפקודה הזו יוצרת טריגר בשם helloworld-trigger לקטגוריה my-project-bucket של Cloud Storage ולאירוע שמזוהה כ-google.cloud.storage.object.v1.finalized.

Terraform

אפשר ליצור טריגר לתהליך עבודה באמצעות Terraform. פרטים נוספים מופיעים במאמר בנושא הפעלת תהליך עבודה באמצעות Eventarc ו-Terraform.

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

הצגת טריגר

אפשר לאשר את יצירת הטריגר באמצעות רשימת הטריגרים של Eventarc ב-Google Cloud CLI או במסוף Google Cloud .

המסוף

1. נכנסים לדף Triggers ב-Eventarc במסוף Google Cloud .

   כניסה לדף Triggers

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

2. כדי לסנן את הטריגרים:

   1. לוחצים על Filter (מסנן) או על השדה Filter triggers (טריגרים של מסנן).
   2. ברשימה Properties, בוחרים אפשרות לסינון הטריגרים.

   אפשר לבחור נכס אחד או להשתמש באופרטור הלוגי OR כדי להוסיף עוד נכסים.

3. כדי למיין את הטריגרים, לוחצים על מיון לצד כותרת של עמודה נתמכת.

gcloud

מריצים את הפקודה הבאה כדי להציג את הטריגרים:

gcloud eventarc triggers list --location=-

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

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

• הפעלת תהליך עבודה באמצעות Eventarc ו-Terraform

• הפעלת Workflows באמצעות אירועים מ-Cloud Storage

• הפעלת Workflows באמצעות הודעות Pub/Sub

• מידע נוסף על Eventarc