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)がインストールされている。
手順
ワークフロー設定 YAML ファイルを作成します。
workflow-dev.yamlファイルの例apiVersion: sonataflow.org/v1alpha08 kind: SonataFlow metadata: name: greeting1 annotations: sonataflow.org/description: Greeting example on k8s! sonataflow.org/version: 0.0.1 sonataflow.org/profile: dev2 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. 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)がインストールされている。
手順
次のコマンドを実行して、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>
検証
次のコマンドを実行して、
SonataFlowPlatformCR が正しく修正されていることを確認します。$ 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-configconfig map を編集します。$ oc edit cm/logic-operator-rhel8-builder-config -n openshift-serverless-logicdockerfile エントリーを変更します。
エディターで、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. 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)がインストールされている。
手順
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 #...- 1
flow定義は、ビルドプロセス中に使用されるワークフロー定義と一致する必要があります。GitOps プロファイルを使用してワークフローをデプロイすると、Operator はこの定義をコンテナーイメージに埋め込まれたワークフローファイルと比較します。定義とファイルが一致しない場合、デプロイメントは失敗します。
CR を適用してワークフローをデプロイします。
$ oc apply -f <filename>
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)がインストールされている。
手順
以下のコマンドを実行して
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-valueOperator が設定をデフォルトの設定に置き換えないように、プロパティーが正しくフォーマットされていることを確認してください。
- 必要な変更を行った後、ファイルを保存してエディターを終了します。
1.2.5. ワークフローのテスト リンクのコピーリンクがクリップボードにコピーされました!
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.6. ワークフローのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
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.7. ワークフローの削除 リンクのコピーリンクがクリップボードにコピーされました!
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 に置き換えます。