Serverless Logic
OpenShift Serverless Logic の概要
概要
第1章 スタートガイド リンクのコピーリンクがクリップボードにコピーされました!
1.1. Knative Workflow プラグインを使用したワークフローの作成および実行 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Logic ワークフローを作成し、実行できます。
1.1.1. ワークフローの作成 リンクのコピーリンクがクリップボードにコピーされました!
kn workflow で create コマンドを使用して、現在のディレクトリーに新しい OpenShift Serverless Logic プロジェクトを設定できます。
前提条件
-
OpenShift Serverless Logic
kn-workflowCLI プラグインがインストールされている。
手順
次のコマンドを実行して、新しい OpenShift Serverless Logic ワークフロープロジェクトを作成します。
kn workflow create
$ kn workflow createCopy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトでは、生成されるプロジェクト名は
new-projectです。次のように[-n|--name]フラグを使用してプロジェクト名を変更できます。コマンドの例
kn workflow create --name my-project
$ kn workflow create --name my-projectCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.1.2. ワークフローのローカルでの実行 リンクのコピーリンクがクリップボードにコピーされました!
kn workflow で run コマンドを使用して、現在のディレクトリーに OpenShift Serverless Logic ワークフロープロジェクトをビルドして実行できます。
前提条件
- ローカルマシンに Podman がインストールされている。
-
OpenShift Serverless Logic
kn-workflowCLI プラグインがインストールされている。 - OpenShift Serverless Logic ワークフロープロジェクトを作成している。
手順
次のコマンドを実行して、OpenShift Serverless Logic ワークフロープロジェクトをビルドして実行します。
kn workflow run
$ kn workflow runCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロジェクトの準備が整うと、開発 UI がブラウザーの
localhost:8080/q/dev-uiで自動的に開き、Serverless Workflow Tools タイルが利用可能になります。または、http://localhost:8080/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflowsを使用してツールに直接アクセスすることもできます。
マシン上で実行されるコンテナーを使用して、ワークフローをローカルで実行できます。Ctrl+C でコンテナーを停止します。
1.2. ワークフローのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
Serverless Logic ワークフローは、開発モードとプレビューモードの 2 つのモードでクラスターにデプロイできます。
1.2.1. 開発モードでのワークフローのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
ローカルワークフローを OpenShift Container Platform に開発モードでデプロイできます。このデプロイメントを使用すると、クラスター上で直接ワークフローを実験および変更することができ、変更をほぼ即座に確認できます。開発モードは開発とテストの目的で設計されています。初期の開発段階や新しい変更のテストに最適です。
前提条件
- OpenShift Serverless Logic Operator がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
ワークフロー設定 YAML ファイルを作成します。
workflow-dev.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow アプリケーションをデプロイするには、次のコマンドを入力して YAML ファイルを適用します。
oc apply -f <filename> -n <your_namespace>
$ oc apply -f <filename> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、デプロイメントを確認し、デプロイされたワークフローのステータスを確認します。
oc get workflow -n <your_namespace> -w
$ oc get workflow -n <your_namespace> -wCopy to Clipboard Copied! Toggle word wrap Toggle overflow ワークフローがリストされており、ステータスが
RunningまたはCompletedであることを確認します。次のコマンドを入力して、クラスター内でワークフローを直接編集します。
oc edit sonataflow <workflow_name> -n <your_namespace>
$ oc edit sonataflow <workflow_name> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 編集後、変更を保存します。OpenShift Serverless Logic Operator は変更を検出し、それに応じてワークフローを更新します。
検証
変更が正しく適用されていることを確認するには、次のコマンドを入力してワークフローのステータスとログを確認します。
次のコマンドを実行して、ワークフローのステータスを表示します。
oc get sonataflows -n <your_namespace>
$ oc get sonataflows -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してワークフローログを表示します。
oc logs <workflow_pod_name> -n <your_namespace>
$ oc logs <workflow_pod_name> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
テストが完了したら、次のコマンドを実行してリソースを削除し、必要のないリソースの使用を回避します。
oc delete sonataflow <workflow_name> -n <your_namespace>
$ oc delete sonataflow <workflow_name> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.2. プレビューモードでのワークフローのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
プレビューモードで、ローカルワークフローを OpenShift Container Platform にデプロイできます。これにより、クラスター上で直接ワークフローを試したり変更したりすることができ、変更をほぼ即座に確認できます。プレビューモードは、実稼働環境にデプロイする前の最終テストと検証に使用されます。また、実稼働環境と同様の環境でワークフローがスムーズに実行されるようにします。
前提条件
- クラスターに OpenShift Serverless Logic Operator がインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
プレビューモードでワークフローをデプロイするために、OpenShift Serverless Logic Operator は OpenShift Container Platform 上のビルドシステムを使用し、ワークフローをデプロイするためのイメージを自動的に作成します。
次のセクションでは、OpenShift Serverless Logic Operator と SonataFlow カスタムリソースを使用して、クラスター上にワークフローを構築およびデプロイする方法を説明します。
1.2.2.1. プレビューモードでのワークフローの設定 リンクのコピーリンクがクリップボードにコピーされました!
1.2.2.1.1. ワークフローベースビルダーイメージの設定 リンクのコピーリンクがクリップボードにコピーされました!
シナリオで、セキュリティーや強化制約など、イメージの使用に関する厳格なポリシーが必要な場合は、OpenShift Serverless Logic Operator が最終的なワークフローコンテナーイメージを構築するために使用するデフォルトのイメージを置き換えます。
デフォルトでは、OpenShift Serverless Logic Operator は、公式の Red Hat レジストリーで配布されたイメージを使用してワークフローを構築します。シナリオで、セキュリティーや強化の制約など、イメージの使用に厳格なポリシーが必要な場合は、デフォルトのイメージを置き換えることができます。
このイメージを変更するには、ワークフローをデプロイした namespace 内の SonataFlowPlatform カスタムリソース (CR) を編集します。
前提条件
- クラスターに OpenShift Serverless Logic Operator がインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
次のコマンドを実行して、namespace 内の
SonataFlowPlatformリソースをリスト表示します。oc get sonataflowplatform -n <your_namespace>
$ oc get sonataflowplatform -n <your_namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<your_namespace>を namespace の名前に置き換えます。
次のコマンドを実行して、
SonataFlowPlatformリソースに新しいビルダーイメージを適用します。oc patch sonataflowplatform <name> --patch 'spec:\n build:\n config:\n baseImage: <your_new_image_full_name_with_tag>' -n <your_namespace>
$ oc patch sonataflowplatform <name> --patch 'spec:\n build:\n config:\n baseImage: <your_new_image_full_name_with_tag>' -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、
SonataFlowPlatformCR が正しく修正されていることを確認します。oc describe sonataflowplatform <name> -n <your_namespace>
$ oc describe sonataflowplatform <name> -n <your_namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<name>はSonataFlowPlatformリソースの名前に、<your_namespace>を namespace の名前に置き換えます。
spec.build.configの下のbaseImageフィールドに新しいイメージが反映されていることを確認します。
1.2.2.1.2. ベースビルダー Dockerfile のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Logic Operator は openshift-serverless-logic OpenShift Serverless Logic Operator インストール namespace の logic-operator-rhel8-builder-config config map カスタムリソース (CR) を使用して、ワークフロービルドプロセスを設定および実行します。この config map 内の Dockerfile エントリーを変更して、Dockerfile を要件に合わせて調整できます。
Dockerfile を変更すると、ビルドプロセスが中断される可能性があります。
この例は参考用です。実際のバージョンは若干異なる可能性があります。この例をインストールに使用しないでください。
例: logic-Operator-rhel8-builder-config config map CR
1.2.2.1.3. リソース要件の変更 リンクのコピーリンクがクリップボードにコピーされました!
ワークフロー namespace で SonataFlowPlatform リソースを作成または編集することにより、内部ビルダー Pod のリソース要件を指定できます。
SonataFlowPlatform リソースの例
namespace ごとに 1 つの SonataFlowPlatform リソースのみが許可されます。別のリソースを作成する代わりに、OpenShift Serverless Logic Operator によって作成されたリソースを取得して編集します。
特定のワークフローのリソース要件を微調整できます。各ワークフローインスタンスには、ワークフローと同じ名前で作成された SonataFlowBuild インスタンスがあります。SonataFlowBuild カスタムリソース (CR) を編集し、次のようにパラメーターを指定できます。
SonataFlowBuild CR の例
これらのパラメーターは、新しいビルドインスタンスにのみ適用されます。
1.2.2.1.4. 内部ビルダーに引数を渡す リンクのコピーリンクがクリップボードにコピーされました!
ビルド引数を SonataFlowBuild インスタンスに渡すか、SonataFlowPlatform リソースでデフォルトのビルド引数を設定することで、ビルドプロセスをカスタマイズできます。
前提条件
- クラスターに OpenShift Serverless Logic Operator がインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
次のコマンドを実行して、既存の
SonataFlowBuildインスタンスを確認します。oc get sonataflowbuild <name> -n <namespace>
$ oc get sonataflowbuild <name> -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<name>はSonataFlowBuildインスタンスの名前に、<namespace>を namespace に置き換えます。
次のコマンドを実行して、
SonataFlowBuildインスタンスにビルド引数を追加します。oc edit sonataflowbuild <name> -n <namespace>
$ oc edit sonataflowbuild <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow SonataFlowBuildインスタンスの.spec.buildArgsフィールドの下に、必要なビルド引数を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 既存の
SonataFlowBuildインスタンスの名前。
ファイルを保存して終了します。
更新された設定で新しいビルドが開始されます。
次のコマンドを実行して、
SonataFlowPlatformリソースにデフォルトのビルド引数を設定します。oc edit sonataflowplatform <name> -n <namespace>
$ oc edit sonataflowplatform <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow SonataFlowPlatformリソースの.spec.buildArgsフィールドに、必要なビルド引数を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 既存の
SonataFlowPlatformリソースの名前。
- ファイルを保存して終了します。
1.2.2.1.5. 内部ビルダーでの環境変数の設定 リンクのコピーリンクがクリップボードにコピーされました!
SonataFlowBuild 内部ビルダー Pod に環境変数を設定できます。これらの変数はビルドコンテキストに対してのみ有効であり、最終的にビルドされたワークフローイメージには設定されません。
前提条件
- クラスターに OpenShift Serverless Logic Operator がインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
次のコマンドを実行して、既存の
SonataFlowBuildインスタンスを確認します。oc get sonataflowbuild <name> -n <namespace>
$ oc get sonataflowbuild <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <name>はSonataFlowBuildインスタンスの名前に、<namespace>を namespace に置き換えます。次のコマンドを実行して、
SonataFlowBuildインスタンスを編集します。oc edit sonataflowbuild <name> -n <namespace>
$ oc edit sonataflowbuild <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow SonataFlowBuildインスタンスの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルを保存して終了します。
更新された設定で新しいインスタンスが起動します。
あるいは、
SonataFlowPlatformで環境を設定して、すべての新しいビルドインスタンスがその設定をテンプレートとして使用するようにすることもできます。SonataFlowPlatformインスタンスの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.2.1.6. ベースビルダーイメージの変更 リンクのコピーリンクがクリップボードにコピーされました!
logic-Operator-rhel8-builder-config config map を編集することで、OpenShift Serverless Logic Operator によって使用されるデフォルトのビルダーイメージを変更できます。
前提条件
- クラスターに OpenShift Serverless Logic Operator がインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
次のコマンドを実行して、
logic-Operator-rhel8-builder-configconfig map を編集します。oc edit cm/logic-operator-rhel8-builder-config -n openshift-serverless-logic
$ oc edit cm/logic-operator-rhel8-builder-config -n openshift-serverless-logicCopy to Clipboard Copied! Toggle word wrap Toggle overflow dockerfile エントリーを変更します。
エディターで、Dockerfile エントリーを見つけて、最初の行を目的のイメージに変更します。
例
data: Dockerfile: | FROM registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.33.0 # Change the image to the desired onedata: Dockerfile: | FROM registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.33.0 # Change the image to the desired oneCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存します。
1.2.2.2. ワークフローの構築とデプロイ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform で SonataFlow カスタムリソース (CR) を作成し、OpenShift Serverless Logic Operator がワークフローをビルドしてデプロイすることができます。
前提条件
- クラスターに OpenShift Serverless Logic Operator がインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
次のようなワークフロー YAML ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
SonataFlowワークフロー定義を OpenShift Container Platform namespace に適用します。oc apply -f <workflow-name>.yaml -n <your_namespace>
$ oc apply -f <workflow-name>.yaml -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow greetings-workflow.yamlファイルのコマンドの例:oc apply -f greetings-workflow.yaml -n workflows
$ oc apply -f greetings-workflow.yaml -n workflowsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、すべてのビルド設定をリスト表示します。
oc get buildconfigs -n workflows
$ oc get buildconfigs -n workflowsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ビルドプロセスのログを取得します。
oc logs buildconfig/<workflow-name> -n <your_namespace>
$ oc logs buildconfig/<workflow-name> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow greetings-workflow.yamlファイルのコマンドの例:oc logs buildconfig/greeting -n workflows
$ oc logs buildconfig/greeting -n workflowsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
デプロイメントを確認するには、次のコマンドを実行してすべての Pod をリスト表示します。
oc get pods -n <your_namespace>
$ oc get pods -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワークフローに対応する Pod が実行されていることを確認します。
次のコマンドを実行して、実行中の Pod とそのログを確認します。
oc logs pod/<pod-name> -n workflows
$ oc logs pod/<pod-name> -n workflowsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.2.3. ワークフローのデプロイメントの検証 リンクのコピーリンクがクリップボードにコピーされました!
ワークフロー Pod からテスト HTTP 呼び出しを実行して、OpenShift Serverless Logic ワークフローが実行されていることを確認できます。
前提条件
- クラスターに OpenShift Serverless Logic Operator がインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
次のようなワークフロー
YAMLファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ワークフローサービスのルートを作成します。
oc expose svc/<workflow-service-name> -n workflows
$ oc expose svc/<workflow-service-name> -n workflowsCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、ワークフローサービスにアクセスするためのパブリック URL を作成します。
次のコマンドを実行して、パブリック URL の環境変数を設定します。
WORKFLOW_SVC=$(oc get route/<workflow-service-name> -n <namespace> --template='{{.spec.host}}')$ WORKFLOW_SVC=$(oc get route/<workflow-service-name> -n <namespace> --template='{{.spec.host}}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ワークフローに HTTP 呼び出しを行い、サービスに POST リクエストを送信します。
curl -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' -d '{<"your": "json_payload">}' http://$WORKFLOW_SVC/<endpoint>$ curl -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' -d '{<"your": "json_payload">}' http://$WORKFLOW_SVC/<endpoint>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力は、ワークフローが実行中の場合に予想される応答の例を示しています。
1.2.2.4. ビルドの再実行 リンクのコピーリンクがクリップボードにコピーされました!
ビルドを再実行するには、SonataFlowBuild インスタンスに sonataflow.org/restartBuild: true アノテーションを追加または編集します。ワークフローまたは初期ビルドリビジョンに問題がある場合は、ビルドを再実行する必要があります。
前提条件
- クラスターに OpenShift Serverless Logic Operator がインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
次のコマンドを実行して、
SonataFlowBuildインスタンスが存在するかどうかを確認します。oc get sonataflowbuild <name> -n <namespace>
$ oc get sonataflowbuild <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
SonataFlowBuildインスタンスを編集します。oc edit sonataflowbuild/<name> -n <namespace>
$ oc edit sonataflowbuild/<name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <name>はSonataFlowBuildインスタンスの名前に、<namespace>はワークフローがデプロイされている namespace に置き換えます。ビルドを再実行するには、
sonataflow.org/restartBuild: trueアノテーションを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow このアクションにより、OpenShift Serverless Logic Operator がトリガーされ、ワークフローの新しいビルドが開始されます。
ビルドプロセスを監視するには、次のコマンドを実行してビルドログを確認します。
oc logs buildconfig/<name> -n <namespace>
$ oc logs buildconfig/<name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <name>はSonataFlowBuildインスタンスの名前に、<namespace>はワークフローがデプロイされている namespace に置き換えます。
1.2.3. ワークフローの編集 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Logic Operator がワークフローサービスをデプロイすると、ランタイムプロパティーを保存するための 2 つの config map が作成されます。
-
ユーザープロパティー:
SonataFlowオブジェクトをもとに名前が付けられ、接尾辞が-propsであるConfigMapで定義されます。たとえば、ワークフロー名がgreetingの場合、ConfigMap名はgreeting-propsになります。 -
管理プロパティー:
SonataFlowオブジェクトをもとに名前が付けられ、接尾辞が-managed-propsであるConfigMapで定義されます。たとえば、ワークフロー名がgreetingの場合、ConfigMap名はgreeting-managed-propsになります。
管理プロパティーは常にキー名が同じユーザープロパティーをすべてオーバーライドし、ユーザーが編集することはできません。すべての変更は、次の調整サイクルで Operator によって上書きされます。
前提条件
- OpenShift Serverless Logic Operator がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
以下のコマンドを実行して
ConfigMapを開き、編集します。oc edit cm <workflow_name>-props -n <namespace>
$ oc edit cm <workflow_name>-props -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <workflow_name>はワークフローの名前に、<namespace>はワークフローがデプロイされている namespace に置き換えます。application.propertiesセクションにプロパティーを追加します。ConfigMap内に保存されるワークフロープロパティーの例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator が設定をデフォルトの設定に置き換えないように、プロパティーが正しくフォーマットされていることを確認してください。
- 必要な変更を行った後、ファイルを保存してエディターを終了します。
1.2.4. ワークフローのテスト リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Logic ワークフローが正しく実行されていることを確認するには、関連する Pod からテスト HTTP 呼び出しを実行できます。
前提条件
- OpenShift Serverless Logic Operator がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
次のコマンドを実行して、namespace 内の指定されたサービスへのルートを作成します。
oc expose svc <service_name> -n <namespace>
$ oc expose svc <service_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しく公開されたサービスの URL を取得するには、次のコマンドを実行します。
WORKFLOW_SVC=$(oc get route/<service_name> --template='{{.spec.host}}')$ WORKFLOW_SVC=$(oc get route/<service_name> --template='{{.spec.host}}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、テスト HTTP 呼び出しを実行し、
POSTリクエストを送信します。curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '<request_body>' http://$WORKFLOW_SVC/<endpoint>
$ curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '<request_body>' http://$WORKFLOW_SVC/<endpoint>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 応答を検証して、ワークフローが期待どおりに機能していることを確認します。
1.2.5. ワークフローのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Logic Operator は、ヘルスチェックプローブを備えた Pod をデプロイし、ワークフローが正常な状態で実行されるようにします。変更したことが原因でこれらのヘルスチェックに失敗すると、Pod は応答を停止します。
前提条件
- OpenShift Serverless Logic Operator がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
次のコマンドを実行してワークフローのステータスを確認します。
oc get workflow <name> -o jsonpath={.status.conditions} | jq .$ oc get workflow <name> -o jsonpath={.status.conditions} | jq .Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワークフローのデプロイメントからログを取得して分析するには、次のコマンドを実行します。
oc logs deployment/<workflow_name> -f
$ oc logs deployment/<workflow_name> -fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.6. ワークフローの削除 リンクのコピーリンクがクリップボードにコピーされました!
oc delete コマンドを使用して、現在のディレクトリーで OpenShift Serverless Logic ワークフローを削除できます。
前提条件
- OpenShift Serverless Logic Operator がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)がインストールされている。
手順
-
削除するワークフローを定義する正しいファイルがあることを確認します。たとえば、
workflow.yamlなどです。 oc deleteコマンドを実行して、指定した namespace からワークフローを削除します。oc delete -f <your_file> -n <your_namespace>
$ oc delete -f <your_file> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <your_file>は、ワークフローファイルの名前に、<your_namespace>を namespace に置き換えます。
第2章 サービスの管理 リンクのコピーリンクがクリップボードにコピーされました!
2.1. OpenAPI サービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenAPI 仕様 (OAS) は、HTTP API 向けに、プログラミング言語に依存しない、標準のインターフェイスを定義します。ソースコード、追加のドキュメント、またはネットワークトラフィックの検査にアクセスしなくても、サービスの機能を理解することができます。OpenAPI を使用してサービスを定義すると、最小限の実装ロジックを使用してサービスを理解し、操作することができます。インターフェイスの記述によって低レベルのプログラミングが簡素化されるのと同様に、OpenAPI 仕様 によってサービス呼び出し時の推測作業がなくなります。
2.1.1. OpenAPI 関数定義 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Logic を使用すると、ワークフローは関数内の OpenAPI 仕様参照を使用してリモートサービスと対話できます。
OpenAPI 関数定義の例
operation 属性は、次のパラメーターで構成される string です。
-
URI: エンジンはこれを使用して、classpathなどの仕様ファイルを検索します。 - Operation identifier: この識別子は OpenAPI 仕様ファイルにあります。
OpenShift Serverless Logic は以下の URI スキームをサポートします。
-
classpath: アプリケーションプロジェクトの
src/main/resourcesフォルダーにあるファイルに使用します。classpathはデフォルトの URI スキームです。URI スキームを定義しない場合、ファイルの場所はsrc/main/resources/myopenapifile.yamlになります。 - file: ファイルシステム内にあるファイルに使用します。
- http または https: リモートにあるファイルに使用します。
ビルド時に OpenAPI 仕様ファイルが利用可能であることを確認します。OpenShift Serverless Logic は、実行時にリクエストを送信するために内部コード生成機能を使用します。アプリケーションイメージのビルド後、OpenShift Serverless Logic はこれらのファイルにアクセスできません。
ワークフローに追加する OpenAPI サービスに仕様ファイルがない場合は、仕様ファイルを作成するか、サービスを更新してファイルを生成して公開できます。
2.1.2. OpenAPI 仕様に基づく REST リクエストの送信 リンクのコピーリンクがクリップボードにコピーされました!
OpenAPI 仕様ファイルに基づく REST リクエストを送信するには、次の手順を実行する必要があります。
- 関数参照を定義する
- ワークフロー状態で定義された関数にアクセスする
前提条件
- OpenShift Serverless Logic Operator がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
- OpenAPI 仕様ファイルにアクセスできる。
手順
OpenAPI 関数を定義するには、以下を行います。
- 呼び出す予定のサービスの OpenAPI 仕様ファイルを識別してアクセスします。
OpenAPI 仕様ファイルを、
<project_application_dir>/specsなどのワークフローサービスディレクトリーにコピーします。次の例は、乗算 REST サービスの OpenAPI 仕様を示しています。
乗算 REST サービス OpenAPI 仕様の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワークフローで関数を定義するには、OpenAPI 仕様の
operationIdを使用して、関数定義内の目的の操作を参照します。温度変換アプリケーションにおける関数定義の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
関数定義が、
<project_application_dir>/specsディレクトリーに保存されている OpenAPI ファイルへの正しいパスを参照していることを確認します。
ワークフロー状態で定義された関数にアクセスします。
- 追加した関数定義を呼び出すワークフローアクションを定義します。各アクションが以前に定義された関数を参照していることを確認します。
特定の関数を名前で参照するには、
functionRef属性を使用します。OpenAPI 仕様で定義されたパラメーターを使用して、functionRef内の引数をマップします。次の例は、リクエスト本文ではなくリクエストパス内のパラメーターのマッピングを示しています。次の PetStore API の例を参照できます。
ワークフローで関数引数をマッピングする例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
リクエスト内のパラメーターの構造化方法を理解するには、OpenAPI 仕様の
Operation Objectのセクションを確認してください。 -
jq式を使用してペイロードからデータを抽出し、必要なパラメーターにマップします。エンジンが OpenAPI 仕様に従ってパラメーター名をマッピングしていることを確認します。 本文ではなくリクエストパス内のパラメーターを必要とする操作については、OpenAPI 仕様のパラメーター定義を参照してください。
リクエスト本文ではなくリクエストパスでパラメーターをマッピングする方法の詳細は、次の PetStore API の例を参照してください。
パスパラメーターのマッピングの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下は関数の呼び出し例です。リクエストパスに
petIdという名前のパラメーターが 1 つだけ追加されています。PetStore 関数の呼び出し例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.3. OpenAPI サービスのエンドポイント URL の設定 リンクのコピーリンクがクリップボードにコピーされました!
ワークフロー状態の関数定義にアクセスした後、OpenAPI サービスのエンドポイント URL を設定できます。
前提条件
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
- OpenShift Serverless Logic プロジェクトを作成している。
- OpenAPI 仕様ファイルにアクセスできる。
- ワークフローで関数定義を定義している。
- ワークフロー状態で定義された関数にアクセスできる。
手順
-
設定する OpenAPI 仕様ファイルを見つけます。例:
substraction.yaml -
.などの特殊文字をアンダースコアに置き換え、文字を小文字に変換して、ファイル名を有効な設定キーに変換します。たとえば、substraction.yamlをsubstraction_yamlに変更します。 設定キーを定義するには、変換されたファイル名を REST クライアント設定キーとして使用します。次の例に示すように、このキーを環境変数として設定します。
quarkus.rest-client.subtraction_yaml.url=http://myserver.com
quarkus.rest-client.subtraction_yaml.url=http://myserver.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow application.propertiesファイルで URL がハードコーディングされるのを防ぐには、次の例に示すように、環境変数の置換を使用します。quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、以下が適用されます。
-
Configuration Key:
quarkus.rest-client.subtraction_yaml.url - 環境変数: SUBTRACTION_URL
-
フォールバック URL:
http://myserver.com
-
Configuration Key:
-
システムまたはデプロイメント環境で
(SUBTRACTION_URL)環境変数が設定されていることを確認します。変数が見つからない場合、アプリケーションはフォールバック URL(http://myserver.com)を使用します。 設定キーと URL 置換を
application.propertiesファイルに追加します。quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}Copy to Clipboard Copied! Toggle word wrap Toggle overflow - アプリケーションをデプロイまたは再起動して、新しい設定を適用します。
2.2. OpenAPI サービスエンドポイントの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Logic は kogito.sw.operationIdStrategy プロパティーを使用して、OpenAPI ドキュメントに定義されたサービスを呼び出すための REST クライアントを生成します。このプロパティーは、REST クライアント設定の設定キーがどのように導出されるかを決定します。
kogito.sw.operationIdStrategy プロパティーは、FILE_NAME、FULL_URI、FUNCTION_NAME、および SPEC_TITLE の値をサポートします。
FILE_NAMEOpenShift Serverless Logic は、OpenAPI ドキュメントファイル名を使用して設定キーを作成します。キーはファイル名に基づいており、特殊文字はアンダースコアに置き換えられます。
設定例:
quarkus.rest-client.stock_portfolio_svc_yaml.url=http://localhost:8282/
quarkus.rest-client.stock_portfolio_svc_yaml.url=http://localhost:8282/1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenAPI ファイルパスは
<project_application_dir>/specs/stock-portfolio-svc.yamlです。REST クライアントの URL を設定する生成されたキーはstock_portfolio_svc_yamlです。
FULL_URIOpenShift Serverless Logic は、OpenAPI ドキュメントの完全な URI パスを設定キーとして使用します。完全な URI はサニタイズされ、キーが形成されます。
Serverless ワークフローの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定例:
quarkus.rest-client.apicatalog_apis_123_document.url=http://localhost:8282/
quarkus.rest-client.apicatalog_apis_123_document.url=http://localhost:8282/1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- URI パスは
https://my.remote.host/apicatalog/apis/123/documentです。REST クライアントの URL を設定する生成キーはapicatalog_apis_123_documentです。
FUNCTION_NAMEOpenShift Serverless Logic は、ワークフロー ID と OpenAPI ドキュメントを参照する関数名を組み合わせて、設定キーを生成します。
Serverless ワークフローの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定例:
quarkus.rest-client.myworkflow_myfunction.url=http://localhost:8282/
quarkus.rest-client.myworkflow_myfunction.url=http://localhost:8282/1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ワークフロー ID は
myworkflowです。関数名はmyfunctionです。REST クライアントの URL を設定する生成キーはmyworkflow_myfunctionです。
SPEC_TITLEOpenShift Serverless Logic は、OpenAPI ドキュメントの
info.title値を使用して設定キーを作成します。タイトルは、サニタイズされ、キーが作成されます。OpenAPI ドキュメントの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定例:
quarkus.rest-client.stock-service_API.url=http://localhost:8282/
quarkus.rest-client.stock-service_API.url=http://localhost:8282/1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenAPI ドキュメントのタイトルは
stock-service APIです。REST クライアントの URL を設定する生成キーはstock-service_APIです。
2.2.1. URI エイリアスの使用 リンクのコピーリンクがクリップボードにコピーされました!
kogito.sw.operationIdStrategy プロパティーの代わりに、workflow-uri-definitions カスタムエクステンションを使用してエイリアスを URI に割り当てることができます。このエイリアスは設定プロセスを簡素化し、REST クライアント設定および関数定義の設定キーとして使用できます。
workflow-uri-definitions 拡張機能を使用すると、URI をエイリアスにマップして、ワークフロー全体と設定ファイルで参照できるようになります。このアプローチは、URI とその設定を一元管理する方法を提供します。
前提条件
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
- OpenAPI 仕様ファイルにアクセスできる。
手順
workflow-uri-definitions拡張をワークフローに追加します。このエクステンション内で、URI のエイリアスを作成します。ワークフローの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1
- 拡張 ID を
workflow-uri-definitionsに設定します。 - 2
remoteCatalogエイリアスを URI (例:https://my.remote.host/apicatalog/apis/123/documentURI) にマッピングして、エイリアス定義を設定します。- 3
- オペレーション ID (例:
operation1およびoperation2のオペレーション ID) を持つremoteCatalogエイリアスを使用して関数操作を設定します。application.propertiesファイルで、ワークフローで定義されたエイリアスを使用して REST クライアントを設定します。プロパティー例
quarkus.rest-client.remoteCatalog.url=http://localhost:8282/
quarkus.rest-client.remoteCatalog.url=http://localhost:8282/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 前の例では、設定キーは
quarkus.rest-client.remoteCatalog.urlに設定され、URL はhttp://localhost:8282/に設定されており、REST クライアントはremoteCatalogエイリアスを参照してこれを使用します。ワークフローでは、URI を操作する関数を定義するときにエイリアスを使用します。
ワークフローの例 (続き):
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. サービスのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
ワークフローオーケストレーションを維持するには、OpenAPI 関数を使用するような HTTP ベースの関数呼び出しを効率的にトラブルシューティングすることが重要です。
問題を診断するには、HTTP リクエストとレスポンスをトレースできます。
2.3.1. HTTP リクエストとレスポンスのトレース リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Logic は、Apache HTTP クライアントを使用して HTTP リクエストとレスポンスをトレースします。
前提条件
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
- OpenAPI 仕様ファイルにアクセスできる。
- HTTP リクエストとレスポンスを関連付けるためのワークフロー定義とインスタンス ID にアクセスできる。
- HTTP サービス呼び出しが発生しているアプリケーションのログ設定にアクセスできる。
手順
HTTP リクエストとレスポンスをトレースするために、OpenShift Serverless Logic は次のプロパティーを設定して Apache HTTP クライアントを使用します。
# Turning HTTP tracing on quarkus.log.category."org.apache.http".level=DEBUG
# Turning HTTP tracing on quarkus.log.category."org.apache.http".level=DEBUGCopy to Clipboard Copied! Toggle word wrap Toggle overflow Apache HTTP クライアントのデバッグを有効にするには、アプリケーションの
application.propertiesファイルに次の設定を追加します。quarkus.log.category."org.apache.http".level=DEBUG
quarkus.log.category."org.apache.http".level=DEBUGCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ログ設定の変更を反映するには、アプリケーションを再起動します。
再起動後、ログで HTTP リクエストトレースを確認します。
トレースされた HTTP リクエストのログの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow リクエストログに続く HTTP レスポンストレースのログを確認します。
トレースされた HTTP レスポンスのログの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第3章 サポートサービス リンクのコピーリンクがクリップボードにコピーされました!
3.1. ジョブサービス リンクのコピーリンクがクリップボードにコピーされました!
ジョブサービスは、クラウド環境でタスクをスケジュールして実行します。独立したサービスがこれらのタスクを実装し、HTTP 呼び出しや Knative イベント配信など、サポートされている任意の対話モードを通じて開始できます。
OpenShift Serverless Logic では、Job サービスはタイムトリガーアクションの実行を制御します。したがって、ワークフローで使用できる時間ベースの状態はすべて、ワークフローと Job サービス間の対話によって処理されます。
たとえば、ワークフローの実行が、設定されたタイムアウトのある状態に到達し、対応するジョブが Job サービスに作成されます。タイムアウトに達すると、HTTP コールバックが実行されてワークフローに通知します。
Job サービスの主な目的は、実行する必要のあるスケジュールされたジョブなどのアクティブなジョブを管理することです。ジョブが最終状態になると、Job サービスはそれを削除します。ジョブ情報を永続的なリポジトリーに保持するために、Job サービスは、Data Index Service などの外部サービスで記録できるステータス変更イベントを生成します。
OpenShift Serverless Operator を使用してワークフローをデプロイする場合は、Job サービスを手動でインストールしたり、設定したりする必要はありません。Operator はこれらのタスクを自動的に処理し、各ワークフローがこれに接続するために必要な設定をすべて管理します。
3.1.1. Job サービスリーダーの選出プロセス リンクのコピーリンクがクリップボードにコピーされました!
Job サービスはシングルトンサービスとして動作します。つまり、1 つのアクティブなインスタンスのみが、ジョブをスケジュールおよび実行できることを意味します。
複数のインスタンスが実行されている可能性のあるクラウドにサービスがデプロイされる際の競合を防ぐために、Job サービスはリーダー選出プロセスをサポートします。リーダーとして選出されたインスタンスのみが、ジョブを受信およびスケジュールするために外部通信を管理します。
リーダー以外のインスタンスは、スタンバイ状態で非アクティブのままになりますが、選出プロセスを通じてリーダーになる試みは継続されます。新しいインスタンスの起動時に、リーダーシップがすぐには想定されるわけではありません。代わりに、リーダーの選出プロセスを入力して、リーダーロールを引き継ぐことが可能か判断します。
現在のリーダーが応答しなくなったり、シャットダウンしたりした場合に、実行中の別のインスタンスがリーダーとして引き継ぎます。
このリーダー選出メカニズムでは、基盤となる永続バックエンドが使用されます。これは現在、PostgreSQL 実装でのみサポートされています。
3.2. データインデックスサービス リンクのコピーリンクがクリップボードにコピーされました!
データインデックスサービスは、ワークフローインスタンスとそれに関連付けられたジョブに関連するデータを保存する専用のサポートサービスです。このサービスは、GraphQL エンドポイントを提供します。これにより、ユーザーはそのデータをクエリーできます。
Data Index サービスは、イベントを介して受信するデータを処理します。このイベントは、任意のワークフローから、または直接 Job サービスから発生する場合があります。
Data Index は、ワークフローからの CloudEvents メッセージを消費する Apache Kafka または Knative Eventing をサポートします。このイベントデータをインデックス化してデータベースに格納し、GraphQL 経由でアクセスできるようにします。これらのイベントは、ワークフロー実行に関する詳細情報を提供します。Data Index サービスは、OpenShift Serverless Logic の検索、インサイトおよび管理機能の中心となります。
Data Index サービスの主な機能は以下のとおりです。
- 柔軟なデータ構造
- 分散可能なクラウド対応形式
- Apache Kafka、Knative、および CloudEvents を介したワークフローとのメッセージベースの通信
- 強力な GraphQL ベースのクエリー API
OpenShift Serverless Operator を使用してワークフローをデプロイする場合は、Data Index サービスを手動でインストールしたり、設定したりする必要はありません。Operator は、各ワークフローがこれに接続するために必要なすべての設定を自動的に管理します。
3.2.1. ワークフローインスタンスとジョブの GraphQL クエリー リンクのコピーリンクがクリップボードにコピーされました!
ワークフローインスタンスとジョブに関するデータを取得するには、GraphQL クエリーを使用できます。
3.2.1.1. ワークフローインスタンスからのデータの取得 リンクのコピーリンクがクリップボードにコピーされました!
次のクエリー例を使用して、特定のワークフローインスタンスに関する情報を取得できます。
3.2.1.2. ジョブからのデータの取得 リンクのコピーリンクがクリップボードにコピーされました!
以下のクエリー例を使用して、特定のジョブインスタンスからデータを取得できます。
3.2.1.3. where パラメーターを使用してクエリーの結果をフィルタリングする リンクのコピーリンクがクリップボードにコピーされました!
where パラメーターを使用してクエリーの結果をフィルタリングし、ワークフロー属性に基づいて複数の組み合わせを許可できます。
状態別にフィルタリングするクエリーの例
ID 別にフィルタリングするクエリーの例
デフォルトでは、フィルターは AND Operator を使用して組み合わせています。この動作は、フィルターを AND Operator または OR Operator と組み合わせることで変更できます。
フィルターを OR Operator と組み合わせるクエリーの例
フィルターを AND Operator および OR Operator と組み合わせるクエリーの例
属性タイプに応じて、次の使用可能な Operator を使用できます。
| 属性タイプ | 利用可能な演算子 |
|---|---|
| String array |
|
| String |
|
| ID |
|
| Boolean |
|
| 数値 |
|
| Date |
|
3.2.1.4. orderBy パラメーターを使用してクエリー結果をソートする リンクのコピーリンクがクリップボードにコピーされました!
orderBy パラメーターを使用して、ワークフロー属性に基づいてクエリー結果をソートできます。昇順 (ASC) または降順 (DESC) でソート順序を指定することもできます。指定した順序で複数の属性が適用されます。
開始時刻を ASC 順序でソートするクエリーの例
3.2.1.5. pagination パラメーターを使用して結果の数を制限する リンクのコピーリンクがクリップボードにコピーされました!
pagination パラメーターを使用して、返される結果の数を制御し、オフセットを指定できます。
オフセット 0 から始まる結果を 10 に制限するクエリーの例
3.3. サポートサービスの管理 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、OpenShift Serverless Logic に不可欠なサポートサービスの概要を説明します。これは、OpenShift Serverless Logic Operator を使用した Data Index サービスおよび Job Service のサポートサービスの設定およびデプロイに重点を置いています。
通常の OpenShift Serverless Logic インストールでは、ワークフローの実行が正常に実行されるように両方のサービスをデプロイする必要があります。Data Index サービスを使用すると、効率的なデータ管理が可能になりますが、Job Service は信頼性の高いジョブ処理を実現します。
3.3.1. サポートサービスとワークフローのインテグレーション リンクのコピーリンクがクリップボードにコピーされました!
サポートサービスを特定の namespace にデプロイする場合、有効または無効のデプロイメントを選択できます。有効化されたデプロイメントは、OpenShift Serverless Logic Operator に対し、namespace 内で preview または gitops プロファイルを使用するワークフローのデプロイメントを自動的に検出し、それらをサービスに接続するよう設定する指示を送ります。
たとえば、Data Index サービスが有効化されている場合、ステータス変更イベントを送信するようにワークフローが自動的に設定されています。同様に Job Service を有効にすると、ワークフローでタイムアウトが必要なたびにジョブが作成されます。OpenShift Serverless Logic Operator は、イベントを Data Index サービスに送信するように Job Service を設定し、サービス間のシームレスなインテグレーションを容易にします。
OpenShift Serverless Logic Operator はサポートサービスをデプロイするだけでなく、ワークフローが正常に実行されるように他の必要な設定も管理します。これらの設定はすべて自動的に処理されます。SonataFlowPlatform CR でサポートサービス設定のみを提供する必要があります。
サポートサービスの 1 つだけをデプロイすること、または無効化されたデプロイメントの使用は、高度なユースケースです。標準のインストールでは、スムーズなワークフローを実行するには、両方のサービスを有効にする必要があります。
3.3.2. SonataFlowPlatform CR を使用したサポートサービスのデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
サポートサービスをデプロイするには、SonataFlowPlatform カスタムリソース (CR) の spec.services セクション内で dataIndex および jobService サブフィールドを設定します。この設定は、SonataFlowPlatform CR が適用される際に、各サービスをデプロイするように OpenShift Serverless Logic Operator に指示します。
サービスの各設定は独立して処理され、SonataFlowPlatform CR の他の設定と共にこれらの設定をカスタマイズできます。
サポートサービスのデプロイは、以下のスキャフォールディングの設定例を参照してください。
3.3.3. サポートサービスのスコープ リンクのコピーリンクがクリップボードにコピーされました!
SonataFlowPlatform カスタムリソース (CR) は、特定の namespace 内でのサポートサービスのデプロイメントを有効にします。つまり、自動的に設定されたサポートサービスとワークフロー通信はすべて、デプロイされたプラットフォームの namespace に制限されます。
この機能は、異なるワークフローセットごとにサポートサービスの個別のインスタンスが必要な場合に特に有用です。たとえば、ワークフローやサポートサービスと共にアプリケーションを分離してデプロイすることで、他のデプロイメントからの独立性を保つことができます。
3.3.4. サポートサービスの永続性設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Logic のサポートサービスの永続性設定は、環境のニーズに応じて、一時的または PostgreSQL のいずれかの設定になります。一時的な永続性は開発とテストに適していますが、実稼働環境には PostgreSQL 永続性が推奨されます。
3.3.4.1. 一時的な永続性設定 リンクのコピーリンクがクリップボードにコピーされました!
一時的な永続性は、各サービス専用の組み込み PostgreSQL データベースを使用します。OpenShift Serverless Logic Operator は、すべてのサービスの再起動でこのデータベースを再作成し、開発およびテストの目的でのみ適切になるようにします。次の SonataFlowPlatform CR 以外の追加の設定は必要ありません。
3.3.4.2. PostgreSQL の永続性設定 リンクのコピーリンクがクリップボードにコピーされました!
PostgreSQL の永続性の場合、クラスターに PostgreSQL サーバーインスタンスをセットアップする必要があります。このインスタンスの管理は、OpenShift Serverless Logic Operator 制御とは独立して維持されます。サポートサービスを PostgreSQL サーバーに接続するには、適切なデータベース接続パラメーターを設定する必要があります。
次の例を使用して、SonataFlowPlatform CR で PostgreSQL の永続性を設定できます。
PostgreSQL の永続性設定の例
- 1
- PostgreSQL データベースサーバーに接続するためのサービスの名前。
- 2
- オプション: PostgreSQL Service の namespace を定義します。デフォルトは SonataFlowPlatform の namespace です。
- 3
- サポートサービスデータを格納する PostgreSQL データベースの名前を定義します。
- 4
- オプション: サポートサービスデータを格納するためのスキーマを指定します。デフォルト値は
SonataFlowPlatform名で、接尾辞には-data-index-serviceor-jobs-serviceが付いています。たとえば、sonataflow-platform-example-data-index-serviceなどです。 - 5
- オプション: PostgreSQL Service と接続するポート番号。デフォルト値は
5432です。 - 6
- データベースアクセスのユーザー名およびパスワードが含まれるシークレットの名前を定義します。
- 7
- データベースに接続するためのユーザー名を含むシークレットのキーの名前を定義します。
- 8
- データベースに接続するためのパスワードを含むシークレットのキーの名前を定義します。
それぞれの persistence フィールドを使用して、各サービスの永続性を個別に設定できます。
次のコマンドを実行して、PostgreSQL にアクセスするためのシークレットを作成します。
oc create secret generic <postgresql_secret_name> \ --from-literal=POSTGRESQL_USER=<user> \ --from-literal=POSTGRESQL_PASSWORD=<password> \ -n <namespace>
$ oc create secret generic <postgresql_secret_name> \
--from-literal=POSTGRESQL_USER=<user> \
--from-literal=POSTGRESQL_PASSWORD=<password> \
-n <namespace>
3.3.4.3. 一般的な PostgreSQL の永続性設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Logic Operator は、サポートサービスを spec.persistence フィールドで設定された共通の PostgreSQL サーバーに自動的に接続します。
ルールの場合、以下の優先順位が適用されます。
-
サポートするサービス (例:
services.dataIndex.persistence) に特定の永続性を設定すると、その設定が使用されます。 - サービスに永続性を設定しない場合、システムは現在のプラットフォームから共通の永続性設定を使用します。
共通の PostgreSQL 設定を使用する場合、各サービススキーマは SonataFlowPlatform 名として自動的に設定され、-data-index-service または -jobs-service の接尾辞が設定されます (例: sonataflow-platform-example-data-index-service)。
3.3.5. 高度なサポートサービス設定 リンクのコピーリンクがクリップボードにコピーされました!
サポートサービス向けに高度な設定を適用する必要がある場合は、SonataFlowPlatform カスタムリソース (CR) の podTemplate フィールドを使用します。このフィールドでは、レプリカの数、環境変数、コンテナーイメージ、初期化オプションなどの設定を指定して、サービス Pod のデプロイメントをカスタマイズできます。
次の例を使用して、サービスの高度な設定を行うことができます。
Data Index サービスの高度な設定例
要件に応じて、'services' フィールドを 'dataIndex' または 'jobService' に設定できます。設定の残りの部分は同じままとなります。
podTemplate フィールドにより、各サポートサービスのデプロイメントを柔軟に調整できます。これは標準の PodSpec API に準拠します。つまり、同じ API 検証ルールがこれらのフィールドに適用されます。
3.3.6. クラスタースコープのサポートサービス リンクのコピーリンクがクリップボードにコピーされました!
SonataFlowClusterPlatform カスタムリソース (CR) を使用して、さまざまな namespace にまたがるワークフローで使用できるクラスター全体のサポートサービスのセットを定義できます。既存の namespace 固有の SonataFlowPlatform CR を参照すると、これらのサービスの使用をクラスター全体で拡張できます。
次の基本設定の例を使用すると、任意の namespace にデプロイされたワークフローが、example-namespace などの特定の namespace にデプロイされたサポートサービスを利用できるようになります。
SonataFlowClusterPlatform CR の例
SonataFlowPlatform.spec.services でその namespace を設定することにより、これらのクラスター全体のサービスを任意の namespace 内でオーバーライドできます。