Google ใช้เทคโนโลยี AI เพื่อแปลเนื้อหาเป็นภาษาที่คุณต้องการ การแปลโดย AI อาจมีข้อผิดพลาด

เหตุการณ์สำหรับ Cloud Run สำหรับ Anthos Codelab

1. บทนำ

เหตุการณ์สำหรับ Cloud Run สำหรับ Anthos อยู่ภายใต้ข้อกำหนดของข้อเสนอช่วงก่อนเวอร์ชันสำหรับผู้ใช้ทั่วไป ในข้อกำหนดในการให้บริการของ Google Cloud Platform ผลิตภัณฑ์ก่อนเวอร์ชันสำหรับผู้ใช้ทั่วไปอาจมีการรองรับที่จำกัด และการเปลี่ยนแปลงผลิตภัณฑ์ก่อนเวอร์ชันสำหรับผู้ใช้ทั่วไปอาจไม่เข้ากันกับผลิตภัณฑ์ก่อนเวอร์ชันสำหรับผู้ใช้ทั่วไปอื่นๆ ดูข้อมูลเพิ่มเติมได้ที่คำอธิบายเกี่ยวกับระยะการเปิดตัว

Cloud Run ช่วยให้คุณเรียกใช้คอนเทนเนอร์แบบไม่เก็บสถานะในสภาพแวดล้อมที่มีการจัดการครบวงจรได้ Cloud Run สร้างขึ้นจาก Knative โอเพนซอร์ส ซึ่งให้คุณเลือกที่จะเรียกใช้คอนเทนเนอร์แบบมีการจัดการครบวงจรด้วย Cloud Run หรือในคลัสเตอร์ Google Kubernetes Engine ด้วย Cloud Run สำหรับ Anthos ได้

เหตุการณ์สำหรับ Cloud Run สำหรับ Anthos ช่วยให้เชื่อมต่อบริการ Cloud Run กับเหตุการณ์จากแหล่งที่มาต่างๆ ได้ง่าย ซึ่งช่วยให้คุณสร้างสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ซึ่ง Microservice มีการเชื่อมต่อแบบหลวมๆ และกระจาย นอกจากนี้ยังจัดการการส่งผ่านข้อมูลเหตุการณ์ การนำส่ง ความปลอดภัย การให้สิทธิ์ และการจัดการข้อผิดพลาดให้คุณ ซึ่งช่วยเพิ่มความคล่องตัวของนักพัฒนาแอปและความยืดหยุ่นของแอปพลิเคชัน

ใน Codelab นี้ คุณจะได้เรียนรู้เกี่ยวกับเหตุการณ์สำหรับ Cloud Run สำหรับ Anthos กล่าวโดยละเอียดคือ คุณจะได้ฟังเหตุการณ์จาก Cloud Pub/Sub, บันทึกการตรวจสอบ, Cloud Storage, Cloud Scheduler และวิธีสร้าง/ใช้เหตุการณ์ที่กำหนดเอง

สิ่งที่คุณจะได้เรียนรู้

วิสัยทัศน์ระยะยาวของเหตุการณ์สำหรับ Cloud Run สำหรับ Anthos
สถานะปัจจุบันของเหตุการณ์สำหรับ Cloud Run สำหรับ Anthos
สร้างซิงก์ Cloud Run
สร้างทริกเกอร์เหตุการณ์สำหรับ Cloud Pub/Sub
สร้างทริกเกอร์เหตุการณ์สำหรับบันทึกการตรวจสอบ
สร้างทริกเกอร์เหตุการณ์สำหรับ Cloud Storage
สร้างทริกเกอร์เหตุการณ์สำหรับ Cloud Scheduler
สร้างและใช้เหตุการณ์ที่กำหนดเอง

2. วิสัยทัศน์ระยะยาว

เมื่อเราใช้สถาปัตยกรรมแบบไร้เซิร์ฟเวอร์ เหตุการณ์จะกลายเป็นส่วนสำคัญของวิธีที่ไมโครเซอร์วิสที่แยกออกจากกันสื่อสาร เหตุการณ์สำหรับ Cloud Run สำหรับ Anthos ทำให้เหตุการณ์เป็นส่วนสำคัญของข้อเสนอ Cloud Run สำหรับ Anthos เพื่อให้สร้างแอปพลิเคชันแบบ Serverless ที่ขับเคลื่อนด้วยเหตุการณ์ได้ง่าย

เหตุการณ์สำหรับ Cloud Run สำหรับ Anthos ช่วยให้การนำส่งเหตุการณ์แบบไม่พร้อมกันที่เชื่อถือได้ ปลอดภัย และปรับขนาดได้จากแหล่งที่มาของเหตุการณ์ที่แพ็กเกจหรือแอปสร้างขึ้นไปยังผู้ใช้ในคลัสเตอร์และนอกคลัสเตอร์

แหล่งข้อมูลของ Google Cloud	แหล่งที่มาของเหตุการณ์ที่เป็นผลิตภัณฑ์ของ Google Cloud
แหล่งข้อมูลของ Google	แหล่งที่มาของเหตุการณ์ที่เป็นผลิตภัณฑ์ของ Google เช่น Gmail, Hangouts, Android Management และอื่นๆ
แหล่งที่มาที่กำหนดเอง	แหล่งที่มาของเหตุการณ์ที่ไม่ใช่ผลิตภัณฑ์ของ Google และสร้างขึ้นโดยผู้ใช้ปลายทางเอง ซึ่งอาจเป็น Knative Sources ที่ผู้ใช้พัฒนาขึ้น หรือแอปอื่นๆ ที่ทำงานในคลัสเตอร์ซึ่งสร้าง Cloud Event ได้
แหล่งที่มาของบุคคลที่สาม	แหล่งที่มาของเหตุการณ์ที่ไม่ได้เป็นของ Google หรือผู้ใช้ปลายทาง ซึ่งรวมถึงแหล่งที่มาของเหตุการณ์ยอดนิยม เช่น Github, SAP, Datadog, Pagerduty ฯลฯ ที่เป็นของและได้รับการบำรุงรักษาโดยผู้ให้บริการ พาร์ทเนอร์ หรือชุมชน OSS บุคคลที่สาม

ระบบจะแปลงเหตุการณ์ให้อยู่ในรูปแบบ CloudEvents v1.0 เพื่อให้ทำงานร่วมกันได้ในบริการต่างๆ CloudEvents เป็นข้อกำหนดแบบเปิดที่ไม่ขึ้นกับผู้ให้บริการ ซึ่งอธิบายข้อมูลเหตุการณ์ในรูปแบบทั่วไป ทำให้สามารถทำงานร่วมกันได้ในบริการ แพลตฟอร์ม และระบบต่างๆ

เหตุการณ์สำหรับ Cloud Run เป็นไปตาม Knative Eventing และอนุญาตให้ย้ายคอนเทนเนอร์ไปยังและจากข้อมูลการติดตั้งใช้งานอื่นๆ ที่อิงตาม Knative ได้ ซึ่งจะช่วยให้มีเฟรมเวิร์กที่สอดคล้องกันและไม่ขึ้นอยู่กับระบบคลาวด์สำหรับการเชื่อมต่อผู้ผลิตเหตุการณ์กับผู้บริโภคเหตุการณ์แบบประกาศ

3. สถานะปัจจุบัน

ตัวอย่างนี้เป็นเวอร์ชันแรกที่มอบฟังก์ชันการทำงานระยะยาวชุดแรก

เรามุ่งเน้น 2 ด้านในเบื้องต้นเพื่อให้ผู้ใช้สร้างแอปพลิเคชันแบบไร้เซิร์ฟเวอร์ที่ขับเคลื่อนด้วยเหตุการณ์ได้

จัดหาระบบนิเวศที่หลากหลายของแหล่งข้อมูล Google Cloud ที่ช่วยให้บริการ Cloud Run ในคลัสเตอร์ Anthos ตอบสนองต่อเหตุการณ์จากบริการของ Google Cloud ได้

ในตอนแรก เหตุการณ์จากแหล่งที่มาของ Google Cloud จะส่งผ่านบันทึก Cloud Audit (CAL) ซึ่งช่วยให้มีแหล่งที่มาของเหตุการณ์ที่หลากหลาย เวลาในการตอบสนองและความพร้อมใช้งานของการนำส่งเหตุการณ์จากแหล่งที่มาเหล่านี้จะเชื่อมโยงกับของบันทึก Cloud Audit ทุกครั้งที่มีการเผยแพร่เหตุการณ์จากแหล่งที่มาของ Google Cloud ระบบจะสร้างรายการบันทึก Cloud Audit ที่เกี่ยวข้อง
นอกจากบันทึก Cloud Audit แล้ว ยังมีการสนับสนุนระดับเฟิร์สคลาสเพื่อใช้เหตุการณ์จาก Cloud Storage, Cloud Pub/Sub และ Cloud Scheduler เราจะขยายระบบนิเวศของแหล่งข้อมูลนี้ต่อไปด้วยแหล่งข้อมูลชั้นนำมากขึ้นเมื่อได้เรียนรู้เพิ่มเติมจากเส้นทางของผู้ใช้และความคิดเห็น

เปิดใช้แอปพลิเคชันและบริการของผู้ใช้ปลายทางเพื่อปล่อยเหตุการณ์ที่กำหนดเองโดยการเผยแพร่ไปยัง URL ของ Broker ในคลัสเตอร์ภายในเนมสเปซ

กลไกการนำส่งพื้นฐานใช้หัวข้อและการสมัครใช้บริการ Cloud Pub/Sub ที่มองเห็นได้ในโปรเจ็กต์ของลูกค้า ดังนั้นฟีเจอร์นี้จึงรับประกันการนำส่งเช่นเดียวกับ Cloud Pub/Sub

ทริกเกอร์เหตุการณ์เป็นวิธีสมัครรับข้อมูลเหตุการณ์เพื่อให้ระบบส่งเหตุการณ์ที่ตรงกับตัวกรองทริกเกอร์ไปยังปลายทาง (หรือ Sink) ที่ทริกเกอร์ชี้ไป

ระบบจะส่งเหตุการณ์ทั้งหมดในรูปแบบ Cloud Events v1.0 เพื่อให้ทำงานร่วมกันได้ในบริการต่างๆ

เราจะมอบคุณค่าเพิ่มเติมอย่างต่อเนื่องในลักษณะการทำซ้ำไปจนถึง GA และหลังจากนั้น

4. การตั้งค่าและข้อกำหนด

การตั้งค่าสภาพแวดล้อมแบบเรียนรู้ด้วยตนเอง

ลงชื่อเข้าใช้ Cloud Console แล้วสร้างโปรเจ็กต์ใหม่หรือใช้โปรเจ็กต์ที่มีอยู่ซ้ำ หากยังไม่มีบัญชี Gmail หรือ Google Workspace คุณต้องสร้างบัญชี

ชื่อโปรเจ็กต์คือชื่อที่แสดงสำหรับโปรเจ็กต์นี้ คุณสามารถใช้ชื่อใดก็ได้และอัปเดตได้ทุกเมื่อ ตราบใดที่คุณปฏิบัติตามรูปแบบการตั้งชื่อ
รหัสโปรเจ็กต์ต้องไม่ซ้ำกันในโปรเจ็กต์ Google Cloud ทั้งหมดและเปลี่ยนแปลงไม่ได้ (เมื่อตั้งค่าแล้วจะเปลี่ยนไม่ได้) คอนโซลระบบคลาวด์จะสร้างสตริงที่ไม่ซ้ำกันโดยอัตโนมัติ ซึ่งโดยปกติแล้วคุณไม่จำเป็นต้องสนใจว่าสตริงนั้นคืออะไร ใน Codelab ส่วนใหญ่ คุณจะต้องอ้างอิงรหัสโปรเจ็กต์ (และโดยปกติจะระบุเป็น PROJECT_ID) ดังนั้นหากไม่ชอบรหัสนี้ ให้สร้างรหัสแบบสุ่มอีกรหัสหนึ่ง หรือคุณจะลองใช้รหัสของคุณเองและดูว่ามีรหัสนั้นหรือไม่ก็ได้ จากนั้นระบบจะ "ตรึง" ไว้เมื่อสร้างโปรเจ็กต์แล้ว

จากนั้นคุณจะต้องเปิดใช้การเรียกเก็บเงินใน Cloud Console เพื่อใช้ทรัพยากร Google Cloud

การทำตาม Codelab นี้ไม่ควรมีค่าใช้จ่ายมากนัก หรืออาจไม่มีเลย โปรดทำตามวิธีการในส่วน "การล้างข้อมูล" ซึ่งจะแนะนำวิธีปิดทรัพยากรเพื่อไม่ให้มีการเรียกเก็บเงินนอกเหนือจากบทแนะนำนี้ ผู้ใช้ Google Cloud รายใหม่มีสิทธิ์เข้าร่วมโปรแกรมช่วงทดลองใช้ฟรีมูลค่า$300 USD

เริ่มต้น Cloud Shell

แม้ว่าคุณจะใช้งาน Google Cloud จากระยะไกลในแล็ปท็อปได้ แต่ใน Codelab นี้คุณจะใช้ Google Cloud Shell ซึ่งเป็นสภาพแวดล้อมบรรทัดคำสั่งที่ทำงานในระบบคลาวด์

จาก GCP Console ให้คลิกไอคอน Cloud Shell ในแถบเครื่องมือด้านขวาบน

การจัดสรรและเชื่อมต่อกับสภาพแวดล้อมจะใช้เวลาเพียงไม่กี่นาที เมื่อเสร็จแล้ว คุณควรเห็นข้อความคล้ายกับตัวอย่างต่อไปนี้

เครื่องเสมือนนี้มาพร้อมเครื่องมือพัฒนาซอฟต์แวร์ทั้งหมดที่คุณต้องการ โดยมีไดเรกทอรีหลักแบบถาวรขนาด 5 GB และทำงานบน Google Cloud ซึ่งช่วยเพิ่มประสิทธิภาพเครือข่ายและการตรวจสอบสิทธิ์ได้อย่างมาก คุณสามารถทำงานทั้งหมดในห้องทดลองนี้ได้โดยใช้เพียงเบราว์เซอร์

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-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 (Control Plane)

เหตุการณ์ Cloud Run มี Control Plane และ Data Plane ที่ต้องตั้งค่าแยกกัน วิธีตั้งค่า Control Plane

ใน Cloud Shell ให้ทำดังนี้

gcloud beta events init

ซึ่งจะเป็นการเริ่มต้นการส่งเหตุการณ์และสร้างบัญชีบริการที่จำเป็นจำนวนหนึ่งด้วย โปรดเลือก "ใช่" เมื่อได้รับข้อความแจ้งให้สร้างบัญชีบริการ

ตอนนี้ควรเริ่มต้นระนาบควบคุมอย่างถูกต้องแล้ว คุณควรเห็นพ็อด 4 พ็อดที่มี

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 (Data Plane)

ขั้นตอนถัดไปคือการตั้งค่า Data Plane ในเนมสเปซของผู้ใช้ ซึ่งจะสร้าง Broker ที่มีสิทธิ์ที่เหมาะสมในการอ่าน/เขียนจาก/ไปยัง 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. สร้างซิงก์ Cloud Run

ในฐานะ Event Sink ให้ติดตั้งใช้งานบริการ 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 และข้อความเหล่านี้จะส่งไปยัง Sink ของ 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 ที่เราสร้างจะบันทึกเนื้อหาของข้อความขาเข้า คุณดูข้อมูลนี้ได้ในส่วนบันทึกของอินสแตนซ์ Cloud Run

โปรดทราบว่า "Hello there" จะได้รับการเข้ารหัส base64 เนื่องจาก Pub/Sub เป็นผู้ส่ง และคุณจะต้องถอดรหัสหากต้องการดูข้อความต้นฉบับที่ส่ง

ลบทริกเกอร์

คุณจะลบทริกเกอร์เมื่อทดสอบเสร็จแล้วก็ได้

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

12. สร้างทริกเกอร์เหตุการณ์สำหรับบันทึกการตรวจสอบ

คุณจะตั้งค่าทริกเกอร์เพื่อฟังเหตุการณ์จากบันทึกการตรวจสอบ กล่าวคือ คุณจะมองหากิจกรรมการสร้างหัวข้อ 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

สร้างที่เก็บข้อมูล

ก่อนอื่น ให้สร้าง 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 นาทีเพื่อให้ระบบเผยแพร่การสร้างทริกเกอร์และเริ่มกรองเหตุการณ์ เมื่อพร้อมแล้ว ระบบจะกรองเหตุการณ์การสร้างและส่งไปยังบริการ

ตอนนี้คุณพร้อมที่จะทริกเกอร์เหตุการณ์แล้ว

อัปโหลดไฟล์แบบสุ่มไปยัง Bucket ของ 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. สร้างทริกเกอร์เหตุการณ์สำหรับ 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

หากตรวจสอบบันทึกของบริการ Cloud Run ใน Cloud Console คุณควรเห็นเหตุการณ์ที่ได้รับ

ลบทริกเกอร์

คุณจะลบทริกเกอร์เมื่อทดสอบเสร็จแล้วก็ได้ โดยทำดังนี้

gcloud beta events triggers delete trigger-scheduler

15. เหตุการณ์ที่กำหนดเอง (ปลายทางของตัวกลาง)

ในส่วนนี้ของโค้ดแล็บ คุณจะสร้างและใช้เหตุการณ์ที่กำหนดเองโดยใช้ Broker

สร้าง Curl Pod เพื่อจัดกิจกรรม

โดยปกติแล้วจะมีการสร้างเหตุการณ์แบบเป็นโปรแกรม อย่างไรก็ตาม ในขั้นตอนนี้ คุณจะใช้ curl เพื่อส่งเหตุการณ์แต่ละรายการด้วยตนเอง และดูว่าผู้บริโภคที่ถูกต้องได้รับเหตุการณ์เหล่านี้อย่างไร

หากต้องการสร้างพ็อดที่ทำหน้าที่เป็นผู้ผลิตเหตุการณ์ ให้เรียกใช้คำสั่งต่อไปนี้

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 ทำงานอย่างถูกต้อง คุณควรเห็นพ็อดชื่อ 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 ไปยังพ็อด curl ที่คุณสร้างไว้ก่อนหน้านี้

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

คุณ 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 เสร็จ

สิ่งที่เราได้พูดถึงไปแล้ว

วิสัยทัศน์ระยะยาวของเหตุการณ์สำหรับ Cloud Run สำหรับ Anthos
สถานะปัจจุบันของเหตุการณ์สำหรับ Cloud Run สำหรับ Anthos
สร้างซิงก์ Cloud Run
สร้างทริกเกอร์เหตุการณ์สำหรับ Cloud Pub/Sub
สร้างทริกเกอร์เหตุการณ์สำหรับบันทึกการตรวจสอบ
สร้างทริกเกอร์เหตุการณ์สำหรับ Cloud Storage
สร้างทริกเกอร์เหตุการณ์สำหรับ Cloud Scheduler
สร้างและใช้เหตุการณ์ที่กำหนดเอง