このページは Cloud Translation API によって翻訳されました。

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 では、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. 長期的なビジョン

サーバーレスアーキテクチャを採用すると、分離されたマイクロサービスの通信においてイベントが不可欠な要素となります。Events for Cloud Run for Anthos は、イベントを Cloud Run for Anthos の主要機能にすることで、イベントドリブンのサーバーレスアプリケーションを簡単に構築できます。

Events for Cloud Run for Anthos を使用すると、パッケージ化またはアプリによって作成されたイベントソースからクラスタ上およびクラスタ外のコンシューマに、信頼性、安全性、スケーラビリティに優れた非同期イベントを配信できます。

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

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

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

3. 現状

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

ユーザーがイベントドリブンのサーバーレスアプリケーションを構築できるようにするために、最初に注目する点は次の 2 つです。

Google Cloud ソースの幅広いエコシステムを提供し、Anthos クラスタの Cloud Run サービスが 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 スコープのクラスタローカルブローカー URL に公開することで、エンドユーザーのアプリケーションとサービスがカスタムイベントを出力できるようにします。

基盤となる配信メカニズムでは、Cloud Pub/Sub のトピックとサブスクリプションが使用されます。できます。そのため、この機能では Cloud Pub/Sub と同じ配信が保証されます。

イベントトリガーを使用すると、イベントをサブスクライブして、トリガーフィルタに一致するイベントが、トリガーがポイントする宛先（またはシンク）に配信されます。

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

Google は、一般提供以降も、反復的な方法でより多くの価値を提供していきます。

4. 設定と要件

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

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

[プロジェクト名] は、このプロジェクトの表示名です。命名規則に従っていれば、自由に使用でき、いつでも更新できます。
プロジェクト ID は、すべての Google Cloud プロジェクトで一意である必要があり、不変です（一度設定すると変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常、それが何であるかは関係ありません。ほとんどの Codelab では、プロジェクト ID を参照する必要があります（通常は PROJECT_ID で識別されます）。気に入らない場合は、別のランダムな ID を生成するか、独自の ID が使用可能かどうかを確認します。その後は「固定」しますプロジェクトが作成されます。

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

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

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 が設定されています。存在しない場合は、プロジェクト 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 イベントを使用して 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 クラスタを作成する

アドオン 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 イベントにはコントロールプレーンとデータプレーンがあり、別々に設定する必要があります。コントロールプレーンを設定するには:

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 イベントを設定する（データプレーン）

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

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

export NAMESPACE=default

指定した 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 の 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

成功すると、コマンドラインにサービス 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 Run サービスに Cloud Pub/Sub トピックにパブリッシュされたイベントをフィルタするトリガーを作成します。

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 コンソールで、左上のメニューから [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] をクリックします。

このクエリを実行すると、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 コンソールで 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 コンソールで 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 で 1 分ごとに実行されるジョブを作成し、ターゲットサービスを呼び出すトリガーを作成します。

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 コンソールで Cloud Run サービスのログを確認すると、受信したイベントがあるはずです。

トリガーを削除する

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

gcloud beta events triggers delete trigger-scheduler

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

Codelab のこのパートでは、ブローカーを使用してカスタムイベントを作成、使用します。

イベントを生成する 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

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 は完了です。

学習した内容

Cloud Run for Anthos のイベントに関する長期的なビジョン
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 イベントを使用して GKE クラスタを作成する

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

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

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. 完了

学習した内容

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

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

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

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

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

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