Cloud Run for Anthos 程式碼研究室事件

1. 簡介

現在，建議您使用 Cloud Run for Anthos 適用的 Eventarc 功能。請改為嘗試透過 Eventarc 程式碼研究室中的事件觸發 Cloud Run for Anthos。

Cloud Run for Anthos 活動受《Google Cloud Platform 服務條款》的《正式發布前產品條款》規範。正式發布前產品或許只提供部分支援，而且這類產品的變更可能與其他正式發布前版本不相容。詳情請參閱推出階段說明。

Cloud Run 可讓您在全代管環境中執行無狀態容器。Kubernetes 是以開放原始碼 Knative 打造而成，可讓您透過 Cloud Run 以全代管的方式執行容器，或是透過 Cloud Run for Anthos 在 Google Kubernetes Engine 叢集中執行容器。

Cloud Run for Anthos 的事件可讓您輕鬆將 Cloud Run 服務連結至各種來源的事件。Kubernetes 可讓您建構事件導向的架構，其中微服務的鬆耦合和分佈情形很低。它也能處理事件擷取、提交、安全性、授權和錯誤處理等工作，提升開發人員的靈活性和應用程式彈性。

在本程式碼研究室中，您將瞭解 Cloud Run for Anthos 的事件。具體來說，您將會監聽來自 Cloud Pub/Sub、稽核記錄、Cloud Storage、Cloud Scheduler 的事件，以及如何產生/使用自訂事件。

課程內容

• Cloud Run for Anthos 事件的長期願景
• Cloud Run for Anthos 事件目前狀態
• 建立 Cloud Run 接收器
• 為 Cloud Pub/Sub 建立事件觸發條件
• 為稽核記錄建立事件觸發條件
• 為 Cloud Storage 建立事件觸發條件
• 為 Cloud Scheduler 建立事件觸發條件
• 產生及使用自訂事件

2. 長期願景

當我們採用無伺服器架構時，事件會成為分離微服務通訊的重要環節。Cloud Run for Anthos 事件可讓事件成為 Cloud Run for Anthos 服務的第一級公民，輕鬆建構事件導向的無伺服器應用程式。

透過 Cloud Run for Anthos 事件，您可以將封裝或應用程式建立的事件來源傳送至叢集內和叢集外的用戶，藉此提供可靠、安全且可擴充的非同步事件傳遞服務。

Google Cloud 來源	Google Cloud 自有產品的事件來源
Google 來源	屬於 Google 自有產品的活動來源，例如 Gmail、Hangouts、Android 管理服務等
自訂來源	由使用者自行建立，且非 Google 自有產品的事件來源。這些來源可以是使用者開發的 Knative source，或其他在叢集中執行且可產生 Cloud Event 的應用程式。
第三方來源	非 Google 自有自營的事件來源。這些事件來源包括由第三方供應商、合作夥伴或 OSS 社群擁有及維護的熱門事件來源，例如 GitHub、SAP、Datadog、Pagerduty 等。

為實現跨服務互通性，事件會正規化為 CloudEvents v1.0 格式。CloudEvents 是不受制於供應商的開放規格，以通用格式描述事件資料，使服務、平台和系統互通。

Cloud Run 的事件符合 Knative Eventing，可讓容器與其他以 Knative 為基礎的實作項目相互遷移。這提供了跨雲端的一致架構，可透過宣告方式將事件生產者與事件取用者進行傳輸。

3. 目前狀態

這個預先發布版是第一個提供長期功能的第一個版本。

為了讓使用者建構事件導向的無伺服器應用程式，我們一開始會將重心放在兩個方面：

1. 提供廣泛的 Google Cloud 來源生態系統，可讓 Anthos 叢集上的 Cloud Run 服務對 Google Cloud 服務的事件做出回應。

• 一開始，Google Cloud 來源的事件會透過 Cloud 稽核記錄 (CAL) 傳遞，以利廣泛涵蓋事件來源。這些來源的事件傳送的延遲時間和可用性會綁定 Cloud 稽核記錄。每當發布 Google Cloud 來源的事件時，系統都會建立相應的 Cloud 稽核記錄項目。
• 除了 Cloud 稽核記錄外，在 Cloud Storage、Cloud Pub/Sub 和 Cloud Scheduler 中使用事件時，仍享有第一級支援。隨著我們從使用者歷程和意見回饋中學習到更多相關資訊，我們將持續拓展這個來源生態系統，並提供更多一流來源。

2. 將使用者應用程式和服務發布至命名空間範圍內的叢集-本機代理程式網址，藉此觸發自訂事件。

基礎傳送機制會使用 Cloud Pub/Sub 主題和訂閱項目，讓客戶可以在客戶的產品中看到這些內容Google Cloud 的 Resource Manager 工具 經特別設計，能以程式輔助方式協助您管理專案因此，這項功能提供的傳送保證與 Cloud Pub/Sub 相同。

「事件觸發條件」提供事件的訂閱方式，可讓與觸發條件篩選器相符的事件傳送至觸發條件指向的目的地 (或接收器)。

所有事件都會以 Cloud 事件 v1.0 格式傳送，以便實現跨服務互通性。

我們將持續不斷為 Google Analytics 和其他服務創造更多價值。

4. 設定和需求

自修環境設定

1. 登入 Cloud 控制台建立新專案，或是重複使用現有專案。如果您還沒有 Gmail 或 Google Workspace 帳戶，請先建立帳戶。

注意：只要記住網址 (即 console.cloud.google.com)，即可輕鬆存取 Cloud 控制台。

• 專案名稱是這項專案的顯示名稱。您只要遵守命名慣例，即可任意使用，並隨時更新。
• 所有 Google Cloud 專案的專案 ID 均不得重複，且設定後即無法變更。Cloud 控制台會自動產生一個不重複的字串。但通常是在乎它何在在大部分的程式碼研究室中，您必須參照專案 ID (通常稱為 PROJECT_ID)，因此如果您不喜歡的話，可以再隨機產生一個，或者，您也可以自行嘗試看看是否可用。是「凍結」建立專案後

注意：專案 ID 必須是全域唯一的，選取後即無法使用。您是該 ID 的唯一使用者。刪除專案之後，就無法再使用該 ID。

注意：如果您使用 Gmail 帳戶，請保留預設位置的「無機構」。如果您使用的是 Google Workspace 帳戶，請選擇適合貴機構的位置。

2. 接下來，您需要在 Cloud 控制台中啟用計費功能，才能使用 Google Cloud 資源。

執行這個程式碼研究室並不會產生任何費用，如果有的話。請務必依照「清除所用資源」一節指示本節將說明如何關閉資源，這樣您就不會產生本教學課程結束後產生的費用。Google Cloud 的新使用者符合 $300 美元免費試用計畫的資格。

啟動 Cloud Shell

雖然 Google Cloud 可以從筆記型電腦遠端操作，但在本程式碼研究室中，您將使用 Google Cloud Shell，這是一種在 Cloud 中執行的指令列環境。

在 GCP 控制台的右上方，按一下「Cloud Shell」圖示：

佈建並連線至環境的作業只需幾分鐘的時間。完成後，您應該會看到類似下方的內容：

這部虛擬機器都裝載了您需要的所有開發工具。提供永久的 5 GB 主目錄，而且在 Google Cloud 中運作，大幅提高網路效能和驗證能力。這個研究室中的所有工作都可以透過瀏覽器完成。

5. 啟用 API、設定可用區和平台

設定專案 ID 並安裝 Alpha 版元件

Cloud Shell 中應該已經設定您的專案 ID。如果不是，請確實設定這個專案，並使用該專案 ID 來設定 gcloud：

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

確認已安裝適用於 Alpha 的 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

設定可用區和平台

使用 Cloud Run 事件建立 GKE 叢集之前，請先設定叢集名稱、可用區和平台。例如，這裡將名稱和可用區設為 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. 使用 Cloud Run 事件建立 GKE 叢集

建立執行 Kubernetes >= 1.15.9-gke.26 且已啟用下列外掛程式的 GKE 叢集：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 

這會初始化事件，並建立所需的多個服務帳戶。確認你選取「是」當系統提示您建立服務帳戶時

此時控制層應已正確初始化。您應該會看到四個

cloud-run-events 命名空間中的 Running 狀態、2 (controller-xxx-xxx 和 webhook-xxx-xxx)，以及 knative-eventing 命名空間中的 2 (eventing-controller-xxx-xxx 和 eventing-webhook-xxx-xxx)。如要檢查，請執行下列指令：

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 讀取/寫入 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 接收器

部署 Cloud Run 服務做為事件接收器，藉此記錄其接收的 CloudEvent 內容。

您可以使用 Knative 的 event_display 已經過編譯，並使用 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

部署成功之後，指令列會顯示服務網址。您現在可以在任意瀏覽器視窗中開啟服務網址，查看已部署的容器。

11. 為 Cloud Pub/Sub 建立事件觸發條件

其中一種接收事件的方式為 Cloud Pub/Sub。自訂應用程式可以將訊息發布至 Cloud Pub/Sub，而這些訊息可透過 Cloud Run 事件傳送至 Google 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 執行個體的「記錄檔」部分查看這項資訊：

請注意，「您好」會依照 Pub/Sub 傳送時的 base64 編碼，如要查看原始訊息，您必須解碼。

刪除觸發條件

如有需要，您可以在測試完成後刪除觸發條件。

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：

注意：記錄檢視器 UI 顯示稽核記錄有些延遲。如果資源清單下方沒有「Cloud Pub/Sub Topic」，請稍待片刻，然後再試一次。

執行查詢後，您會看到 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 控制台中查看 Cloud Run 服務的記錄檔，應該會看到收到的事件：

刪除觸發條件和主題

如有需要，您可以在完成測試後刪除觸發條件：

gcloud beta events triggers delete trigger-auditlog

一併刪除主題：

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

13. 為 Cloud Storage 建立事件觸發條件

請設定觸發條件來監聽 Cloud Storage 事件。

建立值區

首先，在已部署 Cloud Run 服務的區域建立 Cloud Storage 值區。你可以將 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」下方。

假設您在上方找到的服務帳戶是 [e-mail]，請將此設為環境變數：

export GCS_SERVICE_ACCOUNT=[e-mail]

然後授權給該服務帳戶，以發布至 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 控制台中查看 Cloud Run 服務的記錄檔，應該會看到收到的事件：

刪除觸發條件

如有需要，您可以在完成測試後刪除觸發條件：

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}

建立觸發條件

如要進一步瞭解從 Google Cloud 來源建構事件觸發條件時所需的參數，請執行下列指令：

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

挑選 Cloud Scheduler 位置來建立排程器：

export SCHEDULER_LOCATION=europe-west1

重要事項：在大多數情況下，APP_ENGINE_LOCATION 和 SCHEDULER_LOCATION 都相同，但兩個位置除外。請注意，在 Cloud Scheduler 中，App Engine 中的 europe-west 和 us-central 這兩個位置分別稱為 europe-west1 和 us-central1。

建立觸發條件，每分鐘建立在 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 控制台中查看 Cloud Run 服務的記錄檔，應該會看到已收到的事件。

刪除觸發條件

如有需要，您可以在完成測試後刪除觸發條件：

gcloud beta events triggers delete trigger-scheduler

15. 自訂事件 (代理程式端點)

在程式碼研究室的這部分，您將使用代理程式產生和使用自訂事件。

建立用來產生事件的 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 的 Pod，其中包含 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 要求給代理程式來建立事件。執行下列指令，提醒自己代理人網址：

kubectl get brokers -n ${NAMESPACE}

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

透過 SSH 連線至您先前建立的 curl Pod：

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:/ ]$

建立活動：

重要事項：請將 <BROKE-URL> 替換成代理人的實際網址。

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 回應。結束與 Ctrl + D 的 SSH 工作階段

查看 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. 恭喜！

恭喜您完成本程式碼研究室。

涵蓋內容

• Cloud Run for Anthos 事件的長期願景
• Cloud Run for Anthos 事件目前狀態
• 建立 Cloud Run 接收器
• 為 Cloud Pub/Sub 建立事件觸發條件
• 為稽核記錄建立事件觸發條件
• 為 Cloud Storage 建立事件觸發條件
• 為 Cloud Scheduler 建立事件觸發條件
• 產生及使用自訂事件