Funqy Knative Events バインディング

このガイドを完成させるには、以下が必要です:

Minikube 環境で Knative をローカルに設定することは、このガイドの範囲を超えています。Red HatがまとめたKnativeチュートリアル に従うことをお勧めします。このチュートリアルでは、ローカル環境でMinikubeやOpenShift上でKnativeをセットアップする方法を説明しています。

Knative Events をより深く理解するために、Cloud Events の 仕様 を読んでおくと良いでしょう。

Gitレポジトリをクローンするか git clone https://github.com/quarkusio/quarkus-quickstarts.git 、 アーカイブ をダウンロードします。

ソリューションは funqy-knative-events-quickstart ディレクトリ にあります。

クイックスタートは、Cloud Eventを含む HTTP リクエストを curl を使用して Knative Broker に手動で送信することで動作します。Knative Broker はリクエストを受信し、クイックスタートによって構築された Funqy コンテナの起動をトリガーします。イベントは、一連の Funqy 関数の呼び出しをトリガーします。1 つの関数の出力は、別の Funqy 関数の呼び出しをトリガーします。

Knative Events環境内で稼働する場合、Funqy関数は特定のタイプの Cloud Event によってトリガーされます。1つのアプリケーション/デプロイメント内に複数のFunqy関数を持つことができますが、それらは特定のタイプの Cloud Event によってトリガーされなければなりません。このルールの例外は、アプリケーション内にFunqy関数が1つしかない場合です。この場合、イベントは Cloud Event タイプに関係なく、その関数にプッシュされます。

現在、FunqyはJSONベースのデータしか消費できません。それ自体はバイナリモードと構造化モードの両方をサポートしていますが、Cloud EventメッセージのデータコンポーネントはJSONでなければなりません。このJSONは、関数のJavaパラメータやリターンタイプとの間でマーシャル可能でなければなりません。

Knative イベントがどのように Funqy にマップされるかを理解するために、クイックスタートのコードを見てみましょう。クイックスタートコードは、 SimpleFunctionChain.java を開いてください。

最初に見る関数は defaultChain です。

この状態で、Funqy関数はデフォルトの Cloud Event マッピングを持っています。デフォルトでは、 Cloud Event のタイプは、トリガする関数の関数名と一致していなければなりません。関数が出力を返す場合、レスポンスは Cloud Event に変換され、ブローカに返されて他のトリガーにルーティングされます。このレスポンスのデフォルトの Cloud Event タイプは、関数名 + .output です。デフォルトの Cloud Event のソースは、関数名です。

したがって、 defaultChain 関数の場合、この関数をトリガーする Cloud Event のタイプは defaultChain です。これは、タイプが defaultChain.output でイベントソースが defaultChain である新しい Cloud Event をトリガーするレスポンスを生成します。

デフォルトのマッピングはシンプルですが、必ずしもうまくいくとは限りません。このデフォルトのマッピングは設定で変更することができます。次の関数を見てみましょう。

configChain 関数は、 application.properties 内の設定により、 Cloud Event のマッピングが変更されています。

この場合、この構成では、受信するCloud Eventのタイプ defaultChain.output を configChain 関数にマッピングします。 configChain 関数は、そのレスポンスを annotated Cloud Event タイプに、Cloud Event ソース configChain にマッピングします。

Funqy Knative Events エクステンションには、この Cloud Event の関数へのマッピングを行うためのアノテーションも用意されています。 annotatedChain メソッドを見てみましょう。

関数に @CloudEventMapping アノテーションを使用すると、Cloud Event タイプのトリガーとCloud Event レスポンスをマッピングできます。この例では、 annotatedChain 関数は annotated Cloud Event タイプによってトリガされ、レスポンスは lastChainLink タイプと annotated Cloud Eventソースにマッピングされます。

So, if you look at all the functions defined within SimpleFunctionChain you’ll notice that one function triggers the next. The last function that is triggered is lastChainLink.

この機能には2つの注意点があります。一つは、この関数には出力がありません。あなたの関数は出力を返す必要はありません。第二に、この関数には追加の event パラメータがあります。

If you want to know additional information about the incoming Cloud Event, you can inject the io.quarkus.funqy.knative.events.CloudEvent interface using the Funqy @Context annotation. The CloudEvent interface exposes information about the triggering event.

If you look at the POM, you’ll see that it is a typical Quarkus POM that pulls in one Funqy dependency:

Funqy Knative Events support dev mode and unit testing using RestAssured. You can invoke on Funqy Knative Events functions using the same invocation model as Funqy HTTP using normal HTTP requests, or Cloud Event Binary mode, or Structured Mode. All invocation modes are supported at the same time.

そのため、 FunqyTest.java のユニットテストコードを開くと、関数をテストするためのHTTP呼び出しを行うために、単にRestAssuredを使用していることがわかります。

FunqyはQuarkus 開発モードにも対応しています!

まず、Javaアーティファクトをビルドします。

次に、Knativeではdockerイメージが必要なので、続いてそれをビルドする必要があります。

docker build を実行する際には、必ず yourAccountName を docker または quay のアカウント名に置き換えてください。Dockerfileは標準のQuarkusのdockerfileです。特別なKnativeマジックはありません。

イメージをDocker HubやQuayにプッシュする

繰り返しになりますが、 docker push を実行する際には、 yourAccountName を docker または quay のアカウント名に置き換えてください。

The first step is to set up the broker in our namespace. Following is an example command from the Knative cli.

The broker we have created is called default, this broker will receive the cloud events. The broker is also referenced in the function YAML files.

The second step is to define a Kubernetes/OpenShift service to point to the Docker image you created and pushed during build. Take a look at funqy-service.yaml

これはKubernetesの標準的なサービス定義YAMLファイルです。

For our quickstart, one Kubernetes service will contain all functions. There’s no reason you couldn’t break up this quickstart into multiple different projects and deploy a service for each function. For simplicity, and to show that you don’t have to have a deployment per function, the quickstart combines everything into one project, image, and service.

サービスyamlをデプロイします。

The next step is to deploy Knative Event triggers for each of the event types. As noted in the code section, each Funqy function is mapped to a specific Cloud Event type. You must create Knative Event triggers that map a Cloud Event and route it to a specific Kubernetes service. We have 4 different triggers.

defaultChain-trigger.yaml

spec:filter:attributes:type は、 spec:subscriber:ref で定義されている Kubernetes サービスにCloud Eventのタイプをマッピングします。Cloud EventがBrokerにプッシュされると、そのイベントにマッピングされたサービスのスピンアップがトリガーされます。

There’s a trigger YAML file for each of our 4 Funqy functions. Deploy them all:

You’ll need two different terminal windows. One to do a curl request to the Broker, the other to watch the pod log files, so you can see the messages flowing through the Funqy function event chain.

stern ツールがインストールされていることを確認してください。それについての情報は Knative チュートリアルのセットアップを参照してください。Funqy デプロイメントが出力したログを探すために stern を実行します。

別の端末を開きます。まずブローカーのURLを知る必要があります。このコマンドを実行して探します。

This will provide you a URL similar to e.g.: http://broker-ingress.knative-eventing.svc.cluster.local/knativetutorial/default. Remember this URL.

Next thing we need to do is ssh into our Kubernetes cluster so that we can send a curl request to our broker. The following command will create a simple OS pod so we can curl into our functions.

You might need to wait a couple of seconds until the curler pod comes up. Run the following to get bash access to the curler pod:

You will now be in a shell within the Kubernetes cluster. Within the shell, execute this curl command , the broker address is an example and might differ based on your project or broker name.

これは、ブローカーに Knative イベントをポストし、 defaultChain 関数をトリガーします。前述したように、 defaultChain の出力は、 configChain に投稿されたイベントをトリガーにして、 annotatedChain に投稿されたイベントをトリガーにして、最後に lastChainLink 関数をトリガーにします。この流れは stern ウィンドウで見ることができます。以下のようなものが出力されるはずです。