דף זה תורגם על ידי Cloud Translation API.

אירועים של Cloud Run for Anthos Codelab

1. מבוא

ב-Cloud Run אפשר להריץ קונטיינרים ללא שמירת מצב בסביבה מנוהלת. היא מבוססת על קוד פתוח Knative, ומאפשרת לכם להריץ את הקונטיינרים בניהול מלא באמצעות Cloud Run, או באשכול Google Kubernetes Engine באמצעות Cloud Run for Anthos.

בעזרת Events for Cloud Run for Anthos קל לקשר בין שירותי Cloud Run לאירועים ממגוון מקורות. הוא מאפשר לפתח ארכיטקטורות מבוססות-אירועים שבהן מיקרו-שירותים (microservices) בצימוד חלש ומפוזרים. הוא גם מטפל בהטמעת נתונים של אירועים, מסירה, אבטחה, הרשאות וטיפול בשגיאות, כדי לשפר את הגמישות של המפתחים ואת עמידות האפליקציות.

ב-Codelab הזה, תלמדו על אירועים ל-Cloud Run for Anthos. באופן ספציפי יותר, תוכלו להאזין לאירועים מ-Cloud Pub/Sub, מיומני ביקורת, מ-Cloud Storage, מ-Cloud Scheduler ואיך ליצור או לצרוך אירועים בהתאמה אישית.

מה תלמדו

חזון ארוך טווח של אירועים ב-Cloud Run for Anthos
מצב האירועים הנוכחיים ב-Cloud Run for Anthos
יצירת sink ב-Cloud Run
יצירת טריגר לאירוע בשביל Cloud Pub/Sub
יצירת טריגר לאירוע עבור יומני ביקורת
יצירת טריגר לאירוע ב-Cloud Storage
יצירת טריגר לאירוע בשביל Cloud Scheduler
הפקה וצריכה של אירועים מותאמים אישית

2. ראייה לטווח ארוך

ככל שאנחנו משתמשים בארכיטקטורה ללא שרת (serverless), אירועים הופכים לחלק בלתי נפרד מדרכי התקשורת של מיקרו-שירותים (microservices) מופרדים. אירועים ל-Cloud Run for Anthos הופכים את האירועים לאזרחים ברמה ראשונה בהצעה של Cloud Run for Anthos, כך שקל לפתח אפליקציות ללא שרת (serverless) שמבוססות על אירועים.

אירועים של Cloud Run for Anthos מאפשרים שליחה של אירועים אסינכרוניים מהימנים, מאובטחים וניתנים להתאמה, ממקורות אירועים ארוזים או שנוצרו על ידי אפליקציות, לצרכנים שנמצאים באשכולות ומחוץ לאשכולות.

המקורות של Google Cloud	מקורות אירועים שהם מוצרים בבעלות Google Cloud
מקורות של Google	מקורות של אירועים שהם מוצרים בבעלות Google, כמו Gmail , Hangouts, ניהול Android ועוד
מקורות מותאמים אישית	מקורות של אירועים שהם לא מוצרים בבעלות Google, שנוצרים על ידי משתמשי הקצה עצמם. האפליקציות יכולות להיות Knative Sources שפותחו על ידי משתמשים, או כל אפליקציה אחרת שפועלת באשכול שיכולה להפיק אירוע Cloud.
מקורות של צד שלישי	מקורות של אירועים שלא בבעלות Google ולא בבעלות של משתמשי קצה. מקורות כאלה כוללים אירועים פופולריים כמו GitHub , SAP, Datadog , Pagerduty וכו' שנמצאים בבעלות ובתחזוקה של ספקים, שותפים או קהילות OSS של צד שלישי.

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

האירועים של Cloud Run תואמים ל-Knative Eventing ומאפשרים ניידות של קונטיינרים אל הטמעות אחרות מבוססות Knative ומהן. כך אנחנו מעניקים למפיקי אירועים חיווט עם צרכני האירועים מסגרת עקבית וגמישה לענן.

3. המצב הנוכחי

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

כדי לאפשר למשתמשים לפתח אפליקציות ללא שרת (serverless) שמבוססות על אירועים, אנחנו מתמקדים בהתחלה בשני שלבים:

ליצור סביבה עסקית רחבה של מקורות Google Cloud, שמאפשרת לשירותי Cloud Run באשכול Anthos להגיב לאירועים משירותי Google Cloud.

בהתחלה, אירועים ממקורות של Google Cloud נשלחים באמצעות יומני ביקורת של Cloud (CAL), וכך מאפשרים שימוש במגוון רחב של מקורות אירועים. זמן האחזור והזמינות של העברת אירועים מהמקורות האלה קשורים לאלו של יומני הביקורת של Cloud. בכל פעם שאירוע ממקור של Google Cloud מתפרסם, נוצרת רשומה תואמת ביומן הביקורת של Cloud.
יחד עם יומני הביקורת של Cloud, יש תמיכה ברמה ראשונה בצריכת אירועים מ-Cloud Storage, מ-Cloud Pub/Sub ומ-Cloud Scheduler. נמשיך להרחיב את הסביבה העסקית הזו של מקורות עם עוד מקורות מהשורה הראשונה, ככל שנלמד יותר מהתהליכים שהמשתמשים עוברים ומהמשוב עליהם.

כדי לאפשר לאפליקציות ולשירותים של משתמשי קצה להפיץ אירועים מותאמים אישית, מפרסמים את כתובת ה-URL של Broker-מקומית ברמת מרחב השמות.

במנגנון הבסיס של הצגת המודעות נעשה שימוש בנושאים ובמינויים של Cloud Pub/Sub שמוצגים בחשבונות של הלקוחות פרויקטים. לכן התכונה מספקת את אותן אחריות להעברה כמו ב-Cloud Pub/Sub.

'טריגר אירוע' מאפשר להירשם לאירועים כך שאירועים שתואמים למסנן הטריגר יועברו ליעד (או ל-sink) שאליו מפנה הטריגר.

כל האירועים נשלחים בפורמט Cloud Event v1.0 כדי לאפשר יכולת פעולה הדדית בין שירותים.

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

4. הגדרה ודרישות

הגדרת סביבה בקצב עצמאי

נכנסים למסוף Cloud ויוצרים פרויקט חדש או עושים שימוש חוזר בפרויקט קיים. אם אין לכם עדיין חשבון Gmail או חשבון Google Workspace, עליכם ליצור חשבון.

Project Name (שם הפרויקט) הוא השם המוצג של הפרויקט. כל עוד אתם פועלים בהתאם למוסכמות של מתן השמות, תוכלו להשתמש בכל מה שתרצו ולעדכן אותו בכל שלב.
Project ID חייב להיות ייחודי בכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו (אי אפשר לשנות אותו אחרי שמגדירים אותו). מסוף Cloud יוצר מחרוזת ייחודית באופן אוטומטי. בדרך כלל לא מעניין אותך מה זה. ברוב ה-Codelabs תצטרכו להפנות אל מזהה הפרויקט (ובדרך כלל הוא מזוהה כ-PROJECT_ID), כך שאם הוא לא מוצא חן בעיניכם, תוכלו ליצור פרויקט אקראי אחר או לנסות בעצמכם ולבדוק אם הוא זמין. ואז המכשיר 'קפוא' לאחר יצירת הפרויקט.

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

מעבר ב-Codelab הזה לא אמור לעלות הרבה, אם בכלל. חשוב לבצע את כל ההוראות בקטע 'ניקוי' שמסביר איך להשבית משאבים כדי שלא תצברו חיובים מעבר למדריך הזה. משתמשים חדשים ב-Google Cloud זכאים להצטרף לתוכנית תקופת ניסיון בחינם בשווי 1,200 ש"ח.

הפעלת Cloud Shell

אומנם אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-Codelab הזה משתמשים ב-Google Cloud Shell, סביבת שורת הפקודה שפועלת ב-Cloud.

ממסוף GCP, לוחצים על הסמל של Cloud Shell בסרגל הכלים שבפינה השמאלית העליונה:

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

למכונה הווירטואלית הזו נטען כל כלי הפיתוח הדרושים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר משמעותית את ביצועי הרשת והאימות. כל העבודה בשיעור ה-Lab הזה יכולה להתבצע באמצעות דפדפן בלבד.

5. הפעלת ממשקי API, הגדרת אזור ופלטפורמה

הגדרה של מזהה פרויקט והתקנת רכיבי אלפא

ב-Inside Cloud Shell, הערך של GOOGLE_CLOUD_PROJECT כבר מוגדר למזהה הפרויקט. אם לא, צריך לוודא שהוא מוגדר וש-gcloud מוגדר עם מזהה הפרויקט הזה:

export GOOGLE_CLOUD_PROJECT=your-project-id
gcloud config set project ${GOOGLE_CLOUD_PROJECT}

צריך לוודא שרכיב ה-gcloud לאלפא מותקן:

gcloud components install alpha

הפעלת ממשקי API

מפעילים את כל השירותים הנחוצים:

gcloud services enable cloudapis.googleapis.com 
gcloud services enable container.googleapis.com 
gcloud services enable containerregistry.googleapis.com
gcloud services enable cloudbuild.googleapis.com

הגדרת תחום ופלטפורמה

לפני יצירת אשכול GKE באמצעות אירועי Cloud Run, צריך להגדיר את שם האשכול, התחום והפלטפורמה. לדוגמה, כאן מגדירים את השם ואת האזור כ-events-cluster ו-europe-west1-b והפלטפורמה היא gke,

ב-Cloud Shell:

export CLUSTER_NAME=events-cluster
export CLUSTER_ZONE=europe-west1-b

gcloud config set run/cluster ${CLUSTER_NAME}
gcloud config set run/cluster_location ${CLUSTER_ZONE}
gcloud config set run/platform gke

אפשר לבדוק אם ההגדרות האישיות נקבעו:

gcloud config list

...
[run]
cluster = events-cluster
cluster_location = europe-west1-b
platform = gke

6. יצירת אשכול GKE באמצעות אירועי Cloud Run

יצירת אשכול GKE שמריץ את Kubernetes >= 1.15.9-gke.26, כאשר התוספים הבאים מופעלים: CloudRun, HttpLoadBalancing, HorizontalPodAutoscaling:

gcloud beta container clusters create ${CLUSTER_NAME} \
  --addons=HttpLoadBalancing,HorizontalPodAutoscaling,CloudRun \
  --machine-type=n1-standard-4 \
  --enable-autoscaling --min-nodes=3 --max-nodes=10 \
  --no-issue-client-certificate --num-nodes=3 --image-type=cos \
  --enable-stackdriver-kubernetes \
  --scopes=cloud-platform,logging-write,monitoring-write,pubsub \
  --zone ${CLUSTER_ZONE} \
  --release-channel=rapid

7. הגדרת אירועי Cloud Run (מישור בקרה)

לאירועי Cloud Run יש מישור בקרה ומישור נתונים שצריך להגדיר בנפרד. כדי להגדיר את מישור הבקרה:

ב-Cloud Shell:

gcloud beta events init

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

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

הסטטוס Running, 2 (controller-xxx-xxx ו-webhook-xxx-xxx) במרחב השמות cloud-run-events ו-2 (eventing-controller-xxx-xxx ו-eventing-webhook-xxx-xxx) במרחב השמות knative-eventing. כדי לבדוק זאת, מריצים את הפקודות הבאות:

kubectl get pods -n cloud-run-events

NAME                         READY   STATUS    RESTARTS   AGE
controller-9cc679b67-2952n   1/1     Running   0          22s
webhook-8576c4cfcb-dhz82     1/1     Running   0          16m

kubectl get pods -n knative-eventing

NAME                                   READY   STATUS    RESTARTS   AGE
eventing-controller-77f46f6cf8-kj9ck   1/1     Running   0          17m
eventing-webhook-5bc787965f-hcmwg      1/1     Running   0          17m

8. הגדרת אירועי Cloud Run (מישור נתונים)

בשלב הבא מגדירים את מישור הנתונים במרחבי השמות של המשתמשים. הפעולה הזו יוצרת מתווך עם הרשאות מתאימות לקריאה/כתיבה מ-Pub/Sub.

ב-Inside Cloud Shell, מגדירים משתנה סביבה NAMESPACE למרחב השמות שבו רוצים להשתמש בשביל האובייקטים. אפשר להגדיר אותו לערך default אם רוצים להשתמש במרחב השמות שמוגדר כברירת מחדל, כפי שמוצג בהמשך:

export NAMESPACE=default

שימו לב שאם מרחב השמות שצוין לא קיים (כלומר מרחב השמות לא מוגדר כברירת המחדל), צריך ליצור אותו:

kubectl create namespace ${NAMESPACE}

אתחול מרחב השמות עם הסוד שמוגדר כברירת מחדל:

gcloud beta events namespaces init ${NAMESPACE} --copy-default-secret

יצירת מתווך ברירת מחדל במרחב השמות:

gcloud beta events brokers create default --namespace ${NAMESPACE}

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

kubectl get broker -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-brokercell-ingress.cloud-run-events.svc.cluster.local/default/default

9. גילוי אירועים

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

כדי לראות את הרשימה של סוגי האירועים השונים:

gcloud beta events types list

כדי לקבל מידע נוסף על כל סוג אירוע:

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

10. יצירת Sink של Cloud Run

ב-sink של אירוע, יש לפרוס שירות של Cloud Run שמתעד את התוכן של ה-CloudEvent שהוא מקבל.

אפשר להשתמש באירוע event_display של Knative, שכבר עבר הידור (compile), קובץ אימג' בקונטיינר שנוצר כחלק מגרסת Knative. אפשר לראות את הפרטים של קובץ האימג' בקונטיינר ב-event-display.yaml:

...
containers:
  - image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

פריסה ב-Cloud Run

פורסים את האפליקציה בקונטיינרים ב-Cloud Run:

export SERVICE_NAME=event-display
gcloud run deploy ${SERVICE_NAME} \
  --namespace=${NAMESPACE} \
  --image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

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

11. יצירת טריגר לאירוע בשביל Cloud Pub/Sub

אחת הדרכים לקבל אירועים היא באמצעות Cloud Pub/Sub. אפליקציות מותאמות אישית יכולות לפרסם הודעות ב-Cloud Pub/Sub ולשלוח את ההודעות האלה ל-sinks ב-Google Cloud Run באמצעות אירועים ל-Cloud Run.

איך יוצרים נושאים

קודם כול יוצרים נושא ב-Cloud Pub/Sub. אפשר להחליף את TOPIC_ID בשם נושא ייחודי מועדף:

export TOPIC_ID=cr-gke-topic
gcloud pubsub topics create ${TOPIC_ID}

יצירת טריגר

לפני שיוצרים את הטריגר, אפשר לקבל פרטים נוספים על הפרמטרים שצריך ליצור בשביל אירועים מ-Cloud Pub/Sub:

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

יוצרים טריגר כדי לסנן אירועים שפורסמו בנושא Cloud Pub/Sub לפי שירות Cloud Run שנפרס:

gcloud beta events triggers create trigger-pubsub \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type google.cloud.pubsub.topic.v1.messagePublished \
  --parameters topic=${TOPIC_ID}

בדיקת הטריגר

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

gcloud beta events triggers list

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

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

gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"

ה-sink שיצרנו ב-Cloud Run מתעד את גוף ההודעה הנכנסת. אפשר להציג את הנתונים האלה בקטע Logs במכונה של Cloud Run:

לתשומת ליבך, "שלום לך" יהיה בקידוד base64 כפי שנשלח על ידי Pub/Sub, ויהיה צורך לפענח אותו אם רוצים לראות את ההודעה המקורית שנשלחה.

מחיקת הטריגר

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

gcloud beta events triggers delete trigger-pubsub --namespace ${NAMESPACE}

12. יצירת טריגר לאירוע עבור יומני ביקורת

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

להפעלת יומני ביקורת

כדי לקבל אירועים משירות, עליכם להפעיל יומני ביקורת. במסוף Cloud, בוחרים את IAM & Admin > Audit Logs בתפריט שבפינה השמאלית העליונה. ברשימת השירותים, בודקים את Google Cloud Pub/Sub:

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

בדיקה של יומני ביקורת

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

לדוגמה, יוצרים נושא Pub/Sub:

gcloud pubsub topics create cre-gke-topic1

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

בקטע Query Builder,, בוחרים באפשרות Cloud Pub/Sub Topic ולוחצים על Add:

אחרי הרצת השאילתה, יוצגו יומנים של נושאי Pub/Sub ואחד מהם אמור להיות google.pubsub.v1.Publisher.CreateTopic:

חשוב לשים לב לserviceName, לmethodName ולresourceName. נשתמש בהם ביצירת הטריגר.

יצירת טריגר

עכשיו אתם מוכנים ליצור טריגר לאירוע עבור יומני הביקורת.

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

gcloud beta events types describe google.cloud.audit.log.v1.written

יוצרים את הטריגר בעזרת המסננים הנכונים:

gcloud beta events triggers create trigger-auditlog \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.audit.log.v1.written \
  --parameters serviceName=pubsub.googleapis.com \
  --parameters methodName=google.pubsub.v1.Publisher.CreateTopic

בדיקת הטריגר

מציגים את כל הטריגרים כדי לאשר שהטריגר נוצר בהצלחה:

gcloud beta events triggers list

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

יוצרים נושא Pub/Sub נוסף, כפי שעשיתם קודם לכן:

gcloud pubsub topics create cre-gke-topic2

אם תבדקו את היומנים של שירות Cloud Run במסוף Cloud, אתם אמורים לראות את האירוע שהתקבל:

מחיקת הטריגר והנושאים

לחלופין, אפשר למחוק את הטריגר בסיום הבדיקה:

gcloud beta events triggers delete trigger-auditlog

מוחקים גם את הנושאים:

gcloud pubsub topics delete cre-gke-topic1 cre-gke-topic2

13. יצירת טריגר לאירוע ב-Cloud Storage

אתם תגדירו טריגר להאזנה לאירועים מ-Cloud Storage.

Create a bucket

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

export BUCKET_NAME=[new bucket name]
export REGION=europe-west1

gsutil mb -p $(gcloud config get-value project) \
  -l $REGION \
  gs://$BUCKET_NAME/

הגדרת הרשאות ל-Cloud Storage

לפני יצירת טריגר, אתם צריכים לתת לחשבון השירות שמוגדר כברירת מחדל בשביל Cloud Storage הרשאה לפרסם ב-Pub/Sub.

קודם כול, מאתרים את חשבון השירות שמשמש את Cloud Storage לפרסום ב-Pub/Sub. אפשר לבצע את השלבים שמפורטים במאמר קבלת חשבון השירות של Cloud Storage כדי לקבל את חשבון השירות, או להשתמש בפקודה הבאה:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://storage.googleapis.com/storage/v1/projects/$(gcloud config get-value project)/serviceAccount"

חשבון השירות צריך להיות רשום בקטגוריה email_address.

נניח שחשבון השירות שמצאתם למעלה היה service-XYZ@gs-project-accounts.iam.gserviceaccount.com, מגדירים אותו כמשתנה סביבה:

export GCS_SERVICE_ACCOUNT=service-XYZ@gs-project-accounts.iam.gserviceaccount.com

לאחר מכן, מעניקים הרשאות לחשבון השירות הזה כדי לפרסם אותו ב-Pub/Sub:

gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \
  --member=serviceAccount:${GCS_SERVICE_ACCOUNT} \
  --role roles/pubsub.publisher

יצירת טריגר

עכשיו אתם מוכנים ליצור טריגר לאירוע בשביל אירועים של Cloud Storage.

אפשר לקבל פרטים נוספים על הפרמטרים הדרושים לבניית הטריגר:

gcloud beta events types describe google.cloud.storage.object.v1.finalized

יוצרים את הטריגר בעזרת המסננים הנכונים:

gcloud beta events triggers create trigger-storage \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.storage.object.v1.finalized \
  --parameters bucket=${BUCKET_NAME}

בדיקת הטריגר

מציגים את כל הטריגרים כדי לאשר שהטריגר נוצר בהצלחה:

gcloud beta events triggers list

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

עכשיו אפשר להפעיל אירוע.

העלאת קובץ אקראי לקטגוריה של Cloud Storage:

echo "Hello World" > random.txt
gsutil cp random.txt gs://${BUCKET_NAME}/random.txt

אם תבדקו את היומנים של שירות Cloud Run במסוף Cloud, אתם אמורים לראות את האירוע שהתקבל:

מחיקת הטריגר

לחלופין, אפשר למחוק את הטריגר בסיום הבדיקה:

gcloud beta events triggers delete trigger-storage

14. יצירת טריגר לאירוע בשביל Cloud Scheduler

אתם מגדירים טריגר להאזנה לאירועים מ-Cloud Scheduler.

יצירת אפליקציה ב-App Engine

כרגע, ל-Cloud Scheduler נדרשים משתמשים כדי ליצור אפליקציה של App Engine. בוחרים מיקום ב-App Engine ויוצרים את האפליקציה:

export APP_ENGINE_LOCATION=europe-west
gcloud app create --region=${APP_ENGINE_LOCATION}

יצירת טריגר

gcloud beta events types describe google.cloud.scheduler.job.v1.executed

כדי ליצור את המתזמן, בוחרים מיקום ב-Cloud Scheduler:

export SCHEDULER_LOCATION=europe-west1

יוצרים טריגר שייצור משימה שתבוצע בכל דקה ב-Google Cloud Scheduler וקוראים לשירות היעד:

gcloud beta events triggers create trigger-scheduler \
  --namespace ${NAMESPACE} \
  --target-service=${SERVICE_NAME} \
  --type=google.cloud.scheduler.job.v1.executed \
  --parameters location=${SCHEDULER_LOCATION} \
  --parameters schedule="* * * * *" \
  --parameters data="trigger-scheduler-data"

בדיקת הטריגר

מציגים את כל הטריגרים כדי לאשר שהטריגר נוצר בהצלחה:

gcloud beta events triggers list

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

אם בודקים את היומנים של שירות Cloud Run במסוף Cloud, אמור להופיע האירוע שהתקבל.

מחיקת הטריגר

לחלופין, אפשר למחוק את הטריגר בסיום הבדיקה:

gcloud beta events triggers delete trigger-scheduler

15. אירועים בהתאמה אישית (נקודת קצה של Broker)

בחלק הזה של ה-Codelab, תצרו ותצרו אירועים מותאמים אישית באמצעות ה-Broker.

יצירת Pod של Curl כדי להפיק אירועים

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

כדי ליצור Pod שמוגדר כמפיק האירוע, מריצים את הפקודה הבאה:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: curl
  name: curl
  namespace: $NAMESPACE
spec:
  containers:
  - image: radial/busyboxplus:curl
    imagePullPolicy: IfNotPresent
    name: curl
    resources: {}
    stdin: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    tty: true
EOF

מוודאים שה-Pod של ה-curl פועל בצורה תקינה. אתם אמורים לראות רצף מודעות בשם curl עם Status=Running:

kubectl get pod curl -n ${NAMESPACE}

יצירת טריגר

כדי ליצור טריגר עם מסנן לפי הסוג CloudEvents הספציפי (במקרה הזה alpha-type), תבוצע פליטת נתונים. שימו לב: יש תמיכה בסינון בהתאמה מדויקת לפי כל מספר של מאפיינים של CloudEvents ותוספים. אם המסנן מגדיר מספר מאפיינים, האירוע חייב לכלול את כל המאפיינים כדי שהטריגר יסנן אותו. לעומת זאת, אם לא תציינו מסנן, כל האירועים יתקבלו בשירות שלכם.

יוצרים את הטריגר:

gcloud beta events triggers create trigger-custom \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=alpha-type \
  --custom-type

בדיקת הטריגר

מציגים את כל הטריגרים כדי לאשר שהטריגר נוצר בהצלחה:

gcloud beta events triggers list

כדי ליצור אירוע, שולחים בקשת HTTP ל-Broker. כדי להזכיר לעצמכם את כתובת ה-URL של Broker, מריצים את הפקודה הבאה:

kubectl get brokers -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-broker.<NAMESPACE>.svc.cluster.local

SSH למערך curl שיצרתם קודם:

kubectl --namespace ${NAMESPACE} attach curl -it

הזנתם SSH בתוך ה-pod, ועכשיו אתם יכולים לשלוח בקשת HTTP. עכשיו תופיע הנחיה דומה:

Defaulting container name to curl.
Use 'kubectl describe pod/curl -n default' to see all of the containers in this pod.
If you don't see a command prompt, try pressing enter.
[ root@curl:/ ]$

יצירת אירוע:

curl -v "<BROKER-URL>" \
-X POST \
-H "Ce-Id: my-id" \
-H "Ce-Specversion: 1.0" \
-H "Ce-Type: alpha-type" \
-H "Ce-Source: my-source" \
-H "Content-Type: application/json" \
-d '{"msg":"send-cloudevents-to-broker"}'

אם האירוע התקבל, תישלח אליך תשובה מסוג HTTP 202 Accepted. יציאה מפעילות SSH עם Ctrl + D

כדי לוודא שהאירוע שפורסם נשלח, אפשר לעיין ביומנים של שירות Cloud Run:

kubectl logs --selector serving.knative.dev/service=$SERVICE_NAME \
 -c user-container -n $NAMESPACE --tail=100

מחיקת הטריגר

לחלופין, אפשר למחוק את הטריגר בסיום הבדיקה:

gcloud beta events triggers delete trigger-custom

16. מעולה!

ברכות על השלמת ה-Codelab.

הנושאים שטיפלנו בהם

חזון ארוך טווח של אירועים ב-Cloud Run for Anthos
מצב האירועים הנוכחיים ב-Cloud Run for Anthos
יצירת sink ב-Cloud Run
יצירת טריגר לאירוע בשביל Cloud Pub/Sub
יצירת טריגר לאירוע עבור יומני ביקורת
יצירת טריגר לאירוע ב-Cloud Storage
יצירת טריגר לאירוע בשביל Cloud Scheduler
הפקה וצריכה של אירועים מותאמים אישית