หน้านี้ได้รับการแปลโดย Cloud Translation API

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

1. บทนำ

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

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. วิสัยทัศน์ระยะยาว

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เราจะยังคงสร้างมูลค่าให้มากขึ้นในวิธีการแบบซ้ำๆ ไปจนถึง GA และอื่นๆ

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

การตั้งค่าสภาพแวดล้อมตามเวลาที่สะดวก

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

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

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

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

เริ่มต้น Cloud Shell

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

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

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

เครื่องเสมือนนี้เต็มไปด้วยเครื่องมือการพัฒนาทั้งหมดที่คุณต้องการ โดยมีไดเรกทอรีหลักขนาด 5 GB ที่ใช้งานได้ต่อเนื่องและทำงานบน 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-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

ใน 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)

ขั้นตอนถัดไปคือการตั้งค่าระนาบข้อมูลในเนมสเปซของผู้ใช้ การดำเนินการนี้จะสร้างโบรกเกอร์ที่มีสิทธิ์ที่เหมาะสมในการอ่าน/เขียนจาก/ไปยัง Pub/Sub

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

export NAMESPACE=default

โปรดทราบว่าหากไม่มีเนมสเปซที่ระบุ (กล่าวคือ Namespace ไม่ใช่ค่าเริ่มต้น) คุณจะต้องสร้างเนมสเปซดังนี้

kubectl create namespace ${NAMESPACE}

เริ่มต้นเนมสเปซด้วยข้อมูลลับเริ่มต้นดังนี้

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

สร้างโบรกเกอร์เริ่มต้นในเนมสเปซดังนี้

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

ตรวจสอบว่ามีการสร้างนายหน้าแล้ว โปรดทราบว่าอาจใช้เวลา 2-3 วินาทีก่อนที่นายหน้าจะพร้อม:

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

ในฐานะซิงก์เหตุการณ์ ให้ทำให้บริการ 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 ผ่าน Event 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"

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

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

ลบทริกเกอร์

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

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

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

คุณจะตั้งค่าทริกเกอร์ให้เฝ้าติดตามเหตุการณ์จากบันทึกการตรวจสอบ กล่าวอย่างเจาะจงก็คือ คุณจะพบเหตุการณ์การสร้างหัวข้อ Pub/Sub ในบันทึกการตรวจสอบ

เปิดใช้บันทึกการตรวจสอบ

หากต้องการรับเหตุการณ์จากบริการ คุณต้องเปิดใช้บันทึกการตรวจสอบ เลือก IAM & Admin > Audit Logs จากเมนูด้านซ้ายบน Cloud Console ในรายการบริการ ให้ตรวจสอบ Google Cloud Pub/Sub ดังนี้

ทางด้านขวามือ ให้ตรวจสอบว่าเลือก "ผู้ดูแลระบบ" "อ่านและเขียน" แล้ว คลิกบันทึก

บันทึกการตรวจสอบการทดสอบ

หากต้องการเรียนรู้วิธีระบุพารามิเตอร์ที่คุณต้องตั้งค่าทริกเกอร์จริง ให้ทำการดำเนินการจริง

ตัวอย่างเช่น สร้างหัวข้อ Pub/Sub ดังนี้

gcloud pubsub topics create cre-gke-topic1

ตอนนี้มาดูกันว่าการอัปเดตนี้สร้างบันทึกการตรวจสอบประเภทใด เลือก Logging > Logs Viewer จากเมนูด้านซ้ายบน Cloud Console

ใน 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

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

ขั้นแรก ให้สร้างที่เก็บข้อมูล 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

ลบทริกเกอร์

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

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 และเรียกบริการเป้าหมายด้วยคำสั่งต่อไปนี้

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 นี้ คุณจะต้องสร้างและใช้เหตุการณ์ที่กำหนดเองโดยใช้โบรกเกอร์

สร้าง 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}

สร้างทริกเกอร์

คุณจะสร้างทริกเกอร์ที่มีตัวกรองสำหรับประเภท Cloud Events (ในกรณีนี้คือ 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 ไปยังโบรกเกอร์ เตือนตัวคุณเองเกี่ยวกับ 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
สร้างและใช้เหตุการณ์ที่กำหนดเอง