אירועים של 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, ואיך ליצור ולצרוך אירועים בהתאמה אישית.

מה תלמדו

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

2. חזון לטווח ארוך

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

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

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

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

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

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.

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

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

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

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

הגדרת סביבה בקצב אישי

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

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

לאחר מכן, תצטרכו להפעיל את החיוב ב-Cloud Console כדי להשתמש במשאבים של Google Cloud.

העלות של התרגול הזה לא אמורה להיות גבוהה, ואולי אפילו לא תצטרכו לשלם בכלל. חשוב לפעול לפי ההוראות בקטע 'ניקוי' כדי להשבית את המשאבים, וכך לא תחויבו אחרי שתסיימו את המדריך הזה. משתמשים חדשים ב-Google Cloud זכאים לתוכנית תקופת ניסיון בחינם בשווי 300$.

מפעילים את Cloud Shell

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

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

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

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

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

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

ב-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, צריך להגדיר את שם האשכול, האזור והפלטפורמה. לדוגמה, כאן הגדרנו את השם והתחום ל-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 Events

יוצרים אשכול 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 Events יש מישור בקרה ומישור נתונים שצריך להגדיר בנפרד. כדי להגדיר את מישור הבקרה:

ב-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 Events (מישור הנתונים)

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

ב-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

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

אתם יכולים להשתמש ב-event_display של Knative שכבר עבר קומפילציה וקובץ האימג' שלו בקונטיינר נוצר כחלק מהגרסה של 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, וההודעות האלה יכולות להישלח ליעדים ב-Google Cloud Run באמצעות Events for 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:

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

מחיקת הטריגר

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

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

12. יצירת טריגר מסוג Event ליומני ביקורת

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

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

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

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

בדיקת יומני ביקורת

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

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

gcloud pubsub topics create cre-gke-topic1

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

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

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

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 Console, אמור להופיע האירוע שהתקבל:

מחיקת הטריגר

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

gcloud beta events triggers delete trigger-storage

14. יצירת טריגר מסוג Event ל-Cloud Scheduler

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

יצירת אפליקציית App Engine

בשלב הזה, המשתמשים צריכים ליצור אפליקציית App Engine כדי להשתמש ב-Cloud Scheduler. בוחרים מיקום של 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

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

מחיקת הטריגר

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

gcloud beta events triggers delete trigger-scheduler

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

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

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

בדרך כלל האירועים נוצרים באופן אוטומטי. עם זאת, בשלב הזה תשתמשו ב-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

מוודאים ש-curl Pod פועל בצורה תקינה. אמור להופיע פוד בשם 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 של הברוקר, מריצים את הפקודה הבאה:

kubectl get brokers -n ${NAMESPACE}

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

מתחברים באמצעות SSH אל ה-pod‏ curl שיצרתם קודם:

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

התחברתם ל-pod באמצעות SSH, ועכשיו אתם יכולים לשלוח בקשת 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.

מה נכלל

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