1.2. ワークフローのデプロイ
Serverless Logic ワークフローは、開発モードとプレビューモードの 2 つのモードでクラスターにデプロイできます。
1.2.1. 開発モードでのワークフローのデプロイ
ローカルワークフローを OpenShift Container Platform に開発モードでデプロイできます。このデプロイメントを使用すると、クラスター上で直接ワークフローを実験および変更することができ、変更をほぼ即座に確認できます。開発モードは開発とテストの目的で設計されています。初期の開発段階や新しい変更のテストに最適です。
前提条件
- OpenShift Serverless Logic Operator がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)
がインストールされている。
手順
ワークフロー設定 YAML ファイルを作成します。
workflow-dev.yaml
ファイルの例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
アプリケーションをデプロイするには、次のコマンドを入力して YAML ファイルを適用します。
$ oc apply -f <filename> -n <your_namespace>
次のコマンドを入力して、デプロイメントを確認し、デプロイされたワークフローのステータスを確認します。
$ oc get workflow -n <your_namespace> -w
ワークフローがリストされており、ステータスが
Running
またはCompleted
であることを確認します。次のコマンドを入力して、クラスター内でワークフローを直接編集します。
$ oc edit sonataflow <workflow_name> -n <your_namespace>
- 編集後、変更を保存します。OpenShift Serverless Logic Operator は変更を検出し、それに応じてワークフローを更新します。
検証
変更が正しく適用されていることを確認するには、次のコマンドを入力してワークフローのステータスとログを確認します。
次のコマンドを実行して、ワークフローのステータスを表示します。
$ oc get sonataflows -n <your_namespace>
次のコマンドを実行してワークフローログを表示します。
$ oc logs <workflow_pod_name> -n <your_namespace>
次のステップ
テストが完了したら、次のコマンドを実行してリソースを削除し、必要のないリソースの使用を回避します。
$ 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)
がインストールされている。
手順
次のコマンドを実行して、namespace 内の
SonataFlowPlatform
リソースをリスト表示します。$ oc get sonataflowplatform -n <your_namespace> 1
- 1
<your_namespace>
を namespace の名前に置き換えます。
次のコマンドを実行して、
SonataFlowPlatform
リソースに新しいビルダーイメージを適用します。$ oc patch sonataflowplatform <name> --patch 'spec:\n build:\n config:\n baseImage: <your_new_image_full_name_with_tag>' -n <your_namespace>
検証
次のコマンドを実行して、
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)
がインストールされている。
手順
次のコマンドを実行して、既存の
SonataFlowBuild
インスタンスを確認します。$ oc get sonataflowbuild <name> -n <namespace> 1
- 1
<name>
はSonataFlowBuild
インスタンスの名前に、<namespace>
を namespace に置き換えます。
次のコマンドを実行して、
SonataFlowBuild
インスタンスにビルド引数を追加します。$ oc edit sonataflowbuild <name> -n <namespace>
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
インスタンスの名前。
ファイルを保存して終了します。
更新された設定で新しいビルドが開始されます。
次のコマンドを実行して、
SonataFlowPlatform
リソースにデフォルトのビルド引数を設定します。$ oc edit sonataflowplatform <name> -n <namespace>
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
リソースの名前。
- ファイルを保存して終了します。
1.2.2.1.5. 内部ビルダーでの環境変数の設定
SonataFlowBuild
内部ビルダー Pod に環境変数を設定できます。これらの変数はビルドコンテキストに対してのみ有効であり、最終的にビルドされたワークフローイメージには設定されません。
前提条件
- クラスターに OpenShift Serverless Logic Operator がインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)
がインストールされている。
手順
次のコマンドを実行して、既存の
SonataFlowBuild
インスタンスを確認します。$ oc get sonataflowbuild <name> -n <namespace>
<name>
はSonataFlowBuild
インスタンスの名前に、<namespace>
を namespace に置き換えます。次のコマンドを実行して、
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>
ファイルを保存して終了します。
更新された設定で新しいインスタンスが起動します。
あるいは、
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)
がインストールされている。
手順
次のコマンドを実行して、
logic-Operator-rhel8-builder-config
config map を編集します。$ oc edit cm/logic-operator-rhel8-builder-config -n openshift-serverless-logic
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
- 変更を保存します。
1.2.2.2. ワークフローの構築とデプロイ
OpenShift Container Platform で SonataFlow
カスタムリソース (CR) を作成し、OpenShift Serverless Logic Operator がワークフローをビルドしてデプロイすることができます。
前提条件
- クラスターに OpenShift Serverless Logic Operator がインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)
がインストールされている。
手順
次のようなワークフロー YAML ファイルを作成します。
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
次のコマンドを実行して、
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
次のコマンドを実行して、すべてのビルド設定をリスト表示します。
$ oc get buildconfigs -n workflows
次のコマンドを実行して、ビルドプロセスのログを取得します。
$ oc logs buildconfig/<workflow-name> -n <your_namespace>
greetings-workflow.yaml
ファイルのコマンドの例:$ oc logs buildconfig/greeting -n workflows
検証
デプロイメントを確認するには、次のコマンドを実行してすべての Pod をリスト表示します。
$ oc get pods -n <your_namespace>
ワークフローに対応する Pod が実行されていることを確認します。
次のコマンドを実行して、実行中の 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)
がインストールされている。
手順
次のようなワークフロー
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
次のコマンドを実行して、ワークフローサービスのルートを作成します。
$ oc expose svc/<workflow-service-name> -n workflows
このコマンドは、ワークフローサービスにアクセスするためのパブリック URL を作成します。
次のコマンドを実行して、パブリック URL の環境変数を設定します。
$ WORKFLOW_SVC=$(oc get route/<workflow-service-name> -n <namespace> --template='{{.spec.host}}')
次のコマンドを実行して、ワークフローに 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)
がインストールされている。
手順
次のコマンドを実行して、
SonataFlowBuild
インスタンスが存在するかどうかを確認します。$ oc get sonataflowbuild <name> -n <namespace>
次のコマンドを実行して、
SonataFlowBuild
インスタンスを編集します。$ oc edit sonataflowbuild/<name> -n <namespace>
<name>
はSonataFlowBuild
インスタンスの名前に、<namespace>
はワークフローがデプロイされている namespace に置き換えます。ビルドを再実行するには、
sonataflow.org/restartBuild: true
アノテーションを追加します。apiVersion: sonataflow.org/v1alpha08 kind: SonataFlowBuild metadata: name: <name> annotations: sonataflow.org/restartBuild: true
このアクションにより、OpenShift Serverless Logic Operator がトリガーされ、ワークフローの新しいビルドが開始されます。
ビルドプロセスを監視するには、次のコマンドを実行してビルドログを確認します。
$ 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)
がインストールされている。
手順
以下のコマンドを実行して
ConfigMap
を開き、編集します。$ oc edit cm <workflow_name>-props -n <namespace>
<workflow_name>
はワークフローの名前に、<namespace>
はワークフローがデプロイされている namespace に置き換えます。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 が設定をデフォルトの設定に置き換えないように、プロパティーが正しくフォーマットされていることを確認してください。
- 必要な変更を行った後、ファイルを保存してエディターを終了します。
1.2.4. ワークフローのテスト
OpenShift Serverless Logic ワークフローが正しく実行されていることを確認するには、関連する Pod からテスト HTTP 呼び出しを実行できます。
前提条件
- OpenShift Serverless Logic Operator がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)
がインストールされている。
手順
次のコマンドを実行して、namespace 内の指定されたサービスへのルートを作成します。
$ oc expose svc <service_name> -n <namespace>
新しく公開されたサービスの URL を取得するには、次のコマンドを実行します。
$ WORKFLOW_SVC=$(oc get route/<service_name> --template='{{.spec.host}}')
次のコマンドを実行して、テスト HTTP 呼び出しを実行し、
POST
リクエストを送信します。$ curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '<request_body>' http://$WORKFLOW_SVC/<endpoint>
- 応答を検証して、ワークフローが期待どおりに機能していることを確認します。
1.2.5. ワークフローのトラブルシューティング
OpenShift Serverless Logic Operator は、ヘルスチェックプローブを備えた Pod をデプロイし、ワークフローが正常な状態で実行されるようにします。変更したことが原因でこれらのヘルスチェックに失敗すると、Pod は応答を停止します。
前提条件
- OpenShift Serverless Logic Operator がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションやその他のワークロードを作成するための適切なロールと権限を持つ OpenShift Serverless Logic プロジェクトにアクセスできる。
-
OpenShift CLI
(oc)
がインストールされている。
手順
次のコマンドを実行してワークフローのステータスを確認します。
$ oc get workflow <name> -o jsonpath={.status.conditions} | jq .
ワークフローのデプロイメントからログを取得して分析するには、次のコマンドを実行します。
$ oc 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)
がインストールされている。
手順
-
削除するワークフローを定義する正しいファイルがあることを確認します。たとえば、
workflow.yaml
などです。 oc delete
コマンドを実行して、指定した namespace からワークフローを削除します。$ oc delete -f <your_file> -n <your_namespace>
<your_file>
は、ワークフローファイルの名前に、<your_namespace>
を namespace に置き換えます。