1.2. ワークフローのデプロイ


Serverless Logic ワークフローは、開発モードとプレビューモードの 2 つのモードでクラスターにデプロイできます。

1.2.1. 開発モードでのワークフローのデプロイ

ローカルワークフローを OpenShift Container Platform に開発モードでデプロイできます。このデプロイメントを使用すると、クラスター上で直接ワークフローを実験および変更することができ、変更をほぼ即座に確認できます。開発モードは開発とテストの目的で設計されています。初期の開発段階や新しい変更のテストに最適です。

前提条件

  • 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

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

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

    $ oc get workflow -n <your_namespace> -w

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

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

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

検証

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

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

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

      $ oc logs <workflow_pod_name> -n <your_namespace>

次のステップ

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

    $ oc delete sonataflow <workflow_name> -n <your_namespace>

1.2.2. プレビューモードでのワークフローのデプロイ

プレビューモードで、ローカルワークフローを OpenShift Container Platform にデプロイできます。これにより、クラスター上で直接ワークフローを試したり変更したりすることができ、変更をほぼ即座に確認できます。プレビューモードは、実稼働環境にデプロイする前の最終テストと検証に使用されます。また、実稼働環境と同様の環境でワークフローがスムーズに実行されるようにします。

前提条件

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

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

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

1.2.2.1. プレビューモードでのワークフローの設定

1.2.2.1.1. ワークフローベースビルダーイメージの設定

シナリオで、セキュリティーや強化制約など、イメージの使用に関する厳格なポリシーが必要な場合は、OpenShift Serverless Logic Operator が最終的なワークフローコンテナーイメージを構築するために使用するデフォルトのイメージを置き換えます。

デフォルトでは、OpenShift Serverless Logic Operator は、公式の Red Hat レジストリーで配布されたイメージを使用してワークフローを構築します。シナリオで、セキュリティーや強化の制約など、イメージの使用に厳格なポリシーが必要な場合は、デフォルトのイメージを置き換えることができます。

このイメージを変更するには、ワークフローをデプロイした namespace 内の SonataFlowPlatform カスタムリソース (CR) を編集します。

前提条件

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

手順

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

    $ oc get sonataflowplatform -n <your_namespace> 1
    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>

検証

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

    $ oc describe sonataflowplatform <name> -n <your_namespace> 1
    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

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"

注記

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"

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

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
    1
    <name>SonataFlowBuild インスタンスの名前に、<namespace> を namespace に置き換えます。
  2. 次のコマンドを実行して、SonataFlowBuild インスタンスにビルド引数を追加します。

    $ oc edit sonataflowbuild <name> -n <namespace>
  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>
    1
    既存の SonataFlowBuild インスタンスの名前。
  4. ファイルを保存して終了します。

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

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

    $ oc edit sonataflowplatform <name> -n <namespace>
  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>
    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>

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

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

    $ oc edit sonataflowbuild <name> -n <namespace>

    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>

  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>

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
  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

  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
  2. 次のコマンドを実行して、SonataFlow ワークフロー定義を OpenShift Container Platform namespace に適用します。

    $ oc apply -f <workflow-name>.yaml -n <your_namespace>

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

    $ oc apply -f greetings-workflow.yaml -n workflows

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

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

    $ oc logs buildconfig/<workflow-name> -n <your_namespace>

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

    $ oc logs buildconfig/greeting -n workflows

検証

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

    $ oc get pods -n <your_namespace>

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

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

    $ oc logs pod/<pod-name> -n workflows

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
  2. 次のコマンドを実行して、ワークフローサービスのルートを作成します。

    $ oc expose svc/<workflow-service-name> -n workflows

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

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

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

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

    出力例

    {
      "id": "b5fbfaa3-b125-4e6c-9311-fe5a3577efdd",
      "workflowdata": {
        "name": "John",
        "language": "English",
        "greeting": "Hello from JSON Workflow, "
      }
    }

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

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>
  2. 次のコマンドを実行して、SonataFlowBuild インスタンスを編集します。

    $ oc edit sonataflowbuild/<name> -n <namespace>

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

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

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowBuild
    metadata:
      name: <name>
      annotations:
        sonataflow.org/restartBuild: true

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

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

    $ oc logs buildconfig/<name> -n <namespace>

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

1.2.3. ワークフローの編集

OpenShift Serverless Logic Operator がワークフローサービスをデプロイすると、ランタイムプロパティーを保存するための 2 つの config map が作成されます。

  • ユーザープロパティー: SonataFlow オブジェクトをもとに名前が付けられ、接尾辞が -props である ConfigMap で定義されます。たとえば、ワークフロー名が greeting の場合、ConfigMap 名は greeting-props になります。
  • 管理プロパティー: SonataFlow オブジェクトをもとに名前が付けられ、接尾辞が -managed-props である ConfigMap で定義されます。たとえば、ワークフロー名が greeting の場合、ConfigMap 名は greeting-managed-props になります。
注記

管理プロパティーは常にキー名が同じユーザープロパティーをすべてオーバーライドし、ユーザーが編集することはできません。すべての変更は、次の調整サイクルで Operator によって上書きされます。

前提条件

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

手順

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

    $ oc edit cm <workflow_name>-props -n <namespace>

    <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

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

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

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

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>
  2. 新しく公開されたサービスの URL を取得するには、次のコマンドを実行します。

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

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

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

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 .
  2. ワークフローのデプロイメントからログを取得して分析するには、次のコマンドを実行します。

    $ oc logs deployment/<workflow_name> -f

1.2.6. ワークフローの削除

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>

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

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.