トリガーとシンクの使用¶

前のトピックでは、CloudEvents Playerをイベントソースとして使用して、Brokerにイベントを送信しました。今度は、イベントがBrokerからイベントシンクに移動するようにします。

このトピックでは、CloudEvents Playerをシンクとしてもソースとしても使用します。これは、CloudEvents Playerを使用してイベントを送受信することを意味します。トリガーを使用して、シンクに送信するBrokerのイベントをリッスンします。

最初のトリガーの作成¶

イベントソースからのCloudEventsをリッスンし、CloudEvents Playerアプリでもあるシンクに入れるトリガーを作成します。

knYAML

トリガーを作成するには、次のコマンドを実行します

kn trigger create cloudevents-trigger --sink cloudevents-player  --broker example-broker

期待される出力

Trigger 'cloudevents-trigger' successfully created in namespace 'default'.

次のYAMLをce-trigger.yamlという名前のファイルにコピーします

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: cloudevents-trigger
  annotations:
    knative-eventing-injection: enabled
spec:
  broker: example-broker
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: cloudevents-player

次のコマンドを実行してトリガーを作成します

kubectl apply -f ce-trigger.yaml

期待される出力

trigger.eventing.knative.dev/cloudevents-trigger created

トリガーはどのCloudEventsをリッスンしていますか？

knコマンドで--filterを指定しなかったため、トリガーはBrokerに入ってくるすべてのCloudEventsをリッスンしています。

次の注釈を展開して、フィルターの使用方法を確認してください。

次に、CloudEvents Playerに戻ってイベントを送信すると、CloudEventsがCloudEvents Playerによって送受信されていることがわかります。

CloudEvents Player user interface

変更を確認するには、ページを更新する必要がある場合があります。

CloudEvent属性でフィルタリングしたい場合はどうすればよいですか？

まず、既存のトリガーを削除します

  kn trigger delete cloudevents-trigger

次に、特定のCloudEventタイプをリッスンするトリガーを追加しましょう

  kn trigger create cloudevents-player-filter --sink cloudevents-player  --broker example-broker --filter type=some-type

タイプsome-typeのCloudEventを送信すると、CloudEvents Player UIに反映されます。トリガーは他のすべてのタイプを無視します。

CloudEventの任意の部分でフィルタリングできます。

一部の人はこれを**「イベント駆動型アーキテクチャ」**と呼び、Kubernetesで独自の**「Functions as a Service」**を作成するために使用できます