Serverless Logic


Red Hat OpenShift Serverless 1.35

OpenShift Serverless Logic の概要

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Serverless Logic 機能の概要を説明します。

第1章 スタートガイド

1.1. Knative Workflow プラグインを使用したワークフローの作成および実行

OpenShift Serverless Logic ワークフローをローカルで作成し、実行できます。

1.1.1. ワークフローの作成

kn workflowcreate コマンドを使用して、現在のディレクトリーに新しい OpenShift Serverless Logic プロジェクトを設定できます。

前提条件

  • OpenShift Serverless Logic kn-workflow CLI プラグインがインストールされている。

手順

  1. 次のコマンドを実行して、新しい OpenShift Serverless Logic ワークフロープロジェクトを作成します。

    $ kn workflow create
    Copy to Clipboard Toggle word wrap

    デフォルトでは、生成されるプロジェクト名は new-project です。次のように [-n|--name] フラグを使用してプロジェクト名を変更できます。

    コマンドの例

    $ kn workflow create --name my-project
    Copy to Clipboard Toggle word wrap

1.1.2. ワークフローのローカルでの実行

kn workflowrun コマンドを使用して、現在のディレクトリーに OpenShift Serverless Logic ワークフロープロジェクトをビルドして実行できます。

前提条件

  • ローカルマシンに Podman がインストールされている。
  • OpenShift Serverless Logic kn-workflow CLI プラグインがインストールされている。
  • OpenShift Serverless Logic ワークフロープロジェクトを作成している。

手順

  1. 次のコマンドを実行して、OpenShift Serverless Logic ワークフロープロジェクトをビルドして実行します。

    $ kn workflow run
    Copy to Clipboard Toggle word wrap

    プロジェクトの準備が整うと、開発 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. デプロイメントオプションとワークフローのデプロイ

次の 3 つのデプロイメントプロファイルのいずれかを使用して、クラスターに Serverless Logic ワークフローをデプロイできます。

  • Dev
  • プレビュー
  • GitOps

各プロファイルは、イメージのライフサイクル、ライブ更新、リコンシリエーション動作など、Operator がワークフローのデプロイメントを構築および管理する方法を定義します。

1.2.1. Dev プロファイルを使用してワークフローをデプロイする

Dev プロファイルを使用して、OpenShift Container Platform にローカルワークフローをデプロイできます。このデプロイメントを使用すると、クラスター上で直接ワークフローを実験および変更することができ、変更をほぼ即座に確認できます。Dev プロファイルは開発とテストの目的で設計されています。コンテナーを再起動せずにワークフローを自動的にリロードするため、初期の開発段階やライブ環境でのワークフローの変更のテストに適しています。

前提条件

  • OpenShift Serverless Logic Operator がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. ワークフロー設定 YAML ファイルを作成します。

    workflow-dev.yaml ファイルの例

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlow
    metadata:
      name: greeting 
    1
    
      annotations:
        sonataflow.org/description: Greeting example on k8s!
        sonataflow.org/version: 0.0.1
        sonataflow.org/profile: dev 
    2
    
    spec:
      flow:
        start: ChooseOnLanguage
        functions:
          - name: greetFunction
            type: custom
            operation: sysout
        states:
          - name: ChooseOnLanguage
            type: switch
            dataConditions:
              - condition: "${ .language == \"English\" }"
                transition: GreetInEnglish
              - condition: "${ .language == \"Spanish\" }"
                transition: GreetInSpanish
            defaultCondition: GreetInEnglish
          - name: GreetInEnglish
            type: inject
            data:
              greeting: "Hello from JSON Workflow, "
            transition: GreetPerson
          - name: GreetInSpanish
            type: inject
            data:
              greeting: "Saludos desde JSON Workflow, "
            transition: GreetPerson
          - name: GreetPerson
            type: operation
            actions:
              - name: greetAction
                functionRef:
                  refName: greetFunction
                  arguments:
                    message:  ".greeting + .name"
            end: true
    Copy to Clipboard Toggle word wrap

    1
    <workflow_name> はワークフロー名です。
    2
    Dev プロファイルを使用してワークフローをデプロイする必要があることを示します。
  2. アプリケーションをデプロイするには、次のコマンドを入力して YAML ファイルを適用します。

    $ oc apply -f <filename> -n <your_namespace>
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、デプロイメントを確認し、デプロイされたワークフローのステータスを確認します。

    $ oc get workflow -n <your_namespace> -w
    Copy to Clipboard Toggle word wrap

    ワークフローがリストされており、ステータスが Running または Completed であることを確認します。

  4. 次のコマンドを入力して、クラスター内でワークフローを直接編集します。

    $ oc edit sonataflow <workflow_name> -n <your_namespace>
    Copy to Clipboard Toggle word wrap
  5. 編集後、変更を保存します。OpenShift Serverless Logic Operator は変更を検出し、それに応じてワークフローを更新します。

検証

  1. 変更が正しく適用されていることを確認するには、次のコマンドを入力してワークフローのステータスとログを確認します。

    1. 次のコマンドを実行して、ワークフローのステータスを表示します。

      $ oc get sonataflows -n <your_namespace>
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行してワークフローログを表示します。

      $ oc logs <workflow_pod_name> -n <your_namespace>
      Copy to Clipboard Toggle word wrap

次のステップ

  1. テストが完了したら、次のコマンドを実行してリソースを削除し、必要のないリソースの使用を回避します。

    $ oc delete sonataflow <workflow_name> -n <your_namespace>
    Copy to Clipboard Toggle word wrap

1.2.2. Preview プロファイルを使用したワークフローのデプロイ

Preview プロファイルを使用して、OpenShift Container Platform にローカルワークフローをデプロイできます。これにより、クラスター上で実稼働環境と同様の環境でワークフローを直接検証およびテストできます。Preview プロファイルは、ワークフローを実稼働環境に移行する前の最終テストと検証、およびビルドパイプラインを直接管理しない迅速なイテレーションに適しています。また、実稼働環境と同様の環境でワークフローがスムーズに実行されるようにします。

前提条件

  • クラスターに OpenShift Serverless Logic Operator がインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

Preview プロファイルでワークフローをデプロイするために、OpenShift Serverless Logic Operator は OpenShift Container Platform 上のビルドシステムを使用します。これにより、ワークフローをデプロイするためのイメージが自動的に作成されます。

次のセクションでは、OpenShift Serverless Logic Operator と SonataFlow カスタムリソースを使用して、クラスター上にワークフローを構築およびデプロイする方法を説明します。

1.2.2.1. Preview プロファイルでのワークフローの設定
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) がインストールされている。

手順

  1. 次のコマンドを実行して、namespace 内の SonataFlowPlatform リソースをリスト表示します。

    $ oc get sonataflowplatform -n <your_namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <your_namespace> は namespace の名前に置き換えます。
  2. 次のコマンドを実行して、SonataFlowPlatform リソースに新しいビルダーイメージを適用します。

    $ 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 Toggle word wrap

検証

  1. 次のコマンドを実行して、SonataFlowPlatform CR が正しく修正されていることを確認します。

    $ oc describe sonataflowplatform <name> -n <your_namespace> 
    1
    Copy to Clipboard Toggle word wrap
    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

apiVersion: v1
data:
  DEFAULT_WORKFLOW_EXTENSION: .sw.json
  Dockerfile: |
    FROM registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.33.0 AS builder

    # Variables that can be overridden by the builder
    # To add a Quarkus extension to your application
    ARG QUARKUS_EXTENSIONS
    # Args to pass to the Quarkus CLI add extension command
    ARG QUARKUS_ADD_EXTENSION_ARGS
    # Additional java/mvn arguments to pass to the builder
    ARG MAVEN_ARGS_APPEND

    # Copy from build context to skeleton resources project
    COPY --chown=1001 . ./resources

    RUN /home/kogito/launch/build-app.sh ./resources

    #=============================
    # Runtime Run
    #=============================
    FROM registry.access.redhat.com/ubi9/openjdk-17:latest

    ENV LANG='en_US.UTF-8' LANGUAGE='en_US:en'

    # We make four distinct layers so if there are application changes, the library layers can be re-used
    COPY --from=builder --chown=185 /home/kogito/serverless-workflow-project/target/quarkus-app/lib/ /deployments/lib/
    COPY --from=builder --chown=185 /home/kogito/serverless-workflow-project/target/quarkus-app/*.jar /deployments/
    COPY --from=builder --chown=185 /home/kogito/serverless-workflow-project/target/quarkus-app/app/ /deployments/app/
    COPY --from=builder --chown=185 /home/kogito/serverless-workflow-project/target/quarkus-app/quarkus/ /deployments/quarkus/

    EXPOSE 8080
    USER 185
    ENV AB_JOLOKIA_OFF=""
    ENV JAVA_OPTS="-Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
    ENV JAVA_APP_JAR="/deployments/quarkus-run.jar"
kind: ConfigMap
metadata:
  name: sonataflow-operator-builder-config
  namespace: sonataflow-operator-system
Copy to Clipboard Toggle word wrap

1.2.2.1.3. リソース要件の変更

ワークフロー namespace で SonataFlowPlatform リソースを作成または編集することにより、内部ビルダー Pod のリソース要件を指定できます。

SonataFlowPlatform リソースの例

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform
spec:
  build:
    template:
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"
Copy to Clipboard Toggle word wrap

注記

namespace ごとに 1 つの SonataFlowPlatform リソースのみが許可されます。別のリソースを作成する代わりに、OpenShift Serverless Logic Operator によって作成されたリソースを取得して編集します。

特定のワークフローのリソース要件を微調整できます。各ワークフローインスタンスには、ワークフローと同じ名前で作成された SonataFlowBuild インスタンスがあります。SonataFlowBuild カスタムリソース (CR) を編集し、次のようにパラメーターを指定できます。

SonataFlowBuild CR の例

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowBuild
metadata:
  name: my-workflow
spec:
  resources:
    requests:
      memory: "64Mi"
      cpu: "250m"
    limits:
      memory: "128Mi"
      cpu: "500m"
Copy to Clipboard Toggle word wrap

これらのパラメーターは、新しいビルドインスタンスにのみ適用されます。

1.2.2.1.4. 内部ビルダーに引数を渡す

ビルド引数を SonataFlowBuild インスタンスに渡すか、SonataFlowPlatform リソースでデフォルトのビルド引数を設定することで、ビルドプロセスをカスタマイズできます。

前提条件

  • クラスターに OpenShift Serverless Logic Operator がインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、既存の SonataFlowBuild インスタンスを確認します。

    $ oc get sonataflowbuild <name> -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <name>SonataFlowBuild インスタンスの名前に、<namespace> を namespace に置き換えます。
  2. 次のコマンドを実行して、SonataFlowBuild インスタンスにビルド引数を追加します。

    $ oc edit sonataflowbuild <name> -n <namespace>
    Copy to Clipboard Toggle word wrap
  3. SonataFlowBuild インスタンスの .spec.buildArgs フィールドの下に、必要なビルド引数を追加します。

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowBuild
    metadata:
      name: <name>  
    1
    
    spec:
      buildArgs:
        - name: <argument_1>
          value: <value_1>
        - name: <argument_2>
          value: <value_2>
    Copy to Clipboard Toggle word wrap
    1
    既存の SonataFlowBuild インスタンスの名前。
  4. ファイルを保存して終了します。

    更新された設定で新しいビルドが開始されます。

  5. 次のコマンドを実行して、SonataFlowPlatform リソースにデフォルトのビルド引数を設定します。

    $ oc edit sonataflowplatform <name> -n <namespace>
    Copy to Clipboard Toggle word wrap
  6. SonataFlowPlatform リソースの .spec.buildArgs フィールドに、必要なビルド引数を追加します。

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowPlatform
    metadata:
      name: <name> 
    1
    
    spec:
      build:
        template:
          buildArgs:
            - name: <argument_1>
              value: <value_1>
            - name: <argument_2>
              value: <value_2>
    Copy to Clipboard Toggle word wrap
    1
    既存の SonataFlowPlatform リソースの名前。
  7. ファイルを保存して終了します。
1.2.2.1.5. 内部ビルダーでの環境変数の設定

SonataFlowBuild 内部ビルダー Pod に環境変数を設定できます。これらの変数はビルドコンテキストに対してのみ有効であり、最終的にビルドされたワークフローイメージには設定されません。

前提条件

  • クラスターに OpenShift Serverless Logic Operator がインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、既存の SonataFlowBuild インスタンスを確認します。

    $ oc get sonataflowbuild <name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    <name>SonataFlowBuild インスタンスの名前に、<namespace> を namespace に置き換えます。

  2. 次のコマンドを実行して、SonataFlowBuild インスタンスを編集します。

    $ oc edit sonataflowbuild <name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    SonataFlowBuild インスタンスの例

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowBuild
    metadata:
      name: <name>
    spec:
      envs:
        - name: <env_variable_1>
          value: <value_1>
        - name: <env_variable_2>
          value: <value_2>
    Copy to Clipboard Toggle word wrap

  3. ファイルを保存して終了します。

    更新された設定で新しいビルドが開始されます。

    あるいは、SonataFlowPlatform で環境を設定して、すべての新しいビルドインスタンスがその設定をテンプレートとして使用するようにすることもできます。

    SonataFlowPlatform インスタンスの例

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowPlatform
    metadata:
      name: <name>
    spec:
      build:
        template:
          envs:
            - name: <env_variable_1>
              value: <value_1>
            - name: <env_variable_2>
              value: <value_2>
    Copy to Clipboard Toggle word wrap

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) がインストールされている。

手順

  1. 次のコマンドを実行して、logic-Operator-rhel8-builder-config config map を編集します。

    $ oc edit cm/logic-operator-rhel8-builder-config -n openshift-serverless-logic
    Copy to Clipboard Toggle word wrap
  2. dockerfile エントリーを変更します。

    エディターで、Dockerfile エントリーを見つけて、最初の行を目的のイメージに変更します。

    data:
      Dockerfile: |
        FROM registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.33.0
        # Change the image to the desired one
    Copy to Clipboard Toggle word wrap

  3. 変更を保存します。
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) がインストールされている。

手順

  1. 次のようなワークフロー YAML ファイルを作成します。

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlow
    metadata:
      name: greeting
      annotations:
        sonataflow.org/description: Greeting example on k8s!
        sonataflow.org/version: 0.0.1
    spec:
      flow:
        start: ChooseOnLanguage
        functions:
          - name: greetFunction
            type: custom
            operation: sysout
        states:
          - name: ChooseOnLanguage
            type: switch
            dataConditions:
              - condition: "${ .language == \"English\" }"
                transition: GreetInEnglish
              - condition: "${ .language == \"Spanish\" }"
                transition: GreetInSpanish
            defaultCondition: GreetInEnglish
          - name: GreetInEnglish
            type: inject
            data:
              greeting: "Hello from JSON Workflow, "
            transition: GreetPerson
          - name: GreetInSpanish
            type: inject
            data:
              greeting: "Saludos desde JSON Workflow, "
            transition: GreetPerson
          - name: GreetPerson
            type: operation
            actions:
              - name: greetAction
                functionRef:
                  refName: greetFunction
                  arguments:
                    message:  ".greeting+.name"
            end: true
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、SonataFlow ワークフロー定義を OpenShift Container Platform namespace に適用します。

    $ oc apply -f <workflow-name>.yaml -n <your_namespace>
    Copy to Clipboard Toggle word wrap

    greetings-workflow.yaml ファイルのコマンドの例:

    $ oc apply -f greetings-workflow.yaml -n workflows
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、すべてのビルド設定をリスト表示します。

    $ oc get buildconfigs -n workflows
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、ビルドプロセスのログを取得します。

    $ oc logs buildconfig/<workflow-name> -n <your_namespace>
    Copy to Clipboard Toggle word wrap

    greetings-workflow.yaml ファイルのコマンドの例:

    $ oc logs buildconfig/greeting -n workflows
    Copy to Clipboard Toggle word wrap

検証

  1. デプロイメントを確認するには、次のコマンドを実行してすべての Pod をリスト表示します。

    $ oc get pods -n <your_namespace>
    Copy to Clipboard Toggle word wrap

    ワークフローに対応する Pod が実行されていることを確認します。

  2. 次のコマンドを実行して、実行中の Pod とそのログを確認します。

    $ oc logs pod/<pod-name> -n workflows
    Copy to Clipboard Toggle word wrap
1.2.2.3. ワークフローのデプロイメントの検証

ワークフロー Pod からテスト HTTP 呼び出しを実行して、OpenShift Serverless Logic ワークフローが実行されていることを確認できます。

前提条件

  • クラスターに OpenShift Serverless Logic Operator がインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のようなワークフロー YAML ファイルを作成します。

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlow
    metadata:
      name: greeting
      annotations:
        sonataflow.org/description: Greeting example on k8s!
        sonataflow.org/version: 0.0.1
    spec:
      flow:
        start: ChooseOnLanguage
        functions:
          - name: greetFunction
            type: custom
            operation: sysout
        states:
          - name: ChooseOnLanguage
            type: switch
            dataConditions:
              - condition: "${ .language == \"English\" }"
                transition: GreetInEnglish
              - condition: "${ .language == \"Spanish\" }"
                transition: GreetInSpanish
            defaultCondition: GreetInEnglish
          - name: GreetInEnglish
            type: inject
            data:
              greeting: "Hello from JSON Workflow, "
            transition: GreetPerson
          - name: GreetInSpanish
            type: inject
            data:
              greeting: "Saludos desde JSON Workflow, "
            transition: GreetPerson
          - name: GreetPerson
            type: operation
            actions:
              - name: greetAction
                functionRef:
                  refName: greetFunction
                  arguments:
                    message:  ".greeting+.name"
            end: true
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、ワークフローサービスのルートを作成します。

    $ oc expose svc/<workflow-service-name> -n workflows
    Copy to Clipboard Toggle word wrap

    このコマンドは、ワークフローサービスにアクセスするためのパブリック URL を作成します。

  3. 次のコマンドを実行して、パブリック URL の環境変数を設定します。

    $ WORKFLOW_SVC=$(oc get route/<workflow-service-name> -n <namespace> --template='{{.spec.host}}')
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、ワークフローに HTTP 呼び出しを行い、サービスに POST リクエストを送信します。

    $ curl -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' -d '{<"your": "json_payload">}' http://$WORKFLOW_SVC/<endpoint>
    Copy to Clipboard Toggle word wrap

    出力例

    {
      "id": "b5fbfaa3-b125-4e6c-9311-fe5a3577efdd",
      "workflowdata": {
        "name": "John",
        "language": "English",
        "greeting": "Hello from JSON Workflow, "
      }
    }
    Copy to Clipboard Toggle word wrap

    この出力は、ワークフローが実行中の場合に予想される応答の例を示しています。

1.2.2.4. ビルドの再実行

ビルドを再実行するには、SonataFlowBuild インスタンスに sonataflow.org/restartBuild: true アノテーションを追加または編集します。ワークフローまたは初期ビルドリビジョンに問題がある場合は、ビルドを再実行する必要があります。

前提条件

  • クラスターに OpenShift Serverless Logic Operator がインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、SonataFlowBuild インスタンスが存在するかどうかを確認します。

    $ oc get sonataflowbuild <name> -n <namespace>
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、SonataFlowBuild インスタンスを編集します。

    $ oc edit sonataflowbuild/<name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    <name>SonataFlowBuild インスタンスの名前に、<namespace> はワークフローがデプロイされている namespace に置き換えます。

  3. ビルドを再実行するには、sonataflow.org/restartBuild: true アノテーションを追加します。

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowBuild
    metadata:
      name: <name>
      annotations:
        sonataflow.org/restartBuild: true
    Copy to Clipboard Toggle word wrap

    このアクションにより、OpenShift Serverless Logic Operator がトリガーされ、ワークフローの新しいビルドが開始されます。

  4. ビルドプロセスを監視するには、次のコマンドを実行してビルドログを確認します。

    $ oc logs buildconfig/<name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    <name>SonataFlowBuild インスタンスの名前に、<namespace> はワークフローがデプロイされている namespace に置き換えます。

1.2.3. GitOps プロファイルを使用してワークフローをデプロイする

重要

GitOps プロファイルは実稼働環境のデプロイメントにのみ使用してください。開発、迅速なイテレーション、またはテストの場合は、代わりに Dev または Preview プロファイルを使用してください。

GitOps プロファイルを使用して、OpenShift Container Platform にローカルワークフローをデプロイできます。GitOps プロファイルは、通常は ArgoCD や Tekton などの CI/CD パイプラインを通じてイメージを外部でビルドおよび管理できるようにすることで、ワークフローコンテナーイメージを完全に制御します。コンテナーイメージが SonataFlow カスタムリソース (CR) で定義されると、Operator は GitOps プロファイルが使用されていることを自動的に想定し、イメージのビルドや変更を一切行いません。

前提条件

  • OpenShift Serverless Logic Operator がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. SonataFlow CR でコンテナーイメージを指定します。

    GitOps プロファイルが設定された SonataFlow CR の例

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlow
    metadata:
      annotations:
        sonataflow.org/profile: gitops
      name: workflow_name
    spec:
      flow: 
    1
    
    #...
      podTemplate:
        container:
          image: your-registry/workflow_name:tag
    #...
    Copy to Clipboard Toggle word wrap

    1
    flow 定義は、ビルドプロセス中に使用されるワークフロー定義と一致する必要があります。GitOps プロファイルを使用してワークフローをデプロイすると、Operator はこの定義をコンテナーイメージに埋め込まれたワークフローファイルと比較します。定義とファイルが一致しない場合、デプロイメントは失敗します。
  2. CR を適用してワークフローをデプロイします。

    $ oc apply -f <filename>
    Copy to Clipboard Toggle word wrap

1.2.4. ワークフローの編集

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) がインストールされている。

手順

  1. 以下のコマンドを実行して ConfigMap を開き、編集します。

    $ oc edit cm <workflow_name>-props -n <namespace>
    Copy to Clipboard Toggle word wrap

    <workflow_name> はワークフローの名前に、<namespace> はワークフローがデプロイされている namespace に置き換えます。

  2. application.properties セクションにプロパティーを追加します。

    ConfigMap 内に保存されるワークフロープロパティーの例:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      labels:
        app: greeting
      name: greeting-props
      namespace: default
    data:
      application.properties: |
        my.properties.key = any-value
    Copy to Clipboard Toggle word wrap

    Operator が設定をデフォルトの設定に置き換えないように、プロパティーが正しくフォーマットされていることを確認してください。

  3. 必要な変更を行った後、ファイルを保存してエディターを終了します。

1.2.5. ワークフローのテスト

OpenShift Serverless Logic ワークフローが正しく実行されていることを確認するには、関連する Pod からテスト HTTP 呼び出しを実行できます。

前提条件

  • OpenShift Serverless Logic Operator がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、namespace 内の指定されたサービスへのルートを作成します。

    $ oc expose svc <service_name> -n <namespace>
    Copy to Clipboard Toggle word wrap
  2. 新しく公開されたサービスの URL を取得するには、次のコマンドを実行します。

    $ WORKFLOW_SVC=$(oc get route/<service_name> --template='{{.spec.host}}')
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、テスト HTTP 呼び出しを実行し、POST リクエストを送信します。

    $ curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '<request_body>' http://$WORKFLOW_SVC/<endpoint>
    Copy to Clipboard Toggle word wrap
  4. 応答を検証して、ワークフローが期待どおりに機能していることを確認します。

1.2.6. ワークフローのトラブルシューティング

OpenShift Serverless Logic Operator は、ヘルスチェックプローブを備えた Pod をデプロイし、ワークフローが正常な状態で実行されるようにします。変更したことが原因でこれらのヘルスチェックに失敗すると、Pod は応答を停止します。

前提条件

  • OpenShift Serverless Logic Operator がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行してワークフローのステータスを確認します。

    $ oc get workflow <name> -o jsonpath={.status.conditions} | jq .
    Copy to Clipboard Toggle word wrap
  2. ワークフローのデプロイメントからログを取得して分析するには、次のコマンドを実行します。

    $ oc logs deployment/<workflow_name> -f
    Copy to Clipboard Toggle word wrap

1.2.7. ワークフローの削除

oc delete コマンドを使用して、現在のディレクトリーで OpenShift Serverless Logic ワークフローを削除できます。

前提条件

  • OpenShift Serverless Logic Operator がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 削除するワークフローを定義する正しいファイルがあることを確認します。たとえば、workflow.yaml などです。
  2. oc delete コマンドを実行して、指定した namespace からワークフローを削除します。

    $ oc delete -f <your_file> -n <your_namespace>
    Copy to Clipboard Toggle word wrap

    <your_file> は、ワークフローファイルの名前に、<your_namespace> を namespace に置き換えます。

第2章 グローバル設定

OpenShift Serverless Logic Operator のグローバル設定オプションを設定できます。

2.1. 前提条件

  • OpenShift Serverless Logic Operator をターゲットクラスターにインストールしている。

2.2. グローバル設定のカスタマイズ

OpenShift Serverless Logic Operator のインストール後に、openshift-serverless-logic namespace の logic-operator-rhel8-controllers-config config map ファイルにアクセスできます。この設定ファイルは、Operator がクラスターに新規リソースを作成する際にどのように動作するかを定義します。ただし、この設定への変更は、すでに存在するリソースには影響しません。

config map の controllers_cfg.yaml キー内のオプションのいずれかを変更できます。

以下の表は、利用可能なすべてのグローバル設定オプションの概要を示しています。

Expand
設定キーデフォルト値説明

defaultPvcKanikoSize

1Gi

内部 OpenShift Serverless Logic Operator ビルダーマネージャーを使用する場合の Kaniko 永続ボリューム要求 (PVC) のデフォルトサイズ。

healthFailureThresholdDevMode

50

開発者モードのワークフローが開始されるまでに待機する時間 (秒単位)。この情報は、コントローラーマネージャーが新しい開発者モードコンテナーを作成し、ヘルスチェックプローブを設定するために使用されます。

kanikoDefaultWarmerImageTag

gcr.io/kaniko-project/warmer:v1.9.0

Operator 管理の Kaniko ビルダーがウォームアップ Pod を作成するために使用するデフォルトのイメージ。

kanikoExecutorImageTag

gcr.io/kaniko-project/executor:v1.9.0

Operator 管理の Kaniko ビルダーがエグゼキューター Pod を作成するために内部で使用されるデフォルトのイメージ。

jobsServicePostgreSQLImageTag

registry.redhat.io/openshift-serverless-1/logic-jobs-service-postgresql-rhel8:1.35.0

PostgreSQL が使用する Job サービスイメージ。空の場合、OpenShift Serverless Logic Operator は、現行バージョンの OpenShift Serverless Logic Operator に基づいてデフォルトの Apache コミュニティーイメージを使用します。

jobsServiceEphemeralImageTag

registry.redhat.io/openshift-serverless-1/logic-jobs-service-ephemeral-rhel8:1.35.0

使用する永続性のない Job サービスイメージ。空の場合、OpenShift Serverless Logic Operator は、現行バージョンの OpenShift Serverless Logic Operator に基づいてデフォルトの Apache コミュニティーイメージを使用します。

dataIndexPostgreSQLImageTag

registry.redhat.io/openshift-serverless-1/logic-data-index-postgresql-rhel8:1.35.0

PostgreSQL が使用する Data Index サービスイメージ。空の場合、OpenShift Serverless Logic Operator は、現行バージョンの OpenShift Serverless Logic Operator に基づいてデフォルトの Apache コミュニティーイメージを使用します。

dataIndexEphemeralImageTag

registry.redhat.io/openshift-serverless-1/logic-data-index-ephemeral-rhel8:1.35.0

使用する永続性のない Data Index サービスイメージ。空の場合、OpenShift Serverless Logic Operator は、現行バージョンの OpenShift Serverless Logic Operator に基づいてデフォルトの Apache コミュニティーイメージを使用します。

sonataFlowBaseBuilderImageTag

registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.35.0

プレビュープロファイルでワークフローアプリケーションをビルドするために内部 Dockerfile で使用される OpenShift Serverless Logic ベースビルダーイメージ。空の場合、OpenShift Serverless Logic Operator は、現行バージョンの OpenShift Serverless Logic Operator に基づいてデフォルトの Apache コミュニティーイメージを使用します。

sonataFlowDevModeImageTag

registry.redhat.io/openshift-serverless-1/logic-swf-devmode-rhel8:1.35.0

OpenShift Serverless Logic ワークフローイメージを devmode プロファイルにデプロイするために使用するイメージ。空の場合、OpenShift Serverless Logic Operator は、現行バージョンの OpenShift Serverless Logic Operator に基づいてデフォルトの Apache コミュニティーイメージを使用します。

builderConfigMapName

logic-operator-rhel8-builder-config

OpenShift Serverless Logic Operator namespace のビルダー config map のデフォルト名。

postgreSQLPersistenceExtensions

next column

ワークフローの永続性に必要な Quarkus エクステンション。これらのエクステンションは、ビルドされるワークフローで PostgreSQL の永続性が設定されている場合に、OpenShift Serverless Logic Operator ビルダーによって使用されます。

kogitoEventsGrouping

true

true に設定すると、gitops または preview プロファイルを使用してすべてのワークフローデプロイメントを設定し、蓄積されたワークフローステータス変更イベントを Data Index サービスに送信して、生成されるイベントの数を減らします。個々のイベントを送信するには、値を false に設定します。

kogitoEventsGroupingBinary

true

true に設定されると、累積されたワークフローのステータス変更イベントはバイナリーモードで送信され、生成されるイベントのサイズを縮小します。値を false に設定して、プレーンな JSON イベントを送信できます。

kogitoEventsGroupingCompress

false

true に設定されると、累積されたワークフローのステータス変更イベントは、バイナリーモードで送信された場合に、一部のパフォーマンスを犠牲にして zip されます。

これは、oc コマンドラインツールを使用して logic-operator-controllers-config config map を更新することで編集できます。

2.2.1. グローバル設定変更の影響

グローバル設定を更新すると、変更は直ちに新規作成されたリソースにのみ影響します。たとえば、sonataFlowDevModeImageTag プロパティーを変更し、dev モードでデプロイ済みのワークフローがある場合、OpenShift Serverless Logic Operator は更新されたイメージ設定で新しいデプロイメントをロールアウトしません。変更を反映するのは、新しいデプロイメントのみです。

2.2.2. ベースビルダーイメージのカスタマイズ

OpenShift Serverless Logic Operator で使用される Dockerfile のベースビルダーイメージを直接変更できます。

さらに、現在の namespace 内の SonataFlowPlatform 設定でベースビルダーイメージを指定できます。これにより、指定されたベースイメージが指定の namespace でのみ使用されるようになります。

カスタムベースビルダーイメージを含む SonataFlowPlatform の例

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform
spec:
  build:
    config:
        baseImage: dev.local/my-workflow-builder:1.0.0
Copy to Clipboard Toggle word wrap

または、以下の例のように、グローバル config map でベースビルダーイメージを変更することもできます。

カスタムベースビルダーイメージを含む ConfigMap の例

apiVersion: v1
data:
  controllers_cfg.yaml: |
    sonataFlowBaseBuilderImageTag: dev.local/my-workflow-builder:1.0.0
kind: ConfigMap
metadata:
  name: logic-operator-rhel8-controllers-config
  namespace: openshift-serverless-logic
Copy to Clipboard Toggle word wrap

ベースビルダーイメージをカスタマイズする場合、以下の優先順位が適用されます。

  1. 現在のコンテキストの SonataFlowPlatform 設定。
  2. ConfigMap リソースのグローバル設定エントリー。
  3. logic-operator-rhel8-builder-config config map で定義される、OpenShift Serverless Logic Operator namespace 内の Dockerfile の FROM 句。

SonataFlowPlatform 設定のエントリーは、常に他の値をオーバーライドします。

第3章 サービスの管理

3.1. OpenAPI サービスの設定

OpenAPI 仕様 (OAS) は、HTTP API 向けに、プログラミング言語に依存しない、標準のインターフェイスを定義します。ソースコード、追加のドキュメント、またはネットワークトラフィックの検査にアクセスしなくても、サービスの機能を理解することができます。OpenAPI を使用してサービスを定義すると、最小限の実装ロジックを使用してサービスを理解し、操作することができます。インターフェイスの記述によって低レベルのプログラミングが簡素化されるのと同様に、OpenAPI 仕様 によってサービス呼び出し時の推測作業がなくなります。

3.1.1. OpenAPI 関数定義

OpenShift Serverless Logic を使用すると、ワークフローは関数内の OpenAPI 仕様参照を使用してリモートサービスと対話できます。

OpenAPI 関数定義の例

{
   "functions": [
      {
         "name": "myFunction1",
         "operation": "specs/myopenapi-file.yaml#myFunction1"
      }
   ]
}
Copy to Clipboard Toggle word wrap

operation 属性は、次のパラメーターで構成される string です。

  • URI: エンジンはこれを使用して仕様ファイルを見つけます。
  • Operation identifier: この識別子は OpenAPI 仕様ファイルにあります。

OpenShift Serverless Logic は以下の URI スキームをサポートします。

  • file: ファイルシステム内にあるファイルに使用します。
  • http または https: これらはリモートにあるファイルに使用します。

ビルド時に OpenAPI 仕様ファイルが利用可能であることを確認します。OpenShift Serverless Logic は、実行時にリクエストを送信するために内部コード生成機能を使用します。アプリケーションイメージのビルド後、OpenShift Serverless Logic はこれらのファイルにアクセスできません。

ワークフローに追加する OpenAPI サービスに仕様ファイルがない場合は、仕様ファイルを作成するか、サービスを更新してファイルを生成して公開できます。

3.1.2. OpenAPI 仕様に基づく REST リクエストの送信

OpenAPI 仕様ファイルに基づく REST リクエストを送信するには、次の手順を実行する必要があります。

  • 関数参照を定義する
  • ワークフロー状態で定義された関数にアクセスする

前提条件

  • OpenShift Serverless Logic Operator がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenAPI 仕様ファイルにアクセスできる。

手順

  1. OpenAPI 関数を定義するには、以下を行います。

    1. 呼び出す予定のサービスの OpenAPI 仕様ファイルを識別してアクセスします。
    2. OpenAPI 仕様ファイルを、<project_application_dir>/specs などのワークフローサービスディレクトリーにコピーします。

      次の例は、乗算 REST サービスの OpenAPI 仕様を示しています。

      乗算 REST サービス OpenAPI 仕様の例

      openapi: 3.0.3
      info:
        title: Generated API
        version: "1.0"
      paths:
        /:
          post:
            operationId: doOperation
            parameters:
              - in: header
                name: notUsed
                schema:
                  type: string
                required: false
            requestBody:
              content:
                application/json:
                  schema:
                    $ref: '#/components/schemas/MultiplicationOperation'
            responses:
              "200":
                description: OK
                content:
                  application/json:
                    schema:
                      type: object
                      properties:
                        product:
                          format: float
                          type: number
      components:
        schemas:
          MultiplicationOperation:
            type: object
            properties:
              leftElement:
                format: float
                type: number
              rightElement:
                format: float
                type: number
      Copy to Clipboard Toggle word wrap

    3. ワークフローで関数を定義するには、OpenAPI 仕様の operationId を使用して、関数定義内の目的の操作を参照します。

      温度変換アプリケーションにおける関数定義の例

      {
         "functions": [
           {
             "name": "multiplication",
             "operation": "specs/multiplication.yaml#doOperation"
           },
           {
             "name": "subtraction",
             "operation": "specs/subtraction.yaml#doOperation"
           }
         ]
      }
      Copy to Clipboard Toggle word wrap

    4. 関数定義が、<project_application_dir>/specs ディレクトリーに保存されている OpenAPI ファイルへの正しいパスを参照していることを確認します。
  2. ワークフロー状態で定義された関数にアクセスします。

    1. 追加した関数定義を呼び出すワークフローアクションを定義します。各アクションが以前に定義された関数を参照していることを確認します。
    2. 特定の関数を名前で参照するには、functionRef 属性を使用します。OpenAPI 仕様で定義されたパラメーターを使用して、functionRef 内の引数をマップします。

      次の例は、リクエスト本文ではなくリクエストパス内のパラメーターのマッピングを示しています。次の PetStore API の例を参照できます。

      ワークフローで関数引数をマッピングする例

      {
         "states": [
          {
            "name": "SetConstants",
            "type": "inject",
            "data": {
              "subtractValue": 32.0,
              "multiplyValue": 0.5556
            },
            "transition": "Computation"
          },
          {
            "name": "Computation",
            "actionMode": "sequential",
            "type": "operation",
            "actions": [
              {
                "name": "subtract",
                "functionRef": {
                  "refName": "subtraction",
                  "arguments": {
                    "leftElement": ".fahrenheit",
                    "rightElement": ".subtractValue"
                  }
                }
              },
              {
                "name": "multiply",
                "functionRef": {
                  "refName": "multiplication",
                  "arguments": {
                     "leftElement": ".difference",
                     "rightElement": ".multiplyValue"
                  }
                }
              }
            ],
            "end": {
              "terminate": true
            }
          }
        ]
      }
      Copy to Clipboard Toggle word wrap

    3. リクエスト内のパラメーターの構造化方法を理解するには、OpenAPI 仕様の Operation Object のセクションを確認してください。
    4. jq 式を使用してペイロードからデータを抽出し、必要なパラメーターにマップします。エンジンが OpenAPI 仕様に従ってパラメーター名をマッピングしていることを確認します。
    5. 本文ではなくリクエストパス内のパラメーターを必要とする操作は、OpenAPI 仕様のパラメーター定義を参照してください。

      リクエスト本文ではなくリクエストパスでパラメーターをマッピングする方法の詳細は、次の PetStore API の例を参照してください。

      パスパラメーターのマッピングの例

      {
        "/pet/{petId}": {
          "get": {
            "tags": ["pet"],
            "summary": "Find pet by ID",
            "description": "Returns a single pet",
            "operationId": "getPetById",
            "parameters": [
              {
                "name": "petId",
                "in": "path",
                "description": "ID of pet to return",
                "required": true,
                "schema": {
                  "type": "integer",
                  "format": "int64"
                }
              }
            ]
          }
        }
      }
      Copy to Clipboard Toggle word wrap

      以下は関数の呼び出し例です。リクエストパスに petId という名前のパラメーターが 1 つだけ追加されています。

      PetStore 関数の呼び出し例

      {
        "name": "CallPetStore", 
      1
      
        "actionMode": "sequential",
        "type": "operation",
        "actions": [
          {
            "name": "getPet",
            "functionRef": {
              "refName": "getPetById", 
      2
      
              "arguments": { 
      3
      
                "petId": ".petId"
              }
            }
          }
        ]
      }
      Copy to Clipboard Toggle word wrap

      1
      CallPetStore などの状態定義。
      2
      関数定義リファレンス。前述の例では、関数定義 getPetById は PetStore OpenAPI 仕様用です。
      3
      引数の定義。OpenShift Serverless Logic は、リクエストを送信する前に、petId 引数をリクエストパスに追加します。

3.1.3. OpenAPI サービスのエンドポイント URL の設定

ワークフロー状態の関数定義にアクセスした後、OpenAPI サービスのエンドポイント URL を設定できます。

前提条件

  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenShift Serverless Logic プロジェクトを作成している。
  • OpenAPI 仕様ファイルにアクセスできる。
  • ワークフローで関数定義を定義している。
  • ワークフロー状態で定義された関数にアクセスできる。

手順

  1. 設定する OpenAPI 仕様ファイルを見つけます。例: substraction.yaml
  2. . などの特殊文字をアンダースコアに置き換え、文字を小文字に変換して、ファイル名を有効な設定キーに変換します。たとえば、substraction.yamlsubstraction_yaml に変更します。
  3. 設定キーを定義するには、変換されたファイル名を REST クライアント設定キーとして使用します。次の例に示すように、このキーを環境変数として設定します。

    quarkus.rest-client.subtraction_yaml.url=http://myserver.com
    Copy to Clipboard Toggle word wrap
  4. application.properties ファイルで URL がハードコーディングされるのを防ぐには、次の例に示すように、環境変数の置換を使用します。

    quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}
    Copy to Clipboard Toggle word wrap

    この例では、以下が適用されます。

    • Configuration Key: quarkus.rest-client.subtraction_yaml.url
    • 環境変数: SUBTRACTION_URL
    • フォールバック URL: http://myserver.com
  5. システムまたはデプロイメント環境で (SUBTRACTION_URL) 環境変数が設定されていることを確認します。変数が見つからない場合、アプリケーションはフォールバック URL (http://myserver.com) を使用します。
  6. 設定キーと URL 置換を application.properties ファイルに追加します。

    quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}
    Copy to Clipboard Toggle word wrap
  7. アプリケーションをデプロイまたは再起動して、新しい設定を適用します。

3.2. OpenAPI サービスエンドポイントの設定

OpenShift Serverless Logic は kogito.sw.operationIdStrategy プロパティーを使用して、OpenAPI ドキュメントに定義されたサービスを呼び出すための REST クライアントを生成します。このプロパティーは、REST クライアント設定の設定キーがどのように導出されるかを決定します。

kogito.sw.operationIdStrategy プロパティーは、FILE_NAMEFULL_URIFUNCTION_NAME、および SPEC_TITLE の値をサポートします。

FILE_NAME

OpenShift Serverless Logic は、OpenAPI ドキュメントファイル名を使用して設定キーを作成します。キーはファイル名に基づいており、特殊文字はアンダースコアに置き換えられます。

設定例:

quarkus.rest-client.stock_portfolio_svc_yaml.url=http://localhost:8282/ 
1
Copy to Clipboard Toggle word wrap

1
OpenAPI ファイルパスは <project_application_dir>/specs/stock-portfolio-svc.yaml です。REST クライアントの URL を設定する生成されたキーは stock_portfolio_svc_yaml です。
FULL_URI

OpenShift Serverless Logic は、OpenAPI ドキュメントの完全な URI パスを設定キーとして使用します。完全な URI はサニタイズされ、キーが形成されます。

Serverless ワークフローの例

{
    "id": "myworkflow",
    "functions": [
        {
          "name": "myfunction",
          "operation": "https://my.remote.host/apicatalog/apis/123/document"
        }
    ]
}
Copy to Clipboard Toggle word wrap

設定例:

quarkus.rest-client.apicatalog_apis_123_document.url=http://localhost:8282/ 
1
Copy to Clipboard Toggle word wrap

1
URI パスは https://my.remote.host/apicatalog/apis/123/document です。REST クライアントの URL を設定する生成キーは apicatalog_apis_123_document です。
FUNCTION_NAME

OpenShift Serverless Logic は、ワークフロー ID と OpenAPI ドキュメントを参照する関数名を組み合わせて、設定キーを生成します。

Serverless ワークフローの例

{
    "id": "myworkflow",
    "functions": [
        {
          "name": "myfunction",
          "operation": "https://my.remote.host/apicatalog/apis/123/document"
        }
    ]
}
Copy to Clipboard Toggle word wrap

設定例:

quarkus.rest-client.myworkflow_myfunction.url=http://localhost:8282/ 
1
Copy to Clipboard Toggle word wrap

1
ワークフロー ID は myworkflow です。関数名は myfunction です。REST クライアントの URL を設定する生成キーは myworkflow_myfunction です。
SPEC_TITLE

OpenShift Serverless Logic は、OpenAPI ドキュメントの info.title 値を使用して設定キーを作成します。タイトルは、サニタイズされ、キーが作成されます。

OpenAPI ドキュメントの例

openapi: 3.0.3
info:
  title: stock-service API
  version: 2.0.0-SNAPSHOT
paths:
  /stock-price/{symbol}:
...
Copy to Clipboard Toggle word wrap

設定例:

quarkus.rest-client.stock-service_API.url=http://localhost:8282/ 
1
Copy to Clipboard Toggle word wrap

1
OpenAPI ドキュメントのタイトルは stock-service API です。REST クライアントの URL を設定する生成キーは stock-service_API です。

3.2.1. URI エイリアスの使用

kogito.sw.operationIdStrategy プロパティーの代わりに、workflow-uri-definitions カスタムエクステンションを使用してエイリアスを URI に割り当てることができます。このエイリアスは設定プロセスを簡素化し、REST クライアント設定および関数定義の設定キーとして使用できます。

workflow-uri-definitions エクステンションを使用すると、URI をエイリアスにマップして、ワークフロー全体と設定ファイルで参照できるようになります。このアプローチは、URI とその設定を一元管理する方法を提供します。

前提条件

  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenAPI 仕様ファイルにアクセスできる。

手順

  1. workflow-uri-definitions エクステンションをワークフローに追加します。このエクステンション内で、URI のエイリアスを作成します。

    ワークフローの例

    {
      "extensions": [
        {
          "extensionid": "workflow-uri-definitions", 
    1
    
          "definitions": {
            "remoteCatalog": "https://my.remote.host/apicatalog/apis/123/document" 
    2
    
          }
        }
      ],
      "functions": [ 
    3
    
        {
          "name": "operation1",
          "operation": "remoteCatalog#operation1"
        },
        {
          "name": "operation2",
          "operation": "remoteCatalog#operation2"
        }
      ]
    }
    Copy to Clipboard Toggle word wrap

1
エクステンション ID を workflow-uri-definitions に設定します。
2
remoteCatalog エイリアスを URI (例: https://my.remote.host/apicatalog/apis/123/document URI) にマッピングして、エイリアス定義を設定します。
3
オペレーション識別子 (例: operation1 および operation2 のオペレーション識別子) を持つ remoteCatalog エイリアスを使用して関数操作を設定します。
  1. application.properties ファイルで、ワークフローで定義されたエイリアスを使用して REST クライアントを設定します。

    プロパティー例

    quarkus.rest-client.remoteCatalog.url=http://localhost:8282/
    Copy to Clipboard Toggle word wrap

    前の例では、設定キーは quarkus.rest-client.remoteCatalog.url に設定され、URL は http://localhost:8282/ に設定されており、REST クライアントは remoteCatalog エイリアスを参照してこれを使用します。

  2. ワークフローでは、URI を操作する関数を定義するときにエイリアスを使用します。

    ワークフローの例 (続き):

    {
      "functions": [
        {
          "name": "operation1",
          "operation": "remoteCatalog#operation1"
        },
        {
          "name": "operation2",
          "operation": "remoteCatalog#operation2"
        }
      ]
    }
    Copy to Clipboard Toggle word wrap

3.3. サービスのトラブルシューティング

ワークフローオーケストレーションを維持するには、OpenAPI 関数を使用するような HTTP ベースの関数呼び出しを効率的にトラブルシューティングすることが重要です。

問題を診断するには、HTTP リクエストとレスポンスをトレースできます。

3.3.1. HTTP リクエストとレスポンスのトレース

OpenShift Serverless Logic は、Apache HTTP クライアントを使用して HTTP リクエストとレスポンスをトレースします。

前提条件

  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • OpenAPI 仕様ファイルにアクセスできる。
  • HTTP リクエストとレスポンスを関連付けるためのワークフロー定義とインスタンス ID にアクセスできる。
  • HTTP サービス呼び出しが発生しているアプリケーションのログ設定にアクセスできる。

手順

  1. HTTP リクエストとレスポンスをトレースするために、OpenShift Serverless Logic は次のプロパティーを設定して Apache HTTP クライアントを使用します。

    # Turning HTTP tracing on
    quarkus.log.category."org.apache.http".level=DEBUG
    Copy to Clipboard Toggle word wrap
  2. Apache HTTP クライアントのデバッグを有効にするには、アプリケーションの application.properties ファイルに次の設定を追加します。

    quarkus.log.category."org.apache.http".level=DEBUG
    Copy to Clipboard Toggle word wrap
  3. ログ設定の変更を反映するには、アプリケーションを再起動します。
  4. 再起動後、ログで HTTP リクエストトレースを確認します。

    トレースされた HTTP リクエストのログの例

    2023-09-25 19:00:55,242 DEBUG Executing request POST /v2/models/yolo-model/infer HTTP/1.1
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> POST /v2/models/yolo-model/infer HTTP/1.1
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> Accept: application/json
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> Content-Type: application/json
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> kogitoprocid: inferencepipeline
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> kogitoprocinstanceid: 85114b2d-9f64-496a-bf1d-d3a0760cde8e
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> kogitoprocist: Active
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> kogitoproctype: SW
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> kogitoprocversion: 1.0
    2023-09-25 19:00:55,243 DEBUG http-outgoing-0 >> Content-Length: 23177723
    2023-09-25 19:00:55,244 DEBUG http-outgoing-0 >> Host: yolo-model-opendatahub-model.apps.trustyai.dzzt.p1.openshiftapps.com
    Copy to Clipboard Toggle word wrap

  5. リクエストログに続く HTTP レスポンストレースのログを確認します。

    トレースされた HTTP レスポンスのログの例

    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "HTTP/1.1 500 Internal Server Error[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "content-type: application/json[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "date: Mon, 25 Sep 2023 19:01:00 GMT[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "content-length: 186[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "set-cookie: 276e4597d7fcb3b2cba7b5f037eeacf5=5427fafade21f8e7a4ee1fa6c221cf40; path=/; HttpOnly; Secure; SameSite=None[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "[\r][\n]"
    2023-09-25 19:01:00,738 DEBUG http-outgoing-0 << "{"code":13, "message":"Failed to load Model due to adapter error: Error calling stat on model file: stat /models/yolo-model__isvc-1295fd6ba9/yolov5s-seg.onnx: no such file or directory"}"
    Copy to Clipboard Toggle word wrap

第4章 サポートサービス

4.1. Job サービス

Job サービスは、クラウド環境でタスクをスケジュールして実行します。独立したサービスがこれらのタスクを実装し、HTTP 呼び出しや Knative イベント配信など、サポートされている任意の対話モードを通じて開始できます。

OpenShift Serverless Logic では、Job サービスはタイムトリガーアクションの実行を制御します。したがって、ワークフローで使用できる時間ベースの状態はすべて、ワークフローと Job サービス間の対話によって処理されます。

たとえば、ワークフローの実行が、設定されたタイムアウトのある状態に到達し、対応するジョブが Job サービスに作成されます。タイムアウトに達すると、HTTP コールバックが実行されてワークフローに通知します。

Job サービスの主な目的は、実行する必要のあるスケジュールされたジョブなどのアクティブなジョブを管理することです。ジョブが最終状態になると、Job サービスはそれを削除します。ジョブ情報を永続的なリポジトリーに保持するために、Job サービスは、Data Index Service などの外部サービスで記録できるステータス変更イベントを生成します。

注記

OpenShift Serverless Operator を使用してワークフローをデプロイする場合は、Job サービスを手動でインストールしたり、設定したりする必要はありません。Operator はこれらのタスクを自動的に処理し、各ワークフローがこれに接続するために必要な設定をすべて管理します。

4.1.1. Job サービスリーダーの選出プロセス

Job サービスはシングルトンサービスとして動作します。つまり、1 つのアクティブなインスタンスのみが、ジョブをスケジュールおよび実行できることを意味します。

複数のインスタンスが実行されている可能性のあるクラウドにサービスがデプロイされる際の競合を防ぐために、Job サービスはリーダー選出プロセスをサポートします。リーダーとして選出されたインスタンスのみが、ジョブを受信およびスケジュールするために外部通信を管理します。

リーダー以外のインスタンスは、スタンバイ状態で非アクティブのままになりますが、選出プロセスを通じてリーダーになる試みは継続されます。新しいインスタンスの起動時に、リーダーシップがすぐには想定されるわけではありません。代わりに、リーダーの選出プロセスを入力して、リーダーロールを引き継ぐことが可能か判断します。

現在のリーダーが応答しなくなったり、シャットダウンしたりした場合に、実行中の別のインスタンスがリーダーとして引き継ぎます。

注記

このリーダー選出メカニズムでは、基盤となる永続バックエンドが使用されます。これは現在、PostgreSQL 実装でのみサポートされています。

4.2. Data Index サービス

Data Index サービスは、ワークフローインスタンスとそれに関連付けられたジョブに関連するデータを保存する専用のサポートサービスです。このサービスは、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 は、各ワークフローがこれに接続するために必要なすべての設定を自動的に管理します。

4.2.1. ワークフローインスタンスとジョブの GraphQL クエリー

ワークフローインスタンスとジョブに関するデータを取得するには、GraphQL クエリーを使用できます。

4.2.1.1. ワークフローインスタンスからのデータの取得

次のクエリー例を使用して、特定のワークフローインスタンスに関する情報を取得できます。

{
  ProcessInstances {
    id
    processId
    state
    parentProcessInstanceId
    rootProcessId
    rootProcessInstanceId
    variables
    nodes {
      id
      name
      type
    }
  }
}
Copy to Clipboard Toggle word wrap
4.2.1.2. ジョブからのデータの取得

以下のクエリー例を使用して、特定のジョブインスタンスからデータを取得できます。

{
  Jobs {
    id
    status
    priority
    processId
    processInstanceId
    executionCounter
  }
}
Copy to Clipboard Toggle word wrap
4.2.1.3. where パラメーターを使用してクエリーの結果をフィルタリングする

where パラメーターを使用してクエリーの結果をフィルタリングし、ワークフロー属性に基づいて複数の組み合わせを許可できます。

状態別にフィルタリングするクエリーの例

{
  ProcessInstances(where: {state: {equal: ACTIVE}}) {
    id
    processId
    processName
    start
    state
    variables
  }
}
Copy to Clipboard Toggle word wrap

ID 別にフィルタリングするクエリーの例

{
  ProcessInstances(where: {id: {equal: "d43a56b6-fb11-4066-b689-d70386b9a375"}}) {
    id
    processId
    processName
    start
    state
    variables
  }
}
Copy to Clipboard Toggle word wrap

デフォルトでは、フィルターは AND Operator を使用して組み合わせています。この動作は、フィルターを AND Operator または OR Operator と組み合わせることで変更できます。

フィルターを OR Operator と組み合わせるクエリーの例

{
  ProcessInstances(where: {or: {state: {equal: ACTIVE}, rootProcessId: {isNull: false}}}) {
    id
    processId
    processName
    start
    end
    state
  }
}
Copy to Clipboard Toggle word wrap

フィルターを AND Operator および OR Operator と組み合わせるクエリーの例

{
  ProcessInstances(where: {and: {processId: {equal: "travels"}, or: {state: {equal: ACTIVE}, rootProcessId: {isNull: false}}}}) {
    id
    processId
    processName
    start
    end
    state
  }
}
Copy to Clipboard Toggle word wrap

属性タイプに応じて、次の使用可能な Operator を使用できます。

Expand
属性タイプ利用可能な演算子

String array

  • contains: 文字列
  • containsAll: 文字列の配列
  • containsAny: 文字列の配列
  • isNull: ブール値 (true または false)

文字列

  • in: 文字列の配列
  • like: 文字列
  • isNull: ブール値 (true または false)
  • equal: 文字列

ID

  • in: 文字列の配列
  • isNull: ブール値 (true または false)
  • equal: 文字列

Boolean

  • isNull: ブール値 (true または false)
  • equal: ブール値 (true または false)

数値

  • in: 整数の配列
  • isNull: ブール値
  • equal: 整数
  • greaterThan: 整数
  • greaterThanEqual: 整数
  • lessThan: 整数
  • lessThanEqual: 整数
  • between: 数値の範囲
  • from: 整数
  • to: 整数

Date

  • isNull: ブール値 (true または false)
  • equal: 日時
  • greaterThan: 日時
  • greaterThanEqual: 日時
  • lessThan: 日時
  • lessThanEqual: 日時
  • between: 日付の範囲
  • from: 日時
  • to: 日時
4.2.1.4. orderBy パラメーターを使用してクエリー結果をソートする

orderBy パラメーターを使用して、ワークフロー属性に基づいてクエリー結果をソートできます。昇順 (ASC) または降順 (DESC) でソート順序を指定することもできます。指定した順序で複数の属性が適用されます。

開始時刻を ASC 順序でソートするクエリーの例

{
  ProcessInstances(where: {state: {equal: ACTIVE}}, orderBy: {start: ASC}) {
    id
    processId
    processName
    start
    end
    state
  }
}
Copy to Clipboard Toggle word wrap

4.2.1.5. pagination パラメーターを使用して結果の数を制限する

pagination パラメーターを使用して、返される結果の数を制御し、オフセットを指定できます。

オフセット 0 から始まる結果を 10 に制限するクエリーの例

{
  ProcessInstances(where: {state: {equal: ACTIVE}}, orderBy: {start: ASC}, pagination: {limit: 10, offset: 0}) {
    id
    processId
    processName
    start
    end
    state
  }
}
Copy to Clipboard Toggle word wrap

4.3. サポートサービスの管理

このセクションでは、OpenShift Serverless Logic に不可欠なサポートサービスの概要を説明します。これは、OpenShift Serverless Logic Operator を使用した Data Index サービスおよび Job Service のサポートサービスの設定およびデプロイに重点を置いています。

通常の OpenShift Serverless Logic インストールでは、ワークフローの実行が正常に実行されるように両方のサービスをデプロイする必要があります。Data Index サービスを使用すると、効率的なデータ管理が可能になりますが、Job Service は信頼性の高いジョブ処理を実現します。

4.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 つだけをデプロイすること、または無効化されたデプロイメントの使用は、高度なユースケースです。標準のインストールでは、スムーズなワークフローを実行するには、両方のサービスを有効にする必要があります。

4.3.2. SonataFlowPlatform CR を使用したサポートサービスのデプロイメント

サポートサービスをデプロイするには、SonataFlowPlatform カスタムリソース (CR) の spec.services セクション内で dataIndex および jobService サブフィールドを設定します。この設定は、SonataFlowPlatform CR が適用される際に、各サービスをデプロイするように OpenShift Serverless Logic Operator に指示します。

サービスの各設定は独立して処理され、SonataFlowPlatform CR の他の設定と共にこれらの設定をカスタマイズできます。

サポートサービスのデプロイは、以下のスキャフォールディングの設定例を参照してください。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform-example
  namespace: example-namespace
spec:
  services:
    dataIndex: 
1

      enabled: true 
2

      # Specific configurations for the Data Index Service
      # might be included here
    jobService: 
3

      enabled: true 
4

      # Specific configurations for the Job Service
      # might be included here
Copy to Clipboard Toggle word wrap
1
Data Index サービス設定フィールド。
2
enabled: true を設定すると、Data Index サービスがデプロイされます。false に設定するか、省略すると、デプロイメントは無効になります。デフォルト値は false です。
3
Job Service 設定フィールド。
4
enabled: true を設定すると、Job Service がデプロイされます。false に設定するか、省略すると、デプロイメントは無効になります。デフォルト値は false です。

4.3.3. サポートサービスのスコープ

SonataFlowPlatform カスタムリソース (CR) は、特定の namespace 内でのサポートサービスのデプロイメントを有効にします。つまり、自動的に設定されたサポートサービスとワークフロー通信はすべて、デプロイされたプラットフォームの namespace に制限されます。

この機能は、異なるワークフローセットごとにサポートサービスの個別のインスタンスが必要な場合に特に有用です。たとえば、ワークフローやサポートサービスと共にアプリケーションを分離してデプロイすることで、他のデプロイメントからの独立性を保つことができます。

4.3.4. サポートサービスの永続性設定

OpenShift Serverless Logic のサポートサービスの永続性設定は、環境のニーズに応じて、一時的または PostgreSQL のいずれかの設定になります。一時的な永続性は開発とテストに適していますが、実稼働環境には PostgreSQL 永続性が推奨されます。

4.3.4.1. 一時的な永続性設定

一時的な永続性は、各サービス専用の組み込み PostgreSQL データベースを使用します。OpenShift Serverless Logic Operator は、すべてのサービスの再起動でこのデータベースを再作成し、開発およびテストの目的でのみ適切になるようにします。次の SonataFlowPlatform CR 以外の追加の設定は必要ありません。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform-example
  namespace: example-namespace
spec:
  services:
    dataIndex:
      enabled: true
      # Specific configurations for the Data Index Service
      # might be included here
    jobService:
      enabled: true
      # Specific configurations for the Job Service
      # might be included here
Copy to Clipboard Toggle word wrap
4.3.4.2. PostgreSQL の永続性設定

PostgreSQL の永続性の場合、クラスターに PostgreSQL サーバーインスタンスをセットアップする必要があります。このインスタンスの管理は、OpenShift Serverless Logic Operator 制御とは独立して維持されます。サポートサービスを PostgreSQL サーバーに接続するには、適切なデータベース接続パラメーターを設定する必要があります。

次の例を使用して、SonataFlowPlatform CR で PostgreSQL の永続性を設定できます。

PostgreSQL の永続性設定の例

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform-example
  namespace: example-namespace
spec:
  services:
    dataIndex:
      enabled: true
      persistence:
        postgresql:
          serviceRef:
            name: postgres-example 
1

            namespace: postgres-example-namespace 
2

            databaseName: example-database 
3

            databaseSchema: data-index-schema 
4

            port: 1234 
5

          secretRef:
            name: postgres-secrets-example 
6

            userKey: POSTGRESQL_USER 
7

            passwordKey: POSTGRESQL_PASSWORD 
8

    jobService:
      enabled: true
      persistence:
        postgresql:
        # Specific database configuration for the Job Service
        # might be included here.
Copy to Clipboard Toggle word wrap

1
PostgreSQL データベースサーバーに接続するためのサービスの名前。
2
オプション: PostgreSQL Service の namespace を定義します。デフォルトは SonataFlowPlatform の namespace です。
3
サポートサービスデータを格納する PostgreSQL データベースの名前を定義します。
4
オプション: サポートサービスデータを格納するためのスキーマを指定します。デフォルト値は SonataFlowPlatform 名で、接尾辞には -data-index-service or -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>
Copy to Clipboard Toggle word wrap
4.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)。

4.3.5. サポートサービスイベントシステムの設定

OpenShift Serverless Logic インストールの場合、以下のタイプのイベントが生成されます。

  • ビジネスロジックのワークフローに関連する発信イベントおよび着信イベント。
  • ワークフローから Data Index および Job Service に送信されるイベント。
  • Job Service から Data Index Service に送信されるイベント。

OpenShift Serverless Logic Operator は Knative Eventing システムを利用して、これらのイベントとサービス間のすべてのイベント通信を管理し、効率的で信頼性の高いイベント処理を実現します。

4.3.5.1. プラットフォームスコープのイベントシステム設定

プラットフォームスコープのイベントシステムを設定するには、SonataFlowPlatform CR の spec.eventing.broker.ref フィールドを使用して、Knative Eventing Broker を参照します。この設定は、指定されたブローカーを使用して、サポートサービスを自動的にリンクし、イベントを生成および消費するように OpenShift Serverless Logic Operator に指示します。

preview または gitops プロファイルで同じ namespace にデプロイされ、カスタムのイベントシステム設定がないワークフローは、自動的に指定されたブローカーにリンクされます。

重要

実稼働環境では、Knative Kafka Broker などの実稼働環境対応のブローカーを使用して、スケーラビリティーと信頼性を強化します。

次の例は、プラットフォームスコープのイベントシステムに SonataFlowPlatform CR を設定する方法を示しています。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform-example
  namespace: example-namespace
spec:
  eventing:
    broker:
      ref:
        name: example-broker 
1

        namespace: example-broker-namespace 
2

        apiVersion: eventing.knative.dev/v1
        kind: Broker
Copy to Clipboard Toggle word wrap
1
Knative Eventing Broker 名を指定します。
2
オプション: Knative Eventing Broker の namespace を定義します。値を指定しない場合、パラメーターはデフォルトで SonataFlowPlatform namespace に設定されます。SonataFlowPlatform と同じ namespace に Broker を作成することを検討してください。
4.3.5.2. サービススコープのイベントシステム設定

サービススコープのイベントシステム設定により、イベントシステム (特に Data Index または Job Service) を細かく制御できます。

注記

OpenShift Serverless Logic インストールの場合は、プラットフォームスコープのイベントシステム設定の使用を検討してください。サービススコープの設定は、高度なユースケースのみを対象としています。

4.3.5.3. Data Index のイベントシステム設定

Data Index のサービススコープのイベントシステムを設定するには、SonataFlowPlatform CR の spec.services.dataIndex.source.ref フィールドを使用して、特定の Knative Eventing Broker を参照する必要があります。この設定は、OpenShift Serverless Logic Operator に対して、その Broker からの SonataFlow システムイベントを消費するように Data Index を自動的にリンクするように指示します。

重要

実稼働環境では、Knative Kafka Broker などの実稼働環境対応のブローカーを使用して、スケーラビリティーと信頼性を強化します。

次の例は、Data Index イベントシステム設定を表示しています。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform-example
spec:
  services:
    dataIndex:
      source:
        ref:
          name: data-index-source-example-broker 
1

          namespace: data-index-source-example-broker-namespace 
2

          apiVersion: eventing.knative.dev/v1
          kind: Broker
Copy to Clipboard Toggle word wrap
1
Data Index がイベントを消費する Knative Eventing Broker を指定します。
2
オプション: Knative Eventing Broker の namespace を定義します。値を指定しない場合、パラメーターはデフォルトで SonataFlowPlatform namespace に設定されます。SonataFlowPlatform と同じ namespace にブローカーを作成することを検討してください。
4.3.5.4. Job Service のイベントシステム設定

Job Service 用にサービススコープのイベントシステムを設定するには、SonataFlowPlatform CR の spec.services.jobService.source.ref および spec.services.jobService.sink.ref フィールドを使用する必要があります。これらのフィールドは、指定された設定に基づいて、Job Service を自動的にリンクして SonataFlow システムイベントを消費するように、OpenShift Serverless Logic Operator に指示します。

重要

実稼働環境では、Knative Kafka Broker などの実稼働環境対応のブローカーを使用して、スケーラビリティーと信頼性を強化します。

次の例は、Job Service のイベントシステム設定を表示しています。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform-example
spec:
  services:
    jobService:
      source:
        ref:
          name: jobs-service-source-example-broker 
1

          namespace: jobs-service-source-example-broker-namespace 
2

          apiVersion: eventing.knative.dev/v1
          kind: Broker
      sink:
        ref:
          name: jobs-service-sink-example-broker 
3

          namespace: jobs-service-sink-example-broker-namespace 
4

          apiVersion: eventing.knative.dev/v1
          kind: Broker
Copy to Clipboard Toggle word wrap
1
Job Service がイベントを消費する Knative Eventing Broker を指定します。
2
オプション: Knative Eventing Broker の namespace を定義します。値を指定しない場合、パラメーターはデフォルトで SonataFlowPlatform namespace に設定されます。SonataFlowPlatform と同じ namespace に Broker を作成することを検討してください。
3
Job Service がイベントを生成する Knative Eventing Broker を指定します。
4
オプション: Knative Eventing Broker の namespace を定義します。値を指定しない場合、パラメーターはデフォルトで SonataFlowPlatform namespace に設定されます。SonataFlowPlatform と同じ namespace に Broker を作成することを検討してください。
4.3.5.5. サポートサービス向けのクラスタースコープのイベントシステム設定

クラスタースコープのサポートサービスをデプロイする場合、サポートサービスは、SonataFlowClusterPlatform CR によって参照される SonataFlowPlatform CR で指定された Broker に自動的にリンクされます。

4.3.5.6. サポートサービスの Eventing システム設定の優先度ルール

OpenShift Serverless Logic Operator は定義された優先順位に従って、サポートサービスのイベントシステムを設定します。

Eventing システム設定の優先度ルールは以下のとおりです。

  1. サポートサービスに、Data Index イベントシステムまたは Job Service イベントシステム設定のいずれかを使用した独自のイベントシステム設定がある場合は、サポートサービスの設定が優先されます。
  2. サポートサービスを囲む SonataFlowPlatform CR がプラットフォームスコープのイベントシステムで設定されている場合、その設定が優先されます。
  3. 現在のクラスターがクラスタースコープのイベントシステムで設定されている場合は、その設定が優先されます。
  4. 以前の設定がいずれも存在しない場合は、サポートサービスは直接 HTTP 呼び出しによってイベントを提供します。
4.3.5.7. Eventing システムのリンク設定

OpenShift Serverless Logic Operator は、サポートサービスをイベントシステムにリンクするために、Knative Eventing、SinkBindings、およびトリガーを自動的に作成します。これらのオブジェクトにより、サポートサービスによるイベントの生成と消費が可能になります。

次の例は、SonataFlowPlatform CR 用に作成された Knative Native イベントオブジェクトを示しています。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform-example
  namespace: example-namespace
spec:
  eventing:
    broker:
      ref:
        name: example-broker 
1

        apiVersion: eventing.knative.dev/v1
        kind: Broker
  services:
    dataIndex: 
2

      enabled: true
    jobService: 
3

      enabled: true
Copy to Clipboard Toggle word wrap
1
オーバーライドされない限り、Data Index、Job Service、およびワークフローで使用されます。
2
Data Index の一時デプロイメント、Data Index サービスを設定します。
3
Job Service の一時的なデプロイメント。Job Service を設定します。

次の例は、SonataFlowPlatform CR で使用する Knative Kafka Broker を設定する方法を示しています。

SonataFlowPlatform CR によって使用される Knative Kafka Broker の例

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  annotations:
    eventing.knative.dev/broker.class: Kafka 
1

  name: example-broker
  namespace: example-namespace
spec:
  config:
    apiVersion: v1
    kind: ConfigMap
    name: kafka-broker-config
    namespace: knative-eventing
Copy to Clipboard Toggle word wrap

1
Kafka クラスを使用して Kafka Knative Broker を作成します。

次のコマンドは、どのサービスがイベントにサブスクライブされているかを示す、Data Index および Job Service イベントにセットアップされたトリガーのリストを表示します。

$ oc get triggers -n example-namespace
Copy to Clipboard Toggle word wrap

出力例

NAME                                                        BROKER           SINK                                                       AGE   CONDITIONS   READY   REASON
data-index-jobs-fbf285df-c0a4-4545-b77a-c232ec2890e2        example-broker   service:sonataflow-platform-example-data-index-service     106s  7 OK / 7    True    -
data-index-process-definition-e48b4e4bf73e22b90ecf7e093ff6b1eaf   example-broker   service:sonataflow-platform-example-data-index-service     106s  7 OK / 7    True    -
data-index-process-error-fbf285df-c0a4-4545-b77a-c232ec2890e2   example-broker   service:sonataflow-platform-example-data-index-service     106s  7 OK / 7    True    -
data-index-process-instance-mul35f055c67a626f51bb8d2752606a6b54   example-broker   service:sonataflow-platform-example-data-index-service     106s  7 OK / 7    True    -
data-index-process-node-fbf285df-c0a4-4545-b77a-c232ec2890e2      example-broker   service:sonataflow-platform-example-data-index-service     106s  7 OK / 7    True    -
data-index-process-state-fbf285df-c0a4-4545-b77a-c232ec2890e2     example-broker   service:sonataflow-platform-example-data-index-service     106s  7 OK / 7    True    -
data-index-process-variable-ac727d6051750888dedb72f697737c0dfbf   example-broker   service:sonataflow-platform-example-data-index-service     106s  7 OK / 7    True    -
jobs-service-create-job-fbf285df-c0a4-4545-b77a-c232ec2890e2    example-broker   service:sonataflow-platform-example-jobs-service         106s  7 OK / 7    True    -
jobs-service-delete-job-fbf285df-c0a4-4545-b77a-c232ec2890e2    example-broker   service:sonataflow-platform-example-jobs-service         106s  7 OK / 7    True    -
Copy to Clipboard Toggle word wrap

Job Service の SinkBinding リソースを表示するには、以下のコマンドを使用します。

$ oc get sources -n example-namespace
Copy to Clipboard Toggle word wrap

出力例

NAME                                          TYPE          RESOURCE                           SINK                    READY
sonataflow-platform-example-jobs-service-sb   SinkBinding   sinkbindings.sources.knative.dev   broker:example-broker   True
Copy to Clipboard Toggle word wrap

4.3.6. 高度なサポートサービス設定

サポートサービス向けに高度な設定を適用する必要がある場合は、SonataFlowPlatform カスタムリソース (CR) の podTemplate フィールドを使用します。このフィールドでは、レプリカの数、環境変数、コンテナーイメージ、初期化オプションなどの設定を指定して、サービス Pod のデプロイメントをカスタマイズできます。

次の例を使用して、サービスの高度な設定を行うことができます。

Data Index サービスの高度な設定例

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform-example
  namespace: example-namespace
spec:
  services:
    # This can be either 'dataIndex' or 'jobService'
    dataIndex:
      enabled: true
      podTemplate:
        replicas: 2 
1

        container: 
2

          env: 
3

            - name: <any_advanced_config_property>
              value: <any_value>
          image: 
4

        initContainers: 
5
Copy to Clipboard Toggle word wrap

注記

要件に応じて、'services' フィールドを 'dataIndex' または 'jobService' に設定できます。設定の残りの部分は同じままとなります。

1
レプリカの数を定義します。デフォルト値は 1 です。jobService の場合、この値はシングルトンサービスとして動作するため、常に 1 にオーバーライドされます。
2
サービスを実行しているコンテナーの特定の設定を保持します。
3
環境変数を指定して、サービスプロパティーを微調整できます。
4
サービスのコンテナーイメージを設定します。これは、イメージを更新またはカスタマイズする必要がある場合に役立ちます。
5
Pod の init コンテナーを設定します。これは、メインコンテナーが起動する前に前提条件をセットアップする際に役立ちます。
注記

podTemplate フィールドにより、各サポートサービスのデプロイメントを柔軟に調整できます。これは標準の PodSpec API に準拠します。つまり、同じ API 検証ルールがこれらのフィールドに適用されます。

4.3.7. クラスタースコープのサポートサービス

SonataFlowClusterPlatform カスタムリソース (CR) を使用して、さまざまな namespace にまたがるワークフローで使用できるクラスター全体のサポートサービスのセットを定義できます。既存の namespace 固有の SonataFlowPlatform CR を参照すると、これらのサービスの使用をクラスター全体で拡張できます。

次の基本設定の例を使用すると、任意の namespace にデプロイされたワークフローが、example-namespace などの特定の namespace にデプロイされたサポートサービスを利用できるようになります。

SonataFlowClusterPlatform CR の例

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowClusterPlatform
metadata:
  name: cluster-platform
spec:
  platformRef:
    name: sonataflow-platform-example 
1

    namespace: example-namespace 
2
Copy to Clipboard Toggle word wrap

1
サポートサービスを管理するすでにインストールされている SonataFlowPlatform CR の名前を指定します。
2
サポートサービスを管理する SonataFlowPlatform CR の namespace を指定します。
注記

SonataFlowPlatform.spec.services でその namespace を設定することにより、これらのクラスター全体のサービスを任意の namespace 内でオーバーライドできます。

第5章 ワークフローの永続性の管理

SonataFlow インスタンスを設定して、永続性を使用し、ワークフローコンテキストをリレーショナルデータベースに保存することができます。

設計上、Kubernetes Pod はステートレスです。この動作は、Pod の再起動後もアプリケーションの状態を維持する必要があるワークロードに関する課題が生じる可能性があります。OpenShift Serverless Logic の場合、Pod がデフォルトで再起動するとワークフローコンテキストが失われます。

このようなシナリオでワークフローリカバリーを確保するには、ワークフローのランタイムの永続性を設定する必要があります。SonataFlowPlatform カスタムリソース (CR) または SonataFlow CR を使用してこの設定を指定します。設定のスコープは使用するリソースによって異なります。

5.1. SonataFlowPlatform CR を使用した永続性の設定

SonataFlowPlatform カスタムリソース (CR) は、namespace レベルでの永続性設定を有効にします。このアプローチでは、namespace にデプロイされたすべてのワークフローに永続性設定が自動的に適用されます。これにより、特に namespace 内の複数のワークフローが同じアプリケーションに属する場合に、リソース設定が簡素化されます。この設定はデフォルトで適用されますが、namespace 内の個々のワークフローは SonataFlow CR を使用してこれをオーバーライドできます。

OpenShift Serverless Logic Operator は、この設定を使用してサポートサービスの永続性もセットアップします。

注記

永続性設定は、ワークフローのデプロイメント時にのみ適用されます。SonataFlowPlatform CR への変更は、すでにデプロイされているワークフローには影響しません。

手順

  1. SonataFlowPlatform CR を定義します。
  2. SonataFlowPlatform CR 仕様の下にある persistence フィールドに永続性設定を指定します。

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowPlatform
    metadata:
      name: sonataflow-platform-example
      namespace: example-namespace
    spec:
      persistence:
        postgresql:
          serviceRef:
            name: postgres-example 
    1
    
            namespace: postgres-example-namespace 
    2
    
            databaseName: example-database 
    3
    
            port: 1234 
    4
    
          secretRef:
            name: postgres-secrets-example 
    5
    
            userKey: POSTGRESQL_USER 
    6
    
            passwordKey: POSTGRESQL_PASSWORD 
    7
    Copy to Clipboard Toggle word wrap
    1
    PostgreSQL データベースに接続する Kubernetes Service の名前。
    2
    オプション: PostgreSQL Service の namespace。デフォルトは SonataFlowPlatform の namespace です。
    3
    ワークフローデータを格納する PostgreSQL データベースの名前。
    4
    オプション: PostgreSQL Service に接続するためのポート番号。デフォルトは 5432 です。
    5
    データベース認証情報が含まれる Kubernetes シークレットの名前。
    6
    データベースのユーザー名が含まれる Secret オブジェクトのキー。
    7
    データベースのパスワードが含まれる Secret オブジェクトのキー。
  3. ワークフロー用に生成された環境変数を表示します。

    次の例は、以前の SonataFlowPlatform 設定でデプロイされた example-workflow という名前のワークフロー用に生成された環境変数を示しています。これらの設定は永続性に特化したもので、OpenShift Serverless Logic Operator によって管理されます。これらの設定は、適用後は変更できません。

注記

SonataFlowPlatform の永続性を使用する場合、すべてのワークフローは、ワークフロー名と同じ PostgreSQL スキーマ名を使用するように設定されています。

env:
  - name: QUARKUS_DATASOURCE_USERNAME
    valueFrom:
      secretKeyRef:
        name: postgres-secrets-example
        key: POSTGRESQL_USER
  - name: QUARKUS_DATASOURCE_PASSWORD
    valueFrom:
      secretKeyRef:
        name: postgres-secrets-example
        key: POSTGRESQL_PASSWORD
  - name: QUARKUS_DATASOURCE_DB_KIND
    value: postgresql
  - name: QUARKUS_DATASOURCE_JDBC_URL
    value: >-
      jdbc:postgresql://postgres-example.postgres-example-namespace:1234/example-database?currentSchema=example-workflow
  - name: KOGITO_PERSISTENCE_TYPE
    value: jdbc
Copy to Clipboard Toggle word wrap

この永続性設定が適用されると、OpenShift Serverless Logic Operator は preview または gitops プロファイルを使用して、この namespace にデプロイされたすべてのワークフローを設定し、関連する JDBC 接続パラメーターを環境変数として注入して PostgreSQL データベースに接続します。

注記

現在、PostgreSQL は唯一永続性向けにサポートされているデータベースです。

preview プロファイルを使用した SonataFlow CR デプロイメントの場合、OpenShift Serverless Logic ビルドシステムには、永続性の有効化に必要な特定の Quarkus エクステンションが自動的に含まれます。これにより、永続性メカニズムとの互換性が確保され、ワークフローのデプロイメントプロセスが合理化されます。

5.2. SonataFlow CR を使用した永続性の設定

SonataFlow カスタムリソース (CR) は、ワークフロー固有の永続性設定を有効にします。この設定は、SonataFlowPlatform の永続性がすでに現在の namespace に設定されている場合でも、独立して使用できます。

手順

  • 以下の例のように、SonataFlow CR 仕様の persistence フィールドを使用して永続性を設定します。
apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
  name: example-workflow
  annotations:
    sonataflow.org/description: Example Workflow
    sonataflow.org/version: 0.0.1
spec:
  persistence:
    postgresql:
      serviceRef:
        name: postgres-example 
1

        namespace: postgres-example-namespace 
2

        databaseName: example-database 
3

        databaseSchema: example-schema 
4

        port: 1234 
5

      secretRef:
        name: postgres-secrets-example 
6

        userKey: POSTGRESQL_USER 
7

        passwordKey: POSTGRESQL_PASSWORD 
8

  flow:
Copy to Clipboard Toggle word wrap
1
PostgreSQL データベースサーバーに接続する Kubernetes Service の名前。
2
オプション: PostgreSQL Service を含む namespace。デフォルトはワークフロー namespace です。
3
ワークフローデータが保存される PostgreSQL データベースの名前。
4
オプション: ワークフローデータのデータベーススキーマの名前。デフォルトはワークフロー名です。
5
オプション: PostgreSQL Service に接続するためのポート。デフォルトは 5432 です。
6
データベース認証情報が含まれる Kubernetes シークレットの名前。
7
データベースのユーザー名が含まれる Secret オブジェクトのキー。
8
データベースのパスワードが含まれる Secret オブジェクトのキー。

この設定は、デプロイ時にワークフローが指定の PostgreSQL データベースサーバーに接続する必要があることを OpenShift Serverless Logic Operator に通知します。OpenShift Serverless Logic Operator は、関連する JDBC 接続パラメーターを環境変数としてワークフローコンテナーに追加します。

注記

現在、PostgreSQL は唯一永続性向けにサポートされているデータベースです。

preview プロファイルを使用した SonataFlow CR デプロイメントの場合、OpenShift Serverless Logic ビルドシステムには、永続性を自動的に有効化するために必要な Quarkus エクステンションが含まれています。

5.3. 永続性設定の優先度ルール

SonataFlow カスタムリソース (CR) の永続性は個別に使用することも、SonataFlowPlatform CR 永続性と一緒に使用することもできます。SonataFlowPlatform CR の永続性設定が現在の namespace に存在する場合、以下のルールによって、適用される永続性設定が決まります。

  1. SonataFlow CR に永続性設定が含まれている場合、その設定が優先されワークフローに適用されます。
  2. SonataFlow CR に永続性設定が含まれておらず、spec.persistence フィールドがない場合、OpenShift Serverless Logic Operator は現在の SonataFlowPlatform の永続性設定を使用します (存在する場合)。
  3. ワークフローの永続性を無効にするには、SonataFlow CR で spec.persistence: {} を明示的に設定します。この設定により、ワークフローは SonataFlowPlatform CR から永続性設定を継承しません。

5.4. プロファイル固有の永続要件

SonataFlowPlatform カスタムリソース (CR) と SonataFlow CR の両方に提供される永続性設定は、preview および gitops プロファイルと同じように適用されます。ただし、dev プロファイルはこれらの設定を完全に無視するため、dev プロファイルでは使用しないでください。

preview および gitops プロファイルの主な違いは、ビルドプロセスにあります。

gitops プロファイルを使用する場合は、ビルドプロセス中に以下の Quarkus エクステンションがワークフローイメージに含まれていることを確認してください。

Expand
groupIdartifactIdversion

io.quarkus

quarkus-agroal

3.8.6.redhat-00004

io.quarkus

quarkus-jdbc-postgresql

3.8.6.redhat-00004

org.kie

kie-addons-quarkus-persistence-jdbc

9.102.0.redhat-00005

registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.35.0 を使用してイメージを生成する場合は、以下のビルド引数を渡してこれらのエクステンションを含めることができます。

$ QUARKUS_EXTENSIONS=io.quarkus:quarkus-agroal:3.8.6.redhat-00004,io.quarkus:quarkus-jdbc-postgresql:3.8.6.redhat-00004,org.kie:kie-addons-quarkus-persistence-jdbc:9.102.0.redhat-00005
Copy to Clipboard Toggle word wrap

5.5. データベーススキーマの初期化

SonataFlow を PostgreSQL の永続性で使用している場合は、Flyway を有効にするか、Data Definition Language (DDL) スクリプトを使用してデータベーススキーマの更新を手動で適用することで、データベーススキーマを初期化できます。

Flyway は kie-addons-quarkus-flyway ランタイムモジュールで管理されており、デフォルトでは無効になっています。Flyway を有効にするには、以下のいずれかの方法で設定する必要があります。

5.5.1. ワークフロー ConfigMap での Flyway 設定

ワークフロー ConfigMap で Flyway を有効化するには、以下のプロパティーを追加します。

ワークフロー ConfigMap で Flyway を有効化する例

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: example-workflow
  name: example-workflow-props
data:
  application.properties: |
    kie.flyway.enabled = true
Copy to Clipboard Toggle word wrap

5.5.2. ワークフローコンテナーで環境変数を使用した Flyway 設定

次の例を使用して、SonataFlow CR の spec.podTemplate.container フィールドに環境変数を追加することで、Flyway を有効化できます。

ワークフローコンテナー環境変数を使用して Flyway を有効化する例

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
  name: example-workflow
  annotations:
    sonataflow.org/description: Example Workflow
    sonataflow.org/version: 0.0.1
spec:
  podTemplate:
    container:
      env:
        - name: KIE_FLYWAY_ENABLED
          value: 'true'
  flow: ...
Copy to Clipboard Toggle word wrap

5.5.3. SonataFlowPlatform プロパティーを使用した Flyway 設定

namespace 内のすべてのワークフローに共通の Flyway 設定を適用するには、以下の例に示されている SonataFlowPlatform CR の spec.properties.flow フィールドにプロパティーを追加します。

注記

この設定は、ワークフローのデプロイメント中に適用されます。ワークフローをデプロイする前に Flyway プロパティーが設定されていることを確認します。

SonataFlowPlatform プロパティーを使用して Flyway を有効化する例

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform
spec:
  properties:
    flow:
      - name: kie.flyway.enabled
        value: true
Copy to Clipboard Toggle word wrap

5.5.4. DDL スクリプトを使用した手動データベースの初期化

手動の初期化が必要な場合は、kie.flyway.enabled プロパティーが未設定であるか、明示的に false に設定されていることを確認して、Flyway を無効化する必要があります。

  • デフォルトでは、各ワークフローはワークフロー名と同じスキーマ名を使用します。各ワークフローにスキーマの初期化を手動で適用してください。
  • SonataFlow カスタムリソース (CR) の永続性設定を使用している場合は、カスタムスキーマ名を指定できます。

手順

  1. kogito-ddl-9.102.0.redhat-00005-db-scripts.zip ロケーションから DDL スクリプトをダウンロードします。
  2. ファイルを展開します。
  3. ターゲットである PostgreSQL データベースの root ディレクトリーにある .sql ファイルを実行します。ファイルがバージョン番号の順序で実行されることを確認してください。

    以下に例を示します。

    • V1.35.0__create_runtime_PostgreSQL.sql
    • V10.0.0__add_business_key_PostgreSQL.sql
    • V10.0.1__alter_correlation_PostgreSQL.sql

      注記

      ファイルバージョン番号は、OpenShift Serverless Logic Operator のバージョン管理に関連付けられていません。

第6章 ワークフローのイベントシステム

SonataFlow ワークフローのイベントシステムをセットアップできます。

OpenShift Serverless Logic のインストールでは、以下のタイプのイベントが生成されます。

  • ビジネスロジックのワークフローに関連する発信イベントおよび着信イベント。
  • ワークフローから Data Index および Job Service に送信されるイベント。
  • Job Service から Data Index Service に送信されるイベント。

OpenShift Serverless Logic Operator は Knative Eventing システムを利用して、これらのサービス間のすべてのイベント通信を管理し、効率的で信頼性の高いイベント処理を実現します。

6.1. プラットフォームスコープのイベントシステム設定

プラットフォームスコープのイベントシステムを設定するには、SonataFlowPlatform カスタムリソース (CR) の spec.eventing.broker.ref フィールドを使用して、Knative Eventing Broker を参照します。

この設定は、preview または gitops プロファイルを使用して、指定された namespace にデプロイされたすべてのワークフローを自動的にリンクするように OpenShift Serverless Logic Operator に指示します。これにより、定義されたブローカーを使用してイベントを生成および消費できます。

カスタムイベント設定なしで namespace にデプロイされたサポートサービスもこのブローカーにリンクされます。

注記

実稼働環境では、Knative Kafka Broker などの実稼働環境対応のブローカーを使用して、スケーラビリティーと信頼性を強化します。

次の例は、プラットフォームスコープのイベントシステムに SonataFlowPlatform CR を設定する方法を示しています。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform-example
  namespace: <example-namespace>
spec:
  eventing:
    broker:
      ref:
        name: example-broker 
1

        namespace: <example-broker-namespace> 
2

        apiVersion: eventing.knative.dev/v1
        kind: Broker
Copy to Clipboard Toggle word wrap
1
Knative Eventing Broker 名を指定します。
2
オプション: Knative Eventing Broker の namespace を指定します。値を指定しない場合、パラメーターはデフォルトで SonataFlowPlatform CR の namespace になります。SonataFlowPlatform と同じ namespace にブローカーを作成することを検討してください。

6.2. ワークフロースコープのイベントシステム設定

ワークフロースコープのイベントシステム設定を使用すると、特定のワークフローで生成および消費されるイベントの詳細なカスタマイズが可能になります。SonataFlow CR の spec.sink.ref および spec.sources[] フィールドを使用して、発信および着信イベントを設定できます。

6.2.1. 発信イベントシステムの設定

発信イベントを設定するには、SonataFlow CR の spec.sink.ref フィールドを使用できます。この設定により、ワークフローは、指定された Knative Eventing Broker を使用して、システムイベントとワークフローのビジネスイベントの両方を含むイベントを生成するようになります。

次の例は、ワークフロースコープの発信イベントシステムの SonataFlow CR を設定する方法を示しています。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
  name: example-workflow
  namespace: example-workflow-namespace
  annotations:
    sonataflow.org/description: Example Workflow
    sonataflow.org/version: 0.0.1
    sonataflow.org/profile: preview
spec:
  sink:
    ref:
      name: outgoing-example-broker 
1

      namespace: outgoing-example-broker-namespace 
2

      apiVersion: eventing.knative.dev/v1
      kind: Broker
  flow: 
3

    start: ExampleStartState
    events: 
4

      - name: outEvent1 
5

        source: ''
        kind: produced
        type: out-event-type1 
6

    ...
Copy to Clipboard Toggle word wrap
1
SonataFlow システムイベントを含む、ワークフローによって生成されるすべてのイベントに使用する Knative Eventing Broker の名前。
2
Knative Eventing Broker の namespace を定義します。値を指定しない場合、パラメーターはデフォルトで SonataFlow namespace に設定されます。SonataFlow と同じ namespace にブローカーを作成することを検討してください。
3
SonataFlow CR の Flow 定義フィールド。
4
SonataFlow CR のイベント定義フィールド。
5
発信イベント outEvent1 定義の例。
6
outEvent1 発信イベントのイベントタイプ。

6.2.2. 着信イベントシステム設定

着信イベントを設定するには、SonataFlow CR の spec.sources[] フィールドを使用します。特定の設定を必要とする各イベントタイプのエントリーを追加できます。このセットアップにより、ワークフローはイベントタイプに基づいて異なるブローカーからのイベントを消費できるようになります。

着信イベントタイプに特定の Broker 設定がない場合、システムはイベントシステム設定の優先度ルールを適用します。

次の例は、ワークフロースコープの着信イベントシステムの SonataFlow CR を設定する方法を示しています。

注記

spec.sources[] エントリーとワークフローイベント間のリンクには、イベントタイプが使用されます。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
  name: example-workflow
  namespace: example-workflow-namespace
  annotations:
    sonataflow.org/description: Example Workflow
    sonataflow.org/version: 0.0.1
    sonataflow.org/profile: preview
spec:
  sources:
    - eventType: in-event-type1 
1

      ref:
        name: incoming-example-broker1 
2

        namespace: incoming-example-broker1-namespace 
3

        apiVersion: eventing.knative.dev/v1
        kind: Broker
    - eventType: in-event-type2 
4

      ref:
        name: incoming-example-broker2 
5

        namespace: incoming-example-broker2-namespace 
6

        apiVersion: eventing.knative.dev/v1
        kind: Broker
  flow: 
7

    start: ExampleStartState
    events: 
8

      - name: inEvent1 
9

        source: ''
        kind: consumed
        type: in-event-type1 
10

      - name: inEvent2 
11

        source: ''
        kind: consumed
        type: in-event-type2 
12

    ...
Copy to Clipboard Toggle word wrap
1
指定された Knative Eventing Broker を使用して in-event-type1 タイプのイベントを消費するようにワークフローを設定します。
2
このワークフローに送信された in-event-type1 タイプのイベントを消費するために使用する Knative Eventing Broker の名前。
3
オプション: 値を指定しない場合、パラメーターはデフォルトで SonataFlow namespace に設定されます。SonataFlow ワークフローと同じ namespace にブローカーを作成することを検討してください。
4
指定された Knative Eventing Broker を使用して in-event-type2 タイプのイベントを消費するようにワークフローを設定します。
5
このワークフローに送信された in-event-type2 タイプのイベントを消費するために使用する Knative Eventing Broker の名前。
6
オプション: 値を指定しない場合、パラメーターはデフォルトで SonataFlow namespace に設定されます。SonataFlow ワークフローと同じ namespace にブローカーを作成することを検討してください。
7
SonataFlow CR の Flow 定義フィールド。
8
SonataFlow CR のイベント定義フィールド。
9
着信イベント inEvent1 定義の例。
10
着信イベント inEvent1 のイベントタイプ。対応する spec.sources[] エントリーを含むワークフローイベントのリンクは、イベントタイプ名 in-event-type1 を使用します。
11
着信イベント inEvent2 定義の例。
12
着信イベント inEvent2 のイベントタイプ。対応する spec.sources[] エントリーを含むワークフローイベントのリンクは、イベントタイプ名 in-event-type2 を使用して作成されます。

6.3. クラスタースコープのイベントシステム設定

SonataFlowClusterPlatform セットアップでは、ワークフローは関連付けられた SonataFlowPlatform CR で指定された Broker に自動的にリンクされます。このリンクは、Eventing System 設定の優先度ルールに従います。

適切なインテグレーションを確保するには、SonataFlowClusterPlatform CR によって参照される SonataFlowPlatform CR に Broker を設定できます。

次の例は、SonataFlowClusterPlatform CR とその SonataFlowPlatform CR への参照を設定する方法を示しています。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: global-platform
  namespace: global-namespace
spec:
  eventing:
    broker:
      ref:
        name: global-broker
        namespace: global-namespace
        apiVersion: eventing.knative.dev/v1
        kind: Broker
---
apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowClusterPlatform
metadata:
  name: cluster-platform-example
spec:
  platformRef:
    name: global-platform
    namespace: global-namespace
    ...
Copy to Clipboard Toggle word wrap
注記

SonataFlowClusterPlatform CR はすでにデプロイされている任意の SonataFlowPlatform CR を参照できます。

6.4. Eventing システム設定の優先度ルール

OpenShift Serverless Logic Operator は、定義された優先順位に従って、ワークフローのイベントシステム設定を判別します。

Eventing システム設定の優先度ルールは以下のとおりです。

  1. ワークフロースコープの発信または着信イベントシステム設定のいずれかを使用して、定義されたイベントシステムがワークフローにある場合、選択した設定は他の設定よりも優先され、ワークフローに適用されます。
  2. ワークフローを含む SonataFlowPlatform CR にプラットフォームスコープのイベントシステムが設定されている場合、この設定は次のステップに適用されます。
  3. 現在のクラスターがクラスタースコープのイベントシステムで設定されている場合は、ワークフロースコープまたはプラットフォームスコープの設定が存在しない場合に適用されます。
  4. 上記のいずれの設定も定義されていない場合は、以下の情報を確認してください。

    • ワークフローでは、直接 HTTP 呼び出しを使用して、SonataFlow システムイベントをサポートサービスに提供します。
    • ワークフローは、ワークフローサービスの root パス / で HTTP POST 呼び出しによる着信イベントを消費します。
    • ワークフローのビジネスイベントを生成するイベントシステムは設定されていません。このようなイベントを生成しようとしても、失敗する可能性があります。

6.5. イベントシステムへのワークフローのリンク

OpenShift Serverless Logic Operator は、Knative Eventing、SinkBinding、およびトリガーを使用してイベントシステムとワークフローをリンクします。これらのオブジェクトは OpenShift Serverless Logic Operator によって自動的に作成され、ワークフローイベントの生成および消費を単純化します。

以下の例は、プラットフォームスコープのイベントシステムで設定された example-workflow ワークフロー用に作成された Knative Eventing オブジェクトを示しています。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
  name: sonataflow-platform-example
  namespace: example-namespace
spec:
  eventing:
    broker:
      ref:
        name: example-broker 
1

        apiVersion: eventing.knative.dev/v1
        kind: Broker
  services:
    dataIndex: 
2

      enabled: true
    jobService: 
3

      enabled: true
  ...
Copy to Clipboard Toggle word wrap
1
example-broker オブジェクトは、Data Index、Jobs Service、および example-workflow ワークフローによって使用されます。
2
Data Index は、一時設定でデプロイされます。
3
Job Service は、一時設定でデプロイされます。

example-broker オブジェクトは Kafka クラス Broker で、その設定は kafka-broker-config config map で定義されます。

次の例は、SonataFlowPlatform で使用する Kafka Knative Broker を設定する方法を示しています。

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  annotations:
    eventing.knative.dev/broker.class: Kafka 
1

  name: example-broker
  namespace: example-namespace
spec:
  config:
    apiVersion: v1
    kind: ConfigMap
    name: kafka-broker-config
    namespace: knative-eventing
Copy to Clipboard Toggle word wrap
1
Kafka クラスは、example-broker オブジェクトの作成に使用されます。

以下の例は、イベントの生成および消費用に、example-workflowexample-namespaceexample-broker に自動的にリンクされる方法を示しています。

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
  name: example-workflow
  namespace: example-namespace
  annotations:
    sonataflow.org/description: Example Workflow
    sonataflow.org/version: 0.0.1
    sonataflow.org/profile: preview
spec:
  flow:
    start: ExampleStartState
    events:
      - name: outEvent1
        source: ''
        kind: produced
        type: out-event-type1 
1

      - name: inEvent1
        source: ''
        kind: consumed
        type: in-event-type1 
2

      - name: inEvent2
        source: ''
        kind: consumed
        type: in-event-type2 
3

    states:
      - name: ExampleStartState
    ...
Copy to Clipboard Toggle word wrap
1
example-workflow 発信イベントは、example-workflow-sb という名前の SinkBinding を使用して生成されます。
2
タイプ in-event-type1 のイベントは、example-workflow-inevent1-b40c067c-595b-4913-81a4-c8efa980bc11 トリガーを使用して消費されます。
3
タイプ in-event-type2 のイベントは、example-workflow-inevent2-b40c067c-595b-4913-81a4-c8efa980bc11 トリガーを使用して消費されます。

以下のコマンドを使用して、example-workflow-sb という名前の自動作成された SinkBinding をリスト表示できます。

$ oc get sinkbindings -n example-namespace
Copy to Clipboard Toggle word wrap

出力例

NAME                   TYPE          RESOURCE                           SINK                    READY
example-workflow-sb    SinkBinding   sinkbindings.sources.knative.dev   broker:example-broker   True
Copy to Clipboard Toggle word wrap

以下のコマンドを使用して、イベント消費用に自動作成されたトリガーをリスト表示できます。

$ oc get triggers -n <example-namespace>
Copy to Clipboard Toggle word wrap

出力例

NAME                                                              BROKER           SINK                                                     AGE   CONDITIONS   READY   REASON
example-workflow-inevent1-b40c067c-595b-4913-81a4-c8efa980bc11    example-broker   service:example-workflow                                 16m   7 OK / 7     True
example-workflow-inevent2-b40c067c-595b-4913-81a4-c8efa980bc11    example-broker   service:example-workflow                                 16m   7 OK / 7     True
Copy to Clipboard Toggle word wrap

第7章 アップグレードの管理

7.1. OpenShift Serverless Logic Operator をバージョン 1.34.0 から 1.35.0 にアップグレードする

このセクションでは、OpenShift Serverless Logic Operator をバージョン 1.34.0 から 1.35.0 にアップグレードする手順を段階的に説明します。アップグレードプロセスには、既存のワークフローとサービスの準備、Operator の更新、アップグレード後のワークフローの復元が含まれます。

注記

ワークフロープロファイルごとに、必要なアップグレード手順が異なります。各プロファイルの指示に注意深く従ってください。

7.1.1. アップグレードの準備

アップグレードプロセスを開始する前に、OpenShift Serverless Logic 環境を準備する必要があります。このセクションでは、バージョン 1.34.0 から 1.35.0 へのアップグレードに必要な手順について説明します。

準備プロセスには以下が含まれます。

  • プロファイルに基づいてワークフローを削除またはスケーリングします。
  • 必要なすべてのデータベースとリソースをバックアップします。
  • すべてのカスタム設定の記録があることを確認します。
  • 永続性を使用したワークフローに必要なデータベース移行スクリプトを実行します。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Serverless Logic Operator がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • Operator のアップグレード用の OpenShift 管理コンソール にアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
7.1.1.1. dev プロファイルを使用してワークフローを削除する

Operator をアップグレードする前に、dev プロファイルで実行されているワークフローを削除し、アップグレードの完了後に再デプロイする必要があります。

手順

  1. SonataFlow カスタムリソース定義 (CRD)、ConfigMaps、その他の関連するカスタム設定など、必要なすべての Kubernetes リソースのバックアップがあることを確認します。
  2. 次のコマンドを実行してワークフローを削除します。

    $ oc delete -f <my-workflow.yaml> -n <target_namespace>
    Copy to Clipboard Toggle word wrap
7.1.1.2. preview プロファイルを使用したワークフローの削除と移行

Operator をアップグレードする前に、Preview プロファイルで実行されているワークフローを削除し、保持されているすべてのデータを移行する必要があります。アップグレードが完了したら、ワークフローを再デプロイする必要があります。

手順

  1. 永続性を使用している場合は、ワークフローデータベースをバックアップし、バックアップにデータベースオブジェクトとテーブルデータの両方が含まれていることを確認します。
  2. SonataFlow CRD、ConfigMaps、その他の関連するカスタム設定など、必要なすべての Kubernetes リソースのバックアップがあることを確認します。
  3. 次のコマンドを実行してワークフローを削除します。

    $ oc delete -f <my-workflow.yaml> -n <target_namespace>
    Copy to Clipboard Toggle word wrap
  4. 永続性を使用している場合は、次のデータベース移行スクリプトを実行する必要があります。

    ALTER TABLE flyway_schema_history
        RENAME CONSTRAINT flyway_schema_history_pk TO kie_flyway_history_runtime_persistence_pk;
    
    ALTER INDEX flyway_schema_history_s_idx
      RENAME TO kie_flyway_history_runtime_persistence_s_idx;
    
    ALTER TABLE flyway_schema_history RENAME TO kie_flyway_history_runtime_persistence;
    Copy to Clipboard Toggle word wrap
7.1.1.3. gitops プロファイルを使用してワークフローをスケールダウンする

Operator をアップグレードする前に、gitops プロファイルで実行されているワークフローをスケールダウンし、アップグレードの完了後に再度スケールアップする必要があります。

手順

  1. 次の例に示すように、アップグレードする前に、my-workflow.yaml CRD を変更し、各ワークフローを zero にスケールダウンします。

    spec:
      podTemplate:
        replicas: 0
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、更新された CRD を適用します。

    $ oc apply -f <my-workflow.yaml> -n <target_namespace>
    Copy to Clipboard Toggle word wrap
  3. (オプション) 次のコマンドを実行して、ワークフローを 0 にスケーリングします。

    $ oc patch sonataflow <my-workflow> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 0}}}'
    Copy to Clipboard Toggle word wrap
7.1.1.4. Data Index データベースのバックアップ

データの損失を防ぐために、アップグレードする前に Data Index データベースをバックアップする必要があります。

手順

  • 次の点を確認して、Data Index データベースの完全バックアップを実行します。

    • バックアップには、テーブルデータだけでなく、すべてのデータベースオブジェクトが含まれます。
    • バックアップはセキュアなロケーションに保存されます。
7.1.1.5. Jobs Service データベースのバックアップ

ジョブスケジュールデータを維持するために、アップグレードする前に Jobs Service データベースをバックアップする必要があります。

手順

  • 次の点を確認して、Jobs Service データベースの完全バックアップを実行します。

    • バックアップには、テーブルデータだけでなく、すべてのデータベースオブジェクトが含まれます。
    • バックアップはセキュアなロケーションに保存されます。

7.1.2. OpenShift Serverless Logic Operator のアップグレード

OpenShift Serverless Logic Operator (OSL) バージョン 1.34.0 から 1.35.0 に移行するには、Red Hat OpenShift Serverless Web コンソールを使用して OSL をアップグレードする必要があります。このアップグレードにより、新しい機能との互換性が確保され、ワークフローが適切に機能します。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Serverless Logic Operator がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • Operator のアップグレード用の OpenShift 管理コンソール にアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. Web コンソールで、OperatorsOperatorHubInstalled Operator ページに移動します。
  2. Installed Namespace から openshift-serverless-logic namespace を選択します。
  3. インストールされている Operator のリストで、OpenShift Serverless Logic Operator を見つけてクリックします。
  4. Operator の詳細ページで、Subscription タブをクリックします。Edit Subscription をクリックします。
  5. Upgrade status で、Upgrade available リンクをクリックします。
  6. Preview install planApprove をクリックし、更新を開始します。
  7. アップグレードプロセスを監視するには、次のコマンドを実行します。

    $ oc get subscription logic-operator-rhel8 -n openshift-serverless-logic -o jsonpath='{.status.installedCSV}'
    Copy to Clipboard Toggle word wrap

    予想される出力

    $ logic-operator-rhel8.v1.35.0
    Copy to Clipboard Toggle word wrap

検証

  1. 新しい Operator バージョンがインストールされていることを確認するには、次のコマンドを実行します。

    $ oc get clusterserviceversion logic-operator-rhel8.v1.35.0 -n openshift-serverless-logic
    Copy to Clipboard Toggle word wrap

    予想される出力

    NAME                           DISPLAY                               VERSION   REPLACES                       PHASE
    logic-operator-rhel8.v1.35.0   OpenShift Serverless Logic Operator   1.35.0    logic-operator-rhel8.v1.34.0   Succeeded
    Copy to Clipboard Toggle word wrap

7.1.3. アップグレードの最終処理

OpenShift Serverless Logic Operator をバージョン 1.35.0 にアップグレードした後、ワークフローを復元またはスケーリングし、古いサービスをクリーンアップして、アップグレードプロセスを完了する必要があります。これにより、システムが新しいバージョンで正常に実行され、すべての依存コンポーネントが正しく設定されるようになります。

ワークフローとサービスのプロファイルに基づいて、以下の適切な手順に従ってください。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Serverless Logic Operator がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
  • Operator のアップグレード用の OpenShift 管理コンソール にアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
7.1.3.1. Data Index のアップグレードの最終処理

Operator のアップグレード後、Data Index 1.35.0 の新しい ReplicaSet が自動的に作成されます。古いものは手動で削除する必要があります。

手順

  1. 次のコマンドを実行してすべての ReplicaSet をリスト表示し、新しい ReplicaSet が存在することを確認します。

    $ oc get replicasets -n <target_namespace> -o custom-columns=Name:metadata.name,Image:spec.template.spec.containers[*].image
    Copy to Clipboard Toggle word wrap
  2. 古い Data Index ReplicaSet (バージョン 1.34.0) を特定して削除します。

    $ oc delete replicaset <old_replicaset_name> -n <target_namespace>
    Copy to Clipboard Toggle word wrap
7.1.3.2. Job Service のアップグレードの最終処理

バージョン 1.35.0 コンポーネントのデプロイメントをトリガーするには、古いバージョンの Jobs Service コンポーネントを手動でクリーンアップする必要があります。

手順

  1. 次のコマンドを実行して、古い Jobs Service のデプロイメントを削除します。

    $ oc delete deployment <jobs-service-deployment-name> -n <target_namespace>
    Copy to Clipboard Toggle word wrap

    これにより、古い Pod と ReplicaSet の自動クリーンアップがトリガーされ、バージョン 1.35.0 を使用して新しいデプロイメントが開始されます。

7.1.3.3. dev プロファイルを使用してワークフローを再デプロイする

アップグレード後、dev プロファイルと関連する Kubernetes リソースを使用するワークフローを再デプロイする必要があります。

手順

  1. SonataFlow CRD、ConfigMap、その他の関連するカスタム設定など、必要なすべてのリソースが復元されていることを確認します。
  2. 次のコマンドを実行してワークフローを再デプロイします。

    $ oc apply -f <my-workflow.yaml> -n <target_namespace>
    Copy to Clipboard Toggle word wrap
7.1.3.4. preview プロファイルを使用したワークフローの復元

preview プロファイルを含むワークフローでは、再デプロイする前に追加の設定手順が必要です。

手順

  1. ワークフローが永続性を使用する場合は、ワークフローに関連付けられた ConfigMap に次のプロパティーを追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      labels:
        app: my-workflow
      name: my-workflow-props
    data:
      application.properties: |
        kie.flyway.enabled=true
    Copy to Clipboard Toggle word wrap
  2. SonataFlow CRD、ConfigMap、その他の関連するカスタム設定など、必要なすべてのリソースが再作成されていることを確認します。
  3. 次のコマンドを実行してワークフローを再デプロイします。

    $ oc apply -f <my-workflow.yaml> -n <target_namespace>
    Copy to Clipboard Toggle word wrap
7.1.3.5. gitops プロファイルを使用したワークフローのスケールアップ

以前にスケールダウンされた gitops プロファイルを持つワークフローは、操作を継続するためにスケールアップし直す必要があります。

手順

  1. 次の例に示すように、アップグレードする前に、my-workflow.yaml CRD を変更し、各ワークフローを one にスケールアップします。

    spec:
      podTemplate:
        replicas: 1
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、更新された CRD を適用します。

    $ oc apply -f <my-workflow.yaml> -n <target_namespace>
    Copy to Clipboard Toggle word wrap
  3. (オプション) 次のコマンドを実行して、ワークフローを 1 に戻します。

    $ oc patch sonataflow <my-workflow> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 1}}}'
    Copy to Clipboard Toggle word wrap
7.1.3.6. アップグレードの検証

ワークフローとサービスを復元した後、アップグレードが成功したこと、およびすべてのコンポーネントが期待どおりに機能していることを確認することが重要です。

手順

  1. 次のコマンドを入力して、すべてのワークフローとサービスが実行されているかどうかを確認します。

    $ oc get pods -n <target_namespace>
    Copy to Clipboard Toggle word wrap

    ワークフロー、Data Index、Jobs Service に関連するすべての Pod が Running または Completed 状態であることを確認します。

  2. 次のコマンドを入力して、OpenShift Serverless Logic Operator が正しく実行されていることを確認します。

    $ oc get clusterserviceversion logic-operator-rhel8.v1.35.0 -n openshift-serverless-logic
    Copy to Clipboard Toggle word wrap

    予想される出力

    NAME                           DISPLAY                               VERSION   REPLACES                       PHASE
    logic-operator-rhel8.v1.35.0   OpenShift Serverless Logic Operator   1.35.0    logic-operator-rhel8.v1.34.0   Succeeded
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを入力して、Operator ログにエラーがないか確認します。

    $ oc logs -l control-plane=sonataflow-operator -n openshift-serverless-logic
    Copy to Clipboard Toggle word wrap

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat