Cloud Run for Anthos のイベントに関する Codelab

1. はじめに

Cloud Run を使用すると、フルマネージド環境でステートレスコンテナを実行できます。オープンソースの Knative をベースに構築されており、Cloud Run を使用してフルマネージド型でコンテナを実行するか、Cloud Run for Anthos を使用して Google Kubernetes Engine クラスタ内でコンテナを実行するかを選択できます。

Events for Cloud Run for Anthos を使用すると、Cloud Run サービスをさまざまなソースからのイベントに簡単に接続できます。これにより、マイクロサービスが疎結合で分散されたイベントドリブンアーキテクチャを構築できます。また、イベントの取り込み、配信、セキュリティ、認可、エラー処理も自動的に行われるため、デベロッパーのアジリティとアプリケーションの復元力が向上します。

この Codelab では、Events for Cloud Run for Anthos について学習します。具体的には、Cloud Pub/Sub、Cloud Audit Logs、Cloud Storage、Cloud Scheduler からのイベントをリッスンし、カスタムイベントを生成/使用する方法について説明します。

学習内容

Events for Cloud Run for Anthos の長期的なビジョン
Events for Cloud Run for Anthos の現在の状態
Cloud Run シンクを作成する
Cloud Pub/Sub のイベントトリガーを作成する
監査ログのイベントトリガーを作成する
Cloud Storage のイベントトリガーを作成する
Cloud Scheduler のイベントトリガーを作成する
カスタムイベントを生成して使用する

2. 長期的なビジョン

サーバーレスアーキテクチャを採用すると、イベントは、疎結合マイクロサービスが通信する方法の不可欠な部分になります。Events for Cloud Run for Anthos は、イベントを Cloud Run for Anthos サービスのファーストクラスの要素にします。これにより、イベントドリブンサーバーレスアプリケーションを簡単に構築できます。

Events for Cloud Run for Anthos を使用すると、パッケージ化されたイベントソースまたはアプリで作成されたイベントソースから、クラスタ内およびクラスタ外のコンシューマーに、信頼性が高く安全でスケーラブルな非同期イベント配信が可能になります。

Google Cloud ソース	Google Cloud 所有のプロダクトであるイベントソース
Google のソース	Gmail、ハングアウト、Android Management などの Google 所有のプロダクトであるイベントソース
カスタムソース	Google 所有のプロダクトではなく、エンドユーザー自身が作成したイベントソース。これらは、ユーザーが開発した Knative ソースや、Cloud イベントを生成できるクラスタで実行されている他のアプリにすることができます。
サードパーティのソース	Google が所有しておらず、エンドユーザーも所有していないイベントソース。これには、サードパーティプロバイダ、パートナー、OSS コミュニティが所有および保守する Github、SAP、Datadog、Pagerduty などの一般的なイベントソースが含まれます。

イベントは、サービス間の相互運用性を確保するために CloudEvents v1.0 形式に正規化されます。CloudEvents は、イベントデータを一般的な形式で記述するベンダーニュートラルなオープン仕様であり、サービス、プラットフォーム、システム間の相互運用性を実現します。

Cloud Run 用のイベントは Knative Eventing に準拠しており、他の Knative ベースの実装との間でコンテナを移植できます。これにより、イベントプロデューサーとイベントコンシューマーを宣言的に接続するための、クラウドに依存しない一貫したフレームワークが提供されます。

3. 現在の状態

このプレビューは、長期的な機能の最初のセットを提供する最初のバージョンです。

ユーザーがイベントドリブンなサーバーレスアプリケーションを構築できるように、当初は次の 2 つに重点を置きます。

Anthos クラスタ上の Cloud Run サービスが Google Cloud サービスからのイベントに応答できるようにする、幅広い Google Cloud ソースのエコシステムを提供します。

当初、Google Cloud ソースからのイベントは Cloud Audit Logs（CAL）を介して配信され、幅広いイベントソースが利用可能になります。これらのソースからのイベント配信のレイテンシと可用性は、Cloud Audit Logs のレイテンシと可用性に依存します。Google Cloud ソースからのイベントが公開されるたびに、対応する Cloud Audit Logs エントリが作成されます。
Cloud Audit Logs に加えて、Cloud Storage、Cloud Pub/Sub、Cloud Scheduler からイベントを消費するためのファーストクラスのサポートがあります。ユーザージャーニーとフィードバックから得られた知見を基に、今後もファーストクラスのソースを追加して、このソースのエコシステムを拡大していきます。

Namespace スコープのクラスタローカル Broker URL にパブリッシュすることで、エンドユーザーアプリケーションとサービスがカスタムイベントを発行できるようにします。

基盤となる配信メカニズムは、顧客のプロジェクトに表示される Cloud Pub/Sub トピックとサブスクリプションを使用します。そのため、この機能では Cloud Pub/Sub と同じ配信保証が提供されます。

イベントトリガーは、トリガーフィルタに一致するイベントが、トリガーが指す宛先（シンク）に配信されるように、イベントをサブスクライブする方法を提供します。

すべてのイベントは、サービス間の相互運用性を確保するために Cloud Events v1.0 形式で配信されます。

GA 以降も、価値を反復的に提供し続けます。

4. 設定と要件

セルフペース型の環境設定

Cloud コンソールにログインして、新しいプロジェクトを作成するか、既存のプロジェクトを再利用しますGmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

プロジェクト名は、このプロジェクトの参加者に表示される名称です。命名規則に従っていれば、任意の名前を使用でき、いつでも更新できます。
プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常は、この内容を意識する必要はありません。ほとんどの Codelab では、プロジェクト ID（通常は PROJECT_ID と識別されます）を参照する必要があります。生成された ID が好みではない場合は、ランダムに別の ID を生成するか、独自の ID を試して使用可能かどうかを確認できます。プロジェクトの作成後、ID は「フリーズ」されます。

次に、Google Cloud リソースを使用するために、Cloud Console で課金を有効にする必要があります。

このコードラボを実行しても、費用はほとんどかからないはずです。このチュートリアル以外で請求が発生しないように、リソースのシャットダウン方法を説明する「クリーンアップ」セクションの手順に従うようにしてください。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアルプログラムをご利用いただけます。

Cloud Shell の起動

Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。

GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。

プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。

この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホームディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。

5. API を有効にして、ゾーンとプラットフォームを設定する

プロジェクト ID を設定してアルファコンポーネントをインストールする

Cloud Shell 内では、GOOGLE_CLOUD_PROJECT はすでにプロジェクト ID に設定されているはずです。設定されていない場合は、設定されていることと、gcloud がそのプロジェクト ID で構成されていることを確認します。

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

ゾーンとプラットフォームを設定する

Cloud Run Events を使用して 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 Events を使用して GKE クラスタを作成する

次のアドオン（CloudRun、HttpLoadBalancing、HorizontalPodAutoscaling）が有効になっている Kubernetes >= 1.15.9-gke.26 を実行する GKE クラスタを作成します。

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

これにより、イベントが初期化され、必要なサービスアカウントが作成されます。サービスアカウントの作成を求めるメッセージが表示されたら、[はい] を選択してください。

この時点で、コントロールプレーンは適切に初期化されているはずです。次の 4 つの Pod が表示されます。

Running ステータス、cloud-run-events Namespace に 2 つ（controller-xxx-xxx と webhook-xxx-xxx）、knative-eventing Namespace に 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 Events（データプレーン）を設定する

次は、ユーザー Namespace にデータプレーンを設定します。これにより、Pub/Sub からの読み取りと Pub/Sub への書き込みを行う適切な権限を持つブローカーが作成されます。

Cloud Shell 内で、オブジェクトに使用する Namespace の NAMESPACE 環境変数を設定します。次のように、デフォルトの Namespace を使用する場合は、default に設定できます。

export NAMESPACE=default

指定した Namespace が存在しない場合（Namespace がデフォルトでない場合）は、Namespace を作成する必要があります。

kubectl create namespace ${NAMESPACE}

デフォルトの Secret で名前空間を初期化します。

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

Namespace にデフォルトのブローカーを作成します。

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 シンクを作成する

イベントシンクとして、受信した CloudEvent の内容をログに記録する Cloud Run サービスをデプロイします。

Knative のリリースの一部としてすでにコンパイルされ、コンテナイメージがビルドされている Knative の event_display を使用できます。コンテナイメージの詳細は 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 にメッセージをパブリッシュでき、これらのメッセージは Events for 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 インスタンスの [ログ] セクションで確認できます。

「Hello there」は Pub/Sub によって送信されたため、base64 でエンコードされます。送信された元のメッセージを確認するには、デコードする必要があります。

トリガーを削除する

必要に応じて、テストが完了したらトリガーを削除できます。

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

12. 監査ログのイベントトリガーを作成する

監査ログからのイベントをリッスンするトリガーを設定します。具体的には、監査ログで Pub/Sub トピック作成イベントを探します。

監査ログを有効にする

サービスからイベントを受信するには、監査ログを有効にする必要があります。Cloud Console で、左上のメニューから IAM & Admin > Audit Logs を選択します。サービスのリストで、Google Cloud Pub/Sub をオンにします。

右側で、[Admin]、[Read]、[Write] が選択されていることを確認します。[保存] をクリックします。

監査ログをテストする

実際のトリガーを設定するために必要なパラメータを特定し、実際の操作を行う方法を学びます。

たとえば、Pub/Sub トピックを作成します。

gcloud pubsub topics create cre-gke-topic1

次に、この更新によって生成された監査ログの種類を確認します。Cloud Console で、左上のメニューから Logging > Logs Viewer を選択します。

[Query Builder,] で [Cloud Pub/Sub Topic] を選択し、[Add] をクリックします。

クエリを実行すると、Pub/Sub トピックのログが表示されます。そのうちの 1 つは 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 Console で 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] に表示されます。

上記で確認したサービスアカウントが 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 Console で 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

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 Console で Cloud Run サービスのログを確認すると、受信したイベントが表示されます。

トリガーを削除する

必要に応じて、テストが完了したらトリガーを削除できます。

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 が正しく動作していることを確認します。Status=Running を含む curl という Pod が表示されます。

kubectl get pod curl -n ${NAMESPACE}

トリガーを作成する

特定の CloudEvents タイプ（この場合は alpha-type）をフィルタするトリガーを作成します。任意の数の CloudEvents 属性と拡張機能に完全一致フィルタリングを使用できます。フィルタで複数の属性を設定する場合、トリガーでイベントをフィルタするには、イベントにすべての属性が含まれている必要があります。逆に、フィルタを指定しない場合、すべてのイベントが Service で受信されます。

トリガーを作成します。

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

トリガーをテストする

すべてのトリガーを一覧表示して、トリガーが正常に作成されたことを確認します。

gcloud beta events triggers list

Broker に HTTP リクエストを送信してイベントを作成します。次のコマンドを実行して、ブローカーの URL を確認します。

kubectl get brokers -n ${NAMESPACE}

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

前に作成した curl Pod に SSH 接続します。

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 レスポンスが返されます。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. 完了

以上で、この Codelab は完了です。

学習した内容

Events for Cloud Run for Anthos の長期的なビジョン
Events for Cloud Run for Anthos の現在の状態
Cloud Run シンクを作成する
Cloud Pub/Sub のイベントトリガーを作成する
監査ログのイベントトリガーを作成する
Cloud Storage のイベントトリガーを作成する
Cloud Scheduler のイベントトリガーを作成する
カスタムイベントを生成して使用する

Cloud Run for Anthos のイベントに関する Codelab

1. はじめに

学習内容

2. 長期的なビジョン

3. 現在の状態

4. 設定と要件

セルフペース型の環境設定

Cloud Shell の起動

5. API を有効にして、ゾーンとプラットフォームを設定する

プロジェクト ID を設定してアルファ コンポーネントをインストールする

API を有効にする

ゾーンとプラットフォームを設定する

6. Cloud Run Events を使用して GKE クラスタを作成する

7. Cloud Run イベントを設定する（コントロール プレーン）

8. Cloud Run Events（データプレーン）を設定する

9. イベント検出

10. Cloud Run シンクを作成する

Cloud Run へのデプロイ

11. Cloud Pub/Sub のイベント トリガーを作成する

トピックの作成

トリガーを作成する

トリガーをテストする

トリガーを削除する

12. 監査ログのイベント トリガーを作成する

監査ログを有効にする

監査ログをテストする

トリガーを作成する

トリガーをテストする

トリガーとトピックを削除する

13. Cloud Storage のイベント トリガーを作成する

バケットを作成する

Cloud Storage の権限を設定する

トリガーを作成する

トリガーをテストする

トリガーを削除する

14. Cloud Scheduler のイベント トリガーを作成する

App Engine アプリケーションを作成する

トリガーを作成する

トリガーをテストする

トリガーを削除する

15. カスタム イベント（ブローカー エンドポイント）

イベントを生成する Curl Pod を作成する

トリガーを作成する

トリガーをテストする

トリガーを削除する

16. 完了

学習した内容

プロジェクト ID を設定してアルファコンポーネントをインストールする

7. Cloud Run イベントを設定する（コントロールプレーン）

11. Cloud Pub/Sub のイベントトリガーを作成する

12. 監査ログのイベントトリガーを作成する

13. Cloud Storage のイベントトリガーを作成する

14. Cloud Scheduler のイベントトリガーを作成する

15. カスタムイベント（ブローカーエンドポイント）