Serverless Logic
OpenShift Serverless Logic 简介
摘要
第 1 章 开始使用 复制链接链接已复制到粘贴板!
1.1. 使用 Knative Workflow 插件创建并运行工作流 复制链接链接已复制到粘贴板!
您可以在本地创建并运行 OpenShift Serverless Logic 工作流。
1.1.1. 创建工作流 复制链接链接已复制到粘贴板!
您可以使用带有 kn 工作流 的 create 命令在当前目录中设置新的 OpenShift Serverless Logic 项目。
先决条件
-
已安装 OpenShift Serverless Logic
kn-workflowCLI 插件。
流程
运行以下命令,创建一个新的 OpenShift Serverless Logic 工作流项目:
kn workflow create
$ kn workflow createCopy to Clipboard Copied! Toggle word wrap Toggle overflow 默认情况下,生成的项目名称是
new-project。您可以使用[-n|--name]标志来更改项目名称,如下所示:示例命令
kn workflow create --name my-project
$ kn workflow create --name my-projectCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.1.2. 在本地运行工作流 复制链接链接已复制到粘贴板!
您可以使用带有 kn 工作流 的 run 命令,在当前目录中构建并运行 OpenShift Serverless Logic 工作流项目。
先决条件
- 您已在本地机器上安装了 Podman。
-
已安装 OpenShift Serverless Logic
kn-workflowCLI 插件。 - 您已创建了 OpenShift Serverless Logic 工作流项目。
流程
运行以下命令来构建并运行 OpenShift Serverless Logic 工作流项目:
kn workflow run
$ kn workflow runCopy to Clipboard Copied! Toggle word wrap Toggle overflow 当项目就绪时,Dev Development UI 会在
localhost:8080/q/dev-ui的浏览器中自动打开,您将找到可用的 Serverless Workflow Tools 标题。另外,您可以使用http://localhost:8080/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflows直接访问该工具。
您可以使用机器中运行的容器在本地执行工作流。使用 Ctrl+C 停止容器。
1.2. 部署选项和部署工作流 复制链接链接已复制到粘贴板!
您可以使用三个部署配置集之一在集群中部署 Serverless Logic 工作流:
- Dev
- 预览
- GitOps
每个配置集定义 Operator 如何构建和管理工作流部署,包括镜像生命周期、实时更新和协调行为。
1.2.1. 使用 Dev 配置集部署工作流 复制链接链接已复制到粘贴板!
您可以使用 Dev 配置集在 OpenShift Container Platform 上部署本地工作流。您可以使用此部署在集群中直接试验和修改工作流,查看几乎立即的更改。Dev 配置集专为开发和测试目的而设计。由于它在不重启容器的情况下自动重新载入工作流,因此非常适合初始开发阶段以及测试实时环境中的工作流更改。
先决条件
- 已在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
创建工作流配置 YAML 文件。
workflow-dev.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要部署应用程序,请输入以下命令应用 YAML 文件:
oc apply -f <filename> -n <your_namespace>
$ oc apply -f <filename> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令验证部署并检查部署工作流的状态:
oc get workflow -n <your_namespace> -w
$ oc get workflow -n <your_namespace> -wCopy to Clipboard Copied! Toggle word wrap Toggle overflow 确定列出了您的工作流,其状态为
Running或Completed。输入以下命令直接在集群中编辑工作流:
oc edit sonataflow <workflow_name> -n <your_namespace>
$ oc edit sonataflow <workflow_name> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 编辑后,保存更改。OpenShift Serverless Logic Operator 会检测更改并相应地更新工作流。
验证
要确保正确应用更改,请输入以下命令验证工作流的状态和日志:
运行以下命令,查看工作流的状态:
oc get sonataflows -n <your_namespace>
$ oc get sonataflows -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来查看工作流日志:
oc logs <workflow_pod_name> -n <your_namespace>
$ oc logs <workflow_pod_name> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
后续步骤
完成测试后,运行以下命令来删除资源以避免不必要的用法:
oc delete sonataflow <workflow_name> -n <your_namespace>
$ oc delete sonataflow <workflow_name> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.2. 使用 Preview 配置集部署工作流 复制链接链接已复制到粘贴板!
您可以使用 Preview 配置集在 OpenShift Container Platform 上部署本地工作流。这可让您在集群中直接验证和测试类似生产环境中的工作流。在将工作流移至生产环境之前,预览配置集是最终测试和验证的理想选择,以及快速迭代而无需直接管理构建管道。它还确保工作流在类似于生产的设置中平稳运行。
先决条件
- 在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
要在 Preview 配置集中部署工作流,OpenShift Serverless Logic Operator 使用 OpenShift Container Platform 上的构建系统,这会自动创建用于部署工作流的镜像。
以下小节解释了如何使用带有 SonataFlow 自定义资源的 OpenShift Serverless Logic Operator 在集群中构建和部署您的工作流。
1.2.2.1. 在 Preview 配置集中配置工作流 复制链接链接已复制到粘贴板!
1.2.2.1.1. 配置工作流基础构建器镜像 复制链接链接已复制到粘贴板!
如果您的场景需要严格策略用于镜像使用,如安全或强化约束,请替换 OpenShift Serverless Logic Operator 用来构建最终工作流容器镜像的默认镜像。
默认情况下,OpenShift Serverless Logic Operator 使用官方 Red Hat Registry 中分发的镜像来构建工作流。如果您的场景需要严格的策略用于镜像,如 security 或 hardening 约束,您可以替换默认镜像。
要更改此镜像,您可以编辑部署工作流的命名空间中 SonataFlowPlatform 自定义资源(CR)。
先决条件
- 在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
运行以下命令,列出命名空间中的
SonataFlowPlatform资源:oc get sonataflowplatform -n <your_namespace>
$ oc get sonataflowplatform -n <your_namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<your_namespace> 替换为命名空间的名称。
运行以下命令,使用新构建器镜像修补
SonataFlowPlatform资源:oc patch sonataflowplatform <name> --patch 'spec:\n build:\n config:\n baseImage: <your_new_image_full_name_with_tag>' -n <your_namespace>
$ oc patch sonataflowplatform <name> --patch 'spec:\n build:\n config:\n baseImage: <your_new_image_full_name_with_tag>' -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
运行以下命令,验证
SonataFlowPlatformCR 是否已正确修补:oc describe sonataflowplatform <name> -n <your_namespace>
$ oc describe sonataflowplatform <name> -n <your_namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<name> 替换为SonataFlowPlatform资源的名称,将 <your_namespace> 替换为命名空间的名称。
确保
spec.build.config下的baseImage字段反映了新镜像。
1.2.2.1.2. 自定义基础构建器 Dockerfile 复制链接链接已复制到粘贴板!
OpenShift Serverless Logic Operator 使用 openshift-serverless-logicOpenShift Serverless Logic Operator 安装命名空间中的 logic-operator-rhel8-builder-config 配置映射自定义资源(CR)来配置和运行工作流构建过程。您可以更改此配置映射中的 Dockerfile 条目,以根据您的需要调整 Dockerfile。
修改 Dockerfile 可能会破坏构建过程。
这个示例仅供参考。实际版本可能稍有不同。不要在您的安装中使用这个示例。
logic-operator-rhel8-builder-config 配置映射 CR 示例
1.2.2.1.3. 更改资源要求 复制链接链接已复制到粘贴板!
您可以通过在工作流命名空间中创建或编辑 SonataFlowPlatform 资源来指定内部构建器 pod 的资源要求。
SonataFlowPlatform 资源示例
每个命名空间只允许一个 SonataFlowPlatform 资源。获取并编辑 OpenShift Serverless Logic Operator 为您创建的资源,而不是尝试创建另一个资源。
您可以微调特定工作流的资源要求。每个工作流实例都有一个 SonataFlowBuild 实例,其名称与工作流相同。您可以编辑 SonataFlowBuild 自定义资源(CR)并指定参数,如下所示:
SonataFlowBuild CR 示例
这些参数仅适用于新的构建实例。
1.2.2.1.4. 将参数传递给内部构建器 复制链接链接已复制到粘贴板!
您可以通过将构建参数传递给 SonataFlowBuild 实例,或者在 SonataFlowPlatform 资源中设置默认构建参数来自定义构建流程。
先决条件
- 在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
运行以下命令,检查现有的
SonataFlowBuild实例:oc get sonataflowbuild <name> -n <namespace>
$ oc get sonataflowbuild <name> -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 将
<name> 替换为SonataFlowBuild实例的名称,将 <namespace> 替换为您的命名空间。
运行以下命令,在
SonataFlowBuild实例中添加构建参数:oc edit sonataflowbuild <name> -n <namespace>
$ oc edit sonataflowbuild <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
SonataFlowBuild实例的.spec.buildArgs字段中添加所需的构建参数:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 现有
SonataFlowBuild实例的名称。
保存文件并退出。
将启动一个带有更新的配置的新构建。
运行以下命令,在
SonataFlowPlatform资源中设置默认构建参数:oc edit sonataflowplatform <name> -n <namespace>
$ oc edit sonataflowplatform <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
SonataFlowPlatform资源的.spec.buildArgs字段中添加所需的构建参数:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 现有
SonataFlowPlatform资源的名称。
- 保存文件并退出。
1.2.2.1.5. 在内部构建器中设置环境变量 复制链接链接已复制到粘贴板!
您可以将环境变量设置为 SonataFlowBuild 内部构建器 pod。这些变量仅对构建上下文有效,且不会在最终构建的工作流镜像上设置。
先决条件
- 在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
运行以下命令,检查现有的
SonataFlowBuild实例:oc get sonataflowbuild <name> -n <namespace>
$ oc get sonataflowbuild <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<name> 替换为SonataFlowBuild实例的名称,将 <namespace> 替换为您的命名空间。运行以下命令来编辑
SonataFlowBuild实例:oc edit sonataflowbuild <name> -n <namespace>
$ oc edit sonataflowbuild <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow SonataFlowBuild实例示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 保存文件并退出。
一个新的带有更新后的配置会启动。
或者,您可以在
SonataFlowPlatform中设置 enviroments,以便每个新构建实例都会将其用作模板。SonataFlowPlatform实例示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.2.1.6. 更改基本构建器镜像 复制链接链接已复制到粘贴板!
您可以通过编辑 logic-operator-rhel8-builder-config 配置映射来修改 OpenShift Serverless Logic Operator 使用的默认构建器镜像。
先决条件
- 在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
运行以下命令来编辑
logic-operator-rhel8-builder-config配置映射:oc edit cm/logic-operator-rhel8-builder-config -n openshift-serverless-logic
$ oc edit cm/logic-operator-rhel8-builder-config -n openshift-serverless-logicCopy to Clipboard Copied! Toggle word wrap Toggle overflow 修改 dockerfile 条目。
在编辑器中,找到 Dockerfile 条目并将第一行更改为所需的镜像。
Example
data: Dockerfile: | FROM registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.33.0 # Change the image to the desired onedata: Dockerfile: | FROM registry.redhat.io/openshift-serverless-1/logic-swf-builder-rhel8:1.33.0 # Change the image to the desired oneCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 保存更改。
1.2.2.2. 构建和部署您的工作流 复制链接链接已复制到粘贴板!
您可以在 OpenShift Container Platform 和 OpenShift Serverless Logic Operator 上创建 SonataFlow 自定义资源(CR)并部署工作流。
先决条件
- 在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
创建类似以下示例的工作流 YAML 文件:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,将
SonataFlow工作流定义应用到 OpenShift Container Platform 命名空间:oc apply -f <workflow-name>.yaml -n <your_namespace>
$ oc apply -f <workflow-name>.yaml -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow greetings-workflow.yaml文件的命令示例:oc apply -f greetings-workflow.yaml -n workflows
$ oc apply -f greetings-workflow.yaml -n workflowsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令列出所有构建配置:
oc get buildconfigs -n workflows
$ oc get buildconfigs -n workflowsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,获取构建过程的日志:
oc logs buildconfig/<workflow-name> -n <your_namespace>
$ oc logs buildconfig/<workflow-name> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow greetings-workflow.yaml文件的命令示例:oc logs buildconfig/greeting -n workflows
$ oc logs buildconfig/greeting -n workflowsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要验证部署,请运行以下命令列出所有 pod:
oc get pods -n <your_namespace>
$ oc get pods -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确保与工作流对应的 pod 正在运行。
运行以下命令,检查正在运行的 pod 及其日志:
oc logs pod/<pod-name> -n workflows
$ oc logs pod/<pod-name> -n workflowsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.2.3. 验证工作流部署 复制链接链接已复制到粘贴板!
您可以通过从工作流 pod 执行测试 HTTP 调用来验证 OpenShift Serverless Logic 工作流是否正在运行。
先决条件
- 在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
创建类似以下示例的工作流
YAML文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,为工作流服务创建路由:
oc expose svc/<workflow-service-name> -n workflows
$ oc expose svc/<workflow-service-name> -n workflowsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 此命令创建用于访问工作流服务的公共 URL。
运行以下命令,为公共 URL 设置环境变量:
WORKFLOW_SVC=$(oc get route/<workflow-service-name> -n <namespace> --template='{{.spec.host}}')$ WORKFLOW_SVC=$(oc get route/<workflow-service-name> -n <namespace> --template='{{.spec.host}}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,向工作流发出 HTTP 调用,以将 POST 请求发送到服务:
curl -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' -d '{<"your": "json_payload">}' http://$WORKFLOW_SVC/<endpoint>$ curl -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' -d '{<"your": "json_payload">}' http://$WORKFLOW_SVC/<endpoint>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此输出显示工作流正在运行时的预期响应示例。
1.2.2.4. 重启构建 复制链接链接已复制到粘贴板!
要重启构建,您可以在 SonataFlowBuild 实例中添加或编辑 sonataflow.org/restartBuild: true 注解。如果您的工作流或初始构建版本存在问题,则需要重启构建。
先决条件
- 在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
运行以下命令,检查
SonataFlowBuild实例是否存在:oc get sonataflowbuild <name> -n <namespace>
$ oc get sonataflowbuild <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来编辑
SonataFlowBuild实例:oc edit sonataflowbuild/<name> -n <namespace>
$ oc edit sonataflowbuild/<name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<name> 替换为SonataFlowBuild实例的名称,将<namespace> 替换为部署了工作流的命名空间。添加
sonataflow.org/restartBuild: true注解来重新启动构建。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此操作会触发 OpenShift Serverless Logic Operator 来启动工作流的新构建。
要监控构建过程,请运行以下命令来检查构建日志:
oc logs buildconfig/<name> -n <namespace>
$ oc logs buildconfig/<name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<name> 替换为SonataFlowBuild实例的名称,将<namespace> 替换为部署了工作流的命名空间。
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 Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
在 SonataFlow CR 中指定容器镜像:
带有设置 GitOps 配置集的 SonataFlow CR 示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
流定义必须与构建过程中使用的工作流定义匹配。当使用 GitOps 配置集部署工作流时,Operator 会将此定义与嵌入在容器镜像中的工作流文件进行比较。如果定义和文件不匹配,部署会失败。
应用 CR 来部署工作流:
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.4. 编辑工作流 复制链接链接已复制到粘贴板!
当 OpenShift Serverless Logic Operator 部署工作流服务时,它会创建两个配置映射来存储运行时属性:
-
用户属性:在
ConfigMap中定义,以带有后缀 的SonataFlow对象命名。例如,如果您的工作流名称是greeting,则ConfigMap名称为greeting-props。 -
受管属性:在
ConfigMap中定义,以带有 suffix-managed-props的SonataFlow对象命名。例如,如果您的工作流名称是greeting,则ConfigMap名称为greeting-managed-props。
受管属性始终覆盖具有相同密钥名称的任何 user 属性,用户无法编辑。在下一个协调周期中,Operator 都会覆盖任何更改。
先决条件
- 已在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
运行以下命令打开并编辑
ConfigMap:oc edit cm <workflow_name>-props -n <namespace>
$ oc edit cm <workflow_name>-props -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<workflow_name> 替换为工作流的名称,将<namespace> 替换为部署工作流的命名空间。在
application.properties部分中添加属性。存储在
ConfigMap中的工作流属性示例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确保正确格式化属性,以防止 Operator 将配置替换为默认配置。
- 进行必要的更改后,保存文件并退出编辑器。
1.2.5. 测试工作流 复制链接链接已复制到粘贴板!
要验证 OpenShift Serverless Logic 工作流是否在正确运行,您可以从相关 pod 执行测试 HTTP 调用。
先决条件
- 已在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
运行以下命令,为命名空间中的指定服务创建路由:
oc expose svc <service_name> -n <namespace>
$ oc expose svc <service_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,获取新公开的服务的 URL:
WORKFLOW_SVC=$(oc get route/<service_name> --template='{{.spec.host}}')$ WORKFLOW_SVC=$(oc get route/<service_name> --template='{{.spec.host}}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,执行测试 HTTP 调用并发送
POST请求:curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '<request_body>' http://$WORKFLOW_SVC/<endpoint>
$ curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '<request_body>' http://$WORKFLOW_SVC/<endpoint>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 验证响应,以确保工作流按预期工作。
1.2.6. 工作流故障排除 复制链接链接已复制到粘贴板!
OpenShift Serverless Logic Operator 使用健康检查探测部署其 pod,以确保工作流以健康状态运行。如果更改导致这些健康检查失败,pod 将停止响应。
先决条件
- 已在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
运行以下命令检查工作流状态:
oc get workflow <name> -o jsonpath={.status.conditions} | jq .$ oc get workflow <name> -o jsonpath={.status.conditions} | jq .Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要从工作流的部署中获取和分析日志,请运行以下命令:
oc logs deployment/<workflow_name> -f
$ oc logs deployment/<workflow_name> -fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.7. 删除工作流 复制链接链接已复制到粘贴板!
您可以使用 oc delete 命令删除当前目录中的 OpenShift Serverless Logic 工作流。
先决条件
- 已在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
-
已安装 OpenShift CLI
(oc)。
流程
-
验证您具有定义您要删除的工作流的正确文件。例如,
workflow.yaml。 运行
oc delete命令从指定的命名空间中删除工作流:oc delete -f <your_file> -n <your_namespace>
$ oc delete -f <your_file> -n <your_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<your_file> 替换为工作流文件的名称,将 <your_namespace> 替换为您的命名空间。
第 2 章 全局配置设置 复制链接链接已复制到粘贴板!
您可以为 OpenShift Serverless Logic Operator 设置全局配置选项。
2.1. 先决条件 复制链接链接已复制到粘贴板!
- 您已在目标集群上安装了 OpenShift Serverless Logic Operator。
2.2. 自定义全局配置 复制链接链接已复制到粘贴板!
安装 OpenShift Serverless Logic Operator 后,您可以访问 openshift-serverless-logic 命名空间中的 logic-operator-rhel8-controllers-config 配置映射文件。此配置文件定义 Operator 在集群中创建新资源时 Operator 的行为方式。但是,对此配置的更改不会影响已存在的资源。
您可以修改配置映射中 controllers_cfg.yaml 键中的任何选项。
下表概述了所有可用的全局配置选项:
| 配置密钥 | 默认值 | 描述 |
|---|---|---|
|
|
| 使用内部 OpenShift Serverless Logic Operator 构建器管理器时,Kaniko 持久性卷声明(PVC)的默认大小。 |
|
|
| 等待开发人员模式工作流启动的时间(以秒为单位)。此信息用于控制器管理器来创建新的开发人员模式容器并设置健康检查探测。 |
|
|
| Operator managed Kaniko 构建器在内部使用的默认镜像来创建 warmup pod。 |
|
|
| Operator managed Kaniko 构建器在内部使用的默认镜像来创建 executor pod。 |
|
|
| PostgreSQL 要使用的作业服务镜像。如果为空,OpenShift Serverless Logic Operator 会根据当前的 OpenShift Serverless Logic Operator 版本使用默认的 Apache 社区镜像。 |
|
|
| 作业服务镜像,无需使用持久性。如果为空,OpenShift Serverless Logic Operator 会根据当前的 OpenShift Serverless Logic Operator 版本使用默认的 Apache 社区镜像。 |
|
|
| PostgreSQL 要使用的数据索引服务镜像。如果为空,OpenShift Serverless Logic Operator 会根据当前的 OpenShift Serverless Logic Operator 版本使用默认的 Apache 社区镜像。 |
|
|
| 数据索引服务镜像,无需使用持久性。如果为空,OpenShift Serverless Logic Operator 会根据当前的 OpenShift Serverless Logic Operator 版本使用默认的 Apache 社区镜像。 |
|
|
| 内部 Dockerfile 中使用的 OpenShift Serverless Logic 基础构建器镜像,用于在 preview 配置集中构建工作流应用程序。如果为空,OpenShift Serverless Logic Operator 会根据当前的 OpenShift Serverless Logic Operator 版本使用默认的 Apache 社区镜像。 |
|
|
| 用于在 devmode 配置集中部署 OpenShift Serverless Logic 工作流镜像的镜像。如果为空,OpenShift Serverless Logic Operator 会根据当前的 OpenShift Serverless Logic Operator 版本使用默认的 Apache 社区镜像。 |
|
|
| OpenShift Serverless Logic Operator 命名空间中的 builder 配置映射的默认名称。 |
|
| 下一列 | 工作流持久性所需的 Quarkus 扩展。在构建工作流配置了 PostgreSQL 持久性时,OpenShift Serverless Logic Operator 构建器使用这些扩展。 |
|
|
|
当设置为 |
|
|
|
当设置为 |
|
|
|
当设置为 |
您可以使用 oc 命令行工具更新 logic-operator-controllers-config 配置映射来编辑它。
2.2.1. 全局配置更改的影响 复制链接链接已复制到粘贴板!
当您更新全局配置时,更改会立即影响新创建的资源。例如,如果您更改 sonataFlowDevModeImageTag 属性,且已在 dev 模式中部署工作流,OpenShift Serverless Logic Operator 不会使用更新的镜像配置推出新部署。只有新部署会反映出更改。
2.2.2. 自定义基本构建器镜像 复制链接链接已复制到粘贴板!
您可以直接更改 OpenShift Serverless Logic Operator 使用的 Dockerfile 中的基本构建器镜像。
另外,您可以在当前命名空间中的 SonataFlowPlatform 配置中指定基本构建器镜像。这样可确保指定的基础镜像仅在给定命名空间中使用。
带有自定义基本构建器镜像的 SonataFlowPlatform 示例
另外,您还可以修改全局配置映射中的基本构建器镜像,如下例所示:
使用自定义基本构建器镜像的 ConfigMap 示例
在自定义基本构建器镜像时,适用以下优先级顺序:
-
当前上下文中的
SonataFlowPlatform配置。 -
ConfigMap资源中的全局配置条目。 -
OpenShift Serverless Logic Operator 命名空间中的 Dockerfile 中的
FROM子句,在logic-operator-rhel8-builder-config配置映射中定义的。
SonataFlowPlatform 配置中的条目始终覆盖任何其他值。
第 3 章 管理服务 复制链接链接已复制到粘贴板!
3.1. 配置 OpenAPI 服务 复制链接链接已复制到粘贴板!
OpenAPI 规格 (OAS)为 HTTP API 定义了一个标准的编程语言无关接口。您可以在不访问源代码、额外文档或网络流量检查的情况下了解服务的功能。当使用 OpenAPI 定义服务时,您可以使用最小实施逻辑理解并与之交互。正如接口描述简化了低级别编程一样,OpenAPI 规格 消除了调用服务中的猜测工作。
3.1.1. OpenAPI 功能定义 复制链接链接已复制到粘贴板!
OpenShift Serverless Logic 允许工作流使用函数中的 OpenAPI 规格引用与远程服务交互。
OpenAPI 功能定义示例
operation 属性是由以下参数组成的 字符串 :
-
URI:引擎使用它来找到规格文件。 - 操作标识符 :您可以在 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 Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
- 您可以访问 OpenAPI 规格文件。
流程
定义 OpenAPI 功能:
- 识别并访问您要调用的服务的 OpenAPI 规格文件。
将 OpenAPI 规格文件复制到工作流服务目录中,如 <
project_application_dir>/specs。以下示例显示了 multiplication REST 服务的 OpenAPI 规格:
multiplication REST 服务 OpenAPI 规格示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要在工作流中定义功能,请使用 OpenAPI 规格中的
operationId来引用功能定义中的所需操作。温度转换应用中的函数定义示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
确保您的功能定义引用存储在 <
project_application_dir>/specs目录中的 OpenAPI 文件的正确路径。
访问工作流状态中定义的功能:
- 定义工作流操作来调用您添加的功能定义。确保每个操作引用之前定义的函数。
使用
functionRef属性根据其名称引用特定功能。使用 OpenAPI 规格中定义的参数来映射functionRef中的参数。以下示例演示了在请求路径而不是请求正文中映射参数,您可以参考以下 PetStore API 示例:
工作流中的映射功能参数示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
检查 OpenAPI 规格的
Operation Object部分,以了解如何在请求中结构参数。 -
使用
jq表达式从有效负载中提取数据并将其映射到所需参数。确保引擎根据 OpenAPI 规格映射参数名称。 对于在请求路径而不是正文中需要参数的操作,请参阅 OpenAPI 规格中的参数定义。
有关请求路径而不是请求正文中映射参数的更多信息,您可以参阅以下 PetStore API 示例:
映射路径参数示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下是调用函数的示例,在请求路径中只添加了一个名为
petId的参数:调用 PetStore 功能的示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.3. 配置 OpenAPI 服务的端点 URL 复制链接链接已复制到粘贴板!
在访问工作流状态中的函数定义后,您可以配置 OpenAPI 服务的端点 URL。
先决条件
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
- 您已创建了 OpenShift Serverless Logic 项目。
- 您可以访问 OpenAPI 规格文件。
- 您已在工作流中定义了函数定义。
- 您可以访问工作流状态中定义的功能。
流程
-
找到您要配置的 OpenAPI 规格文件。例如,
substraction.yaml。 -
通过将特殊字符(如
.)替换为下划线并将字母转换为小写,将文件名转换为有效的配置键。例如,将substraction.yaml更改为substraction_yaml。 要定义配置密钥,请使用转换的文件名作为 REST 客户端配置密钥。将此键设置为环境变量,如下例所示:
quarkus.rest-client.subtraction_yaml.url=http://myserver.com
quarkus.rest-client.subtraction_yaml.url=http://myserver.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要防止
application.properties文件中的硬编码 URL,请使用环境变量替换,如下例所示:quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在本例中:
-
配置密钥:
quarkus.rest-client.subtraction_yaml.url - 环境变量:SUBTRACTION_URL
-
回退 URL:
http://myserver.com
-
配置密钥:
-
确保在系统或部署环境中设置了
(SUBTRACTION_URL)环境变量。如果没有找到变量,应用程序将使用回退 URL(http://myserver.com)。 将配置键和 URL 替换添加到
application.properties文件中:quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}quarkus.rest-client.subtraction_yaml.url=${SUBTRACTION_URL:http://myserver.com}Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 部署或重启您的应用程序以应用新的配置设置。
3.2. 配置 OpenAPI 服务端点 复制链接链接已复制到粘贴板!
OpenShift Serverless Logic 使用 kogito.sw.operationIdStrategy 属性来生成 REST 客户端,用于调用 OpenAPI 文档中定义的服务。此属性决定了如何为 REST 客户端配置派生配置密钥。
kogito.sw.operationIdStrategy 属性支持以下值: FILE_NAME、FULL_URI、FUNCTION_NAME 和 SPEC_TITLE。
FILE_NAMEOpenShift Serverless Logic 使用 OpenAPI 文档文件名来创建配置密钥。键基于文件名,其中将特殊字符替换为下划线。
配置示例:
quarkus.rest-client.stock_portfolio_svc_yaml.url=http://localhost:8282/
quarkus.rest-client.stock_portfolio_svc_yaml.url=http://localhost:8282/1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenAPI 文件路径是 <
;project_application_dir>/specs/stock-portfolio-svc.yaml。为 REST 客户端配置 URL 生成的密钥是stock_portfolio_svc_yaml。
FULL_URIOpenShift Serverless Logic 使用 OpenAPI 文档的完整 URI 路径作为配置密钥。整个 URI 被清理以组成密钥。
Serverless 工作流示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置示例:
quarkus.rest-client.apicatalog_apis_123_document.url=http://localhost:8282/
quarkus.rest-client.apicatalog_apis_123_document.url=http://localhost:8282/1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- URI 路径为
https://my.remote.host/apicatalog/apis/123/document。为 REST 客户端配置 URL 生成的密钥是apicatalog_apis_123_document。
FUNCTION_NAMEOpenShift Serverless Logic 组合了工作流 ID 和引用 OpenAPI 文档的功能名称来生成配置密钥。
Serverless 工作流示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置示例:
quarkus.rest-client.myworkflow_myfunction.url=http://localhost:8282/
quarkus.rest-client.myworkflow_myfunction.url=http://localhost:8282/1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 工作流 ID 是
myworkflow。函数名称是myfunction。为 REST 客户端配置 URL 生成的密钥是myworkflow_myfunction。
SPEC_TITLEOpenShift Serverless Logic 使用 OpenAPI 文档中的
info.title值来创建配置键。标题被清理为组成密钥。OpenAPI 文档示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置示例:
quarkus.rest-client.stock-service_API.url=http://localhost:8282/
quarkus.rest-client.stock-service_API.url=http://localhost:8282/1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenAPI 文档标题为
stock-service API。为 REST 客户端配置 URL 生成的密钥是stock-service_API。
3.2.1. 使用 URI 别名 复制链接链接已复制到粘贴板!
作为 kogito.sw.operationIdStrategy 属性的替代选择,您可以使用 workflow-uri-definitions 自定义扩展为 URI 分配别名。此别名简化了配置过程,并可用作 REST 客户端设置和功能定义中的配置密钥。
workflow-uri-definitions 扩展允许您将 URI 映射到别名,您可以在整个工作流和配置文件中引用。这种方法提供了一种集中管理 URI 及其配置的集中方法。
先决条件
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
- 您可以访问 OpenAPI 规格文件。
流程
在您的工作流中添加
workflow-uri-definitions扩展。在此扩展中,为您的 URI 创建别名。工作流示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1
- 将扩展 ID 设置为
workflow-uri-definitions。 - 2
- 通过将
remoteCatalog别名映射到 URI 来设置别名定义,例如https://my.remote.host/apicatalog/apis/123/documentURI。 - 3
- 使用带有操作标识符的
remoteCatalog别名来设置功能操作,如operation1和operation2操作标识符。在
application.properties文件中,使用工作流中定义的别名配置 REST 客户端。属性示例
quarkus.rest-client.remoteCatalog.url=http://localhost:8282/
quarkus.rest-client.remoteCatalog.url=http://localhost:8282/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在上例中,配置键被设置为
quarkus.rest-client.remoteCatalog.url,URL 设置为http://localhost:8282/,REST 客户端通过引用remoteCatalog别名来使用它。在工作流中,在定义在 URI 上操作的功能时使用别名。
工作流示例(续):
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. 故障排除服务 复制链接链接已复制到粘贴板!
对基于 HTTP 的功能调用(如使用 OpenAPI 功能的用户)进行有效的故障排除对于维护工作流编配至关重要。
要诊断问题,您可以跟踪 HTTP 请求和响应。
3.3.1. 追踪 HTTP 请求和响应 复制链接链接已复制到粘贴板!
OpenShift Serverless Logic 使用 Apache HTTP 客户端来跟踪 HTTP 请求和响应。
先决条件
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
- 您可以访问 OpenAPI 规格文件。
- 您可以访问工作流定义和实例 ID,以更正 HTTP 请求和响应。
- 您可以访问发生 HTTP 服务调用的应用的日志配置
流程
要跟踪 HTTP 请求和响应,OpenShift Serverless Logic 通过设置以下属性来使用 Apache HTTP 客户端:
Turning HTTP tracing on
# Turning HTTP tracing on quarkus.log.category."org.apache.http".level=DEBUGCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在应用程序的
application.properties文件中添加以下配置,以打开 Apache HTTP 客户端的调试:quarkus.log.category."org.apache.http".level=DEBUG
quarkus.log.category."org.apache.http".level=DEBUGCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 重启应用程序以传播日志配置更改。
重启后,检查 HTTP 请求追踪的日志。
追踪的 HTTP 请求的日志示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在请求日志后检查 HTTP 响应追踪的日志。
追踪的 HTTP 响应的日志示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 4 章 支持服务 复制链接链接已复制到粘贴板!
4.1. 作业服务 复制链接链接已复制到粘贴板!
Job 服务在云环境中调度并执行任务。独立的服务实现这些任务,可以通过任何受支持的交互模式启动,包括 HTTP 调用或 Knative 事件交付。
在 OpenShift Serverless Logic 中,作业服务负责控制时间触发操作的执行。因此,您可在工作流中使用的所有基于时间的状态都由工作流和作业服务之间的交互处理。
例如,每次工作流执行达到配置超时的状态时,会在作业服务中创建对应的作业,并在满足超时时执行 HTTP 回调来通知工作流。
作业服务的主要目标是管理活动的作业,如需要执行的计划作业。当作业达到其最终状态时,作业服务会将其删除。要在永久存储库中保留作业信息,作业服务会生成可由外部服务记录的状态更改事件,如 Data Index Service。
如果使用 OpenShift Serverless Operator 部署工作流,则不需要手动安装和配置 Job 服务。Operator 会自动处理这些任务,并管理每个工作流需要与之连接的所有必要配置。
4.1.1. 作业服务领导选举过程 复制链接链接已复制到粘贴板!
Job 服务作为单例服务运行,这意味着只有一个活动实例可以调度和执行作业。
为了防止将服务部署到云中(多个实例可能正在运行)时发生冲突,作业服务支持领导选举过程。只有作为领导机选择的实例才会管理外部通信,以接收和调度作业。
非领导实例处于待机状态,但会继续尝试通过选举过程成为领导。当新实例启动时,它不会立即假定领导。相反,它进入领导选举过程来确定是否可以接管领导角色。
如果当前的领导响应没有响应,或者关闭了,另一个正在运行的实例将接管为领导。
这个领导选举机制使用底层持久性后端,目前仅在 PostgreSQL 实现中被支持。
4.2. 数据索引服务 复制链接链接已复制到粘贴板!
Data Index 服务是一个专用的支持服务,它存储了与工作流实例及其关联的作业相关的数据。此服务提供了一个 GraphQL 端点,允许用户查询这些数据。
Data Index 服务处理通过事件接收的数据,这些事件可能源自任何工作流或直接来自作业服务。
数据索引支持 Apache Kafka 或 Knative Eventing 来消耗来自工作流的 CloudEvents 信息。它对数据库进行索引并将其存储在数据库中,使其可通过 GraphQL 访问。这些事件提供有关工作流执行的详细信息。Data Index 服务是 OpenShift Serverless Logic 搜索、insights 和管理功能的核心。
Data Index 服务的主要功能如下:
- 灵活的数据结构
- 一个可分布式、云就绪的格式
- 通过 Apache Kafka、Knative 和 CloudEvents 与工作流进行基于消息的通信
- 强大的基于 GraphQL 的查询 API
当使用 OpenShift Serverless Operator 部署工作流时,您不需要手动安装或配置 Data Index 服务。Operator 会自动管理每个工作流要连接的所有必要配置。
4.2.1. 图形ql 查询工作流实例和作业 复制链接链接已复制到粘贴板!
要检索有关工作流实例和作业的数据,您可以使用 GraphQL 查询。
4.2.1.1. 从工作流实例检索数据 复制链接链接已复制到粘贴板!
您可以使用以下查询示例检索有关特定工作流实例的信息:
4.2.1.2. 从作业检索数据 复制链接链接已复制到粘贴板!
您可以使用以下查询示例从特定作业实例检索数据:
4.2.1.3. 使用 where 参数过滤查询结果 复制链接链接已复制到粘贴板!
您可以使用 where 参数过滤查询结果,允许基于工作流属性的多个组合。
按状态过滤的查询示例
按 ID 过滤的查询示例
默认情况下,使用 AND Operator 合并过滤器。您可以通过将过滤器与 AND 或 OR 运算符组合来修改此行为。
将过滤器与 OR Operator 组合的查询示例
将过滤器与 AND 和 OR Operator 组合的查询示例
根据属性类型,您可以使用以下 avaialable Operator:
| 属性类型 | 可用的 Operator |
|---|---|
| 字符串数组 |
|
| 字符串 |
|
| ID |
|
| 布尔值 |
|
| 数字 |
|
| Date |
|
4.2.1.4. 使用 orderBy 参数对查询结果进行排序 复制链接链接已复制到粘贴板!
您可以使用 orderBy 参数根据工作流属性对查询结果进行排序。您还可以以升序(ASC)或降序(DESC)顺序指定排序方向。按照您指定的顺序应用多个属性。
以 ASC 顺序排序的开始时间的查询示例
4.2.1.5. 使用分页参数限制结果数量 复制链接链接已复制到粘贴板!
您可以控制返回的结果数量,并使用 分页 参数指定偏移量。
从偏移 0 开始将结果限制为 10 的示例
4.3. 管理支持服务 复制链接链接已复制到粘贴板!
本节概述 OpenShift Serverless Logic 所必需的支持服务。它专门用于使用 OpenShift Serverless Logic Operator 配置和部署数据索引服务和作业服务支持服务。
在典型的 OpenShift Serverless Logic 安装中,您必须部署这两个服务来确保成功执行工作流。Data Index 服务允许高效的数据管理,而作业服务则可确保可靠的作业处理。
4.3.1. 支持服务和工作流集成 复制链接链接已复制到粘贴板!
当您在给定命名空间中部署支持服务时,您可以选择启用或禁用的部署。启用的部署会向 OpenShift Serverless Logic Operator 发出信号,以使用命名空间中的 preview 或 gitops 配置集自动截获工作流部署,并将它们配置为与服务连接。
例如,当启用 Data Index 服务时,工作流会自动配置为向它发送状态更改事件。同样,启用作业服务可确保每当工作流需要超时时创建作业。OpenShift Serverless Logic Operator 还配置作业服务,将事件发送到 Data Index 服务,从而促进服务间的无缝集成。
OpenShift Serverless Logic Operator 不仅部署支持服务,它还管理其他必要的配置,以确保工作流成功执行。所有这些配置都会自动处理。您只需要在 SonataFlowPlatform CR 中提供支持服务配置。
仅部署其中一个支持服务或使用禁用的部署是高级用例。在标准安装中,您必须启用这两个服务来确保平稳执行工作流。
4.3.2. 使用 SonataFlowPlatform CR 支持服务部署 复制链接链接已复制到粘贴板!
要部署支持服务,请在 SonataFlowPlatform 自定义资源(CR)的 spec.services 部分中配置 dataIndex 和 jobService 子字段。此配置指示 OpenShift Serverless Logic Operator 在应用 SonataFlowPlatform CR 时部署每个服务。
服务的每个配置都独立处理,允许您自定义这些设置以及 SonataFlowPlatform CR 中的其他配置。
有关部署支持服务,请参阅以下构建示例配置:
4.3.3. 支持服务范围 复制链接链接已复制到粘贴板!
SonataFlowPlatform 自定义资源(CR)启用在特定命名空间中部署支持服务。这意味着所有自动配置的支持服务和工作流通信都仅限于所部署平台的命名空间。
当不同版本的工作流需要单独的支持服务实例时,此功能特别有用。例如,您可以使用其工作流和支持服务以隔离方式部署应用程序,确保它们与其他部署保持相互独立。
4.3.4. 支持服务持久性配置 复制链接链接已复制到粘贴板!
OpenShift Serverless Logic 中支持服务的持久性配置可以是临时的,也可以是 PostgreSQL,具体取决于您的环境的需求。临时持久性是开发和测试的理想选择,而 PostgreSQL 持久性则用于生产环境。
4.3.4.1. 临时持久性配置 复制链接链接已复制到粘贴板!
临时持久性使用专用于每个服务的嵌入式 PostgreSQL 数据库。OpenShift Serverless Logic Operator 使用每个服务重启重新创建此数据库,使其仅适用于开发和测试目的。您不需要以下 SonataFlowPlatform CR 以外的任何其他配置:
4.3.4.2. PostgreSQL 持久性配置 复制链接链接已复制到粘贴板!
对于 PostgreSQL 持久性,您必须在集群中设置 PostgreSQL 服务器实例。此实例的管理保留独立于 OpenShift Serverless Logic Operator 控制。要将支持服务与 PostgreSQL 服务器连接,您必须配置适当的数据库连接参数。
您可以使用以下示例在 SonataFlowPlatform CR 中配置 PostgreSQL 持久性:
PostgreSQL 持久性配置示例
- 1
- 与 PostgreSQL 数据库服务器连接的服务名称。
- 2
- 可选:定义 PostgreSQL Service 的命名空间。默认为 SonataFlowPlatform 命名空间。
- 3
- 定义用于存储支持服务数据的 PostgreSQL 数据库的名称。
- 4
- 可选:指定存储支持服务数据的模式。默认值为
SonataFlowPlatform名称,后缀为 with-data-index-serviceor-jobs-service。例如,sonataflow-platform-example-data-index-service。 - 5
- 可选:与 PostgreSQL 服务连接的端口号。默认值为
5432。 - 6
- 定义包含数据库访问的用户名和密码的机密名称。
- 7
- 定义机密中的密钥名称,其中包含要与数据库连接的用户名。
- 8
- 定义机密中的密钥名称,其中包含要与数据库连接的密码。
您可以使用对应的 persistence 字段独立配置每个服务的持久性。
运行以下命令,创建 secret 以访问 PostgreSQL:
oc create secret generic <postgresql_secret_name> \ --from-literal=POSTGRESQL_USER=<user> \ --from-literal=POSTGRESQL_PASSWORD=<password> \ -n <namespace>
$ oc create secret generic <postgresql_secret_name> \
--from-literal=POSTGRESQL_USER=<user> \
--from-literal=POSTGRESQL_PASSWORD=<password> \
-n <namespace>
4.3.4.3. 常见的 PostgreSQL 持久性配置 复制链接链接已复制到粘贴板!
OpenShift Serverless Logic Operator 会自动将支持服务连接到 spec.persistence 字段中配置的通用 PostgreSQL 服务器。
对于规则,以下优先级适用:
-
如果您为支持服务配置特定的持久性,如
services.dataIndex.persistence,它会使用该配置。 - 如果没有为服务配置持久性,系统将使用当前平台的通用持久性配置。
使用通用 PostgreSQL 配置时,每个服务模式会自动设置为 SonataFlowPlatform 名称,后缀为 with -data-index-service 或 -jobs-service,例如 sonataflow-platform-example-data-index-service。
4.3.5. 支持服务事件系统配置 复制链接链接已复制到粘贴板!
对于 OpenShift Serverless Logic 安装,会生成以下类型的事件:
- 与工作流业务逻辑相关的传出和传入事件。
- 从工作流发送到 Data Index 和 Job 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 配置集部署到同一命名空间中的工作流,且没有自定义事件系统配置,会自动链接到指定的代理。
在生产环境中,使用生产环境就绪的代理(如 Knative Kafka Broker)来提高可扩展性和可靠性。
以下示例演示了如何为平台范围事件系统配置 SonataFlowPlatform CR:
4.3.5.2. 系统范围的事件系统配置 复制链接链接已复制到粘贴板!
系统范围的事件系统配置允许对事件系统进行精细的控制,特别是 Data Index 或 Job Service。
对于 OpenShift Serverless Logic 安装,请考虑使用平台范围事件系统配置。服务级别配置仅用于高级用例。
4.3.5.3. 数据索引事件系统配置 复制链接链接已复制到粘贴板!
要为 Data Index 配置服务范围事件系统,您必须使用 SonataFlowPlatform CR 中的 spec.services.dataIndex.source.ref 字段来引用特定的 Knative Eventing Broker。此配置指示 OpenShift Serverless Logic Operator 自动链接 Data Index,以使用来自该代理的 SonataFlow 系统事件。
在生产环境中,使用生产环境就绪的代理(如 Knative Kafka Broker)来提高可扩展性和可靠性。
以下示例显示了 Data Index 事件系统配置:
4.3.5.4. 作业服务事件系统配置 复制链接链接已复制到粘贴板!
要为作业服务配置服务范围事件系统,您必须使用 SonataFlowPlatform CR 中的 spec.services.jobService.source.ref 和 spec.services.jobService.sink.ref 字段。这些字段指示 OpenShift Serverless Logic Operator 根据提供的配置自动链接作业服务以使用和生成 SonataFlow 系统事件。
在生产环境中,使用生产环境就绪的代理(如 Knative Kafka Broker)来提高可扩展性和可靠性。
以下示例显示了作业服务事件系统配置:
- 1
- 指定作业服务消耗事件的 Knative Eventing Broker。
- 2
- 可选:定义 Knative Eventing Broker 的命名空间。如果没有指定值,则参数默认为
SonataFlowPlatform命名空间。考虑在与SonataFlowPlatform相同的命名空间中创建 Broker。 - 3
- 指定作业服务在其上生成事件的 Knative Eventing Broker。
- 4
- 可选:定义 Knative Eventing Broker 的命名空间。如果没有指定值,则参数默认为
SonataFlowPlatform命名空间。考虑在与SonataFlowPlatform相同的命名空间中创建 Broker。
4.3.5.5. 用于支持服务的集群范围的事件系统配置 复制链接链接已复制到粘贴板!
当您部署集群范围的支持服务时,支持服务会自动链接到 SonataFlowPlatform CR 中指定的 Broker,该代理由 SonataFlowClusterPlatform CR 引用。
4.3.5.6. 支持服务的 Eventing 系统配置优先级规则 复制链接链接已复制到粘贴板!
OpenShift Serverless Logic Operator 按照定义的优先级顺序为支持服务配置事件系统。
Eventing 系统配置优先级规则如下:
- 如果支持服务有自己的事件系统配置,则使用 Data Index 事件系统或作业服务事件系统配置,则支持服务配置具有优先权。
-
如果
SonataFlowPlatformCR 认为支持服务配置了平台范围事件系统,则该配置具有优先权。 - 如果当前集群配置了集群范围的事件系统,则该配置将具有优先权。
- 如果以前配置没有存在,支持服务通过直接 HTTP 调用来提供事件。
4.3.5.7. Eventing 系统链接配置 复制链接链接已复制到粘贴板!
OpenShift Serverless Logic Operator 会自动创建 Knative Eventing、SinkBindings 和触发器,以使用事件系统链接支持服务。这些对象通过支持服务实现事件的生产和消费。
以下示例显示了为 SonataFlowPlatform CR 创建的 Knative Native 事件对象:
以下示例演示了如何配置用于 SonataFlowPlatform CR 的 Knative Kafka Broker:
SonataFlowPlatform CR 使用的 Knative Kafka Broker 示例
- 1
- 使用 Kafka 类创建 Kafka Knative Broker。
以下命令显示为 Data Index 和 Job Service 事件设置的触发器列表,显示哪些服务订阅事件:
oc get triggers -n example-namespace
$ oc get triggers -n example-namespace
输出示例
要查看作业服务的 SinkBinding 资源,请使用以下命令:
oc get sources -n example-namespace
$ oc get sources -n example-namespace
输出示例
NAME TYPE RESOURCE SINK READY sonataflow-platform-example-jobs-service-sb SinkBinding sinkbindings.sources.knative.dev broker:example-broker True
NAME TYPE RESOURCE SINK READY
sonataflow-platform-example-jobs-service-sb SinkBinding sinkbindings.sources.knative.dev broker:example-broker True
4.3.6. 高级支持服务配置 复制链接链接已复制到粘贴板!
如果需要为支持服务应用高级配置,请在 SonataFlowPlatform 自定义资源(CR)中使用 podTemplate 字段。此字段允许您通过指定副本数、环境变量、容器镜像和初始化选项等配置来自定义服务 pod 部署。
您可以使用以下示例为服务配置高级设置:
Data Index 服务的高级配置示例
您可以根据您的要求,将 'services' 字段设置为 'dataIndex' 或 'jobService'。其余的配置保持不变。
podTemplate 字段提供定制每个支持服务部署的灵活性。它遵循标准 PodSpec API,即相同的 API 验证规则适用于这些字段。
4.3.7. 集群范围内的支持服务 复制链接链接已复制到粘贴板!
您可以使用 SonataFlowClusterPlatform 自定义资源(CR)定义一组集群范围的支持服务,供不同命名空间中的工作流使用。通过引用特定于命名空间的 SonataFlowPlatform CR,您可以对集群范围内扩展这些服务。
您可以使用以下基本配置示例,它允许在任何命名空间中部署的工作流使用在特定命名空间中部署的支持服务,如 example-namespace :
SonataFlowClusterPlatform CR 示例
您可以通过在 SonataFlowPlatform.spec.services 中配置该命名空间来覆盖任何命名空间中的这些集群范围的服务。
第 5 章 管理工作流持久性 复制链接链接已复制到粘贴板!
您可以配置 SonataFlow 实例,以在关系数据库中使用持久性和存储工作流上下文。
按照设计,Kubernetes pod 是无状态的。这个行为可能会对在 pod 重启后维护应用程序状态的工作负载造成挑战。对于 OpenShift Serverless Logic,pod 默认重启时工作流上下文会丢失。
为确保在这样的场景中进行工作流恢复,您必须配置工作流运行时持久性。使用 SonataFlowPlatform 自定义资源(CR)或 SonataFlow CR 来提供此配置。配置的范围因您使用的资源而异。
5.1. 使用 SonataFlowPlatform CR 配置持久性 复制链接链接已复制到粘贴板!
SonataFlowPlatform 自定义资源(CR)在命名空间级别启用持久性配置。此方法会自动将持久性设置应用到命名空间中部署的所有工作流。它简化了资源配置,特别是当命名空间中的多个工作流属于同一应用程序时。虽然默认应用此配置,但命名空间中的单个工作流可以使用 SonataFlow CR 覆盖它。
OpenShift Serverless Logic Operator 还使用此配置来为支持服务设置持久性。
持久性配置仅在工作流部署时应用。对 SonataFlowPlatform CR 的更改不会影响已部署的工作流。
流程
-
定义
SonataFlowPlatformCR。 在
SonataFlowPlatformCR spec 的persistence字段中指定持久性设置。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 查看工作流生成的环境变量。
以下示例显示了使用较早
SonataFlowPlatform配置部署的名为example-workflow的工作流生成的环境变量。这些配置与持久性相关,并由 OpenShift Serverless Logic Operator 管理。应用这些设置后,您无法修改这些设置。
当您使用 SonataFlowPlatform 持久性时,每个工作流都配置为使用与工作流名称相等的 PostgreSQL 模式名称。
当此持久性配置就位时,OpenShift Serverless Logic Operator 会使用 preview 或 gitops 配置集配置在此命名空间中部署的每个工作流,通过将相关的 JDBC 连接参数注入环境变量来与 PostgreSQL 数据库进行连接。
PostgreSQL 目前是唯一受支持的用于持久性的数据库。
对于使用 preview 配置集进行 SonataFlow CR 部署,OpenShift Serverless Logic 构建系统自动包含启用持久性所需的特定 Quarkus 扩展。这样可确保与持久性机制兼容,简化了工作流部署过程。
5.2. 使用 SonataFlow CR 配置持久性 复制链接链接已复制到粘贴板!
SonataFlow 自定义资源(CR)启用特定于工作流的持久性配置。您可以独立使用此配置,即使当前命名空间中已经设置了 SonataFlowPlatform 持久性。
流程
-
使用
SonataFlowCR 规格中的persistence字段来配置持久性,如下例所示:
此配置告知 OpenShift Serverless Logic Operator,工作流在部署时必须连接到指定的 PostgreSQL 数据库服务器。OpenShift Serverless Logic Operator 将相关的 JDBC 连接参数作为环境变量添加到工作流容器中。
PostgreSQL 目前是唯一受支持的用于持久性的数据库。
对于使用 preview 配置集进行 SonataFlow CR 部署,OpenShift Serverless Logic 构建系统包括所需的 Quarkus 扩展来自动启用持久性。
5.3. 持久性配置优先级规则 复制链接链接已复制到粘贴板!
您可以独立使用 SonataFlow 自定义资源(CR)持久性,或者与 SonataFlowPlatform CR 持久性一起使用。如果当前命名空间中存在 SonataFlowPlatform CR 持久性配置,以下规则决定了应用哪个持久性配置:
-
如果
SonataFlowCR 包含持久性配置,则该配置具有优先权并应用到工作流。 -
如果
SonataFlowCR 不包含持久性配置,并且没有spec.persistence字段,OpenShift Serverless Logic Operator 会使用当前SonataFlowPlatform中的持久性配置。 -
要禁用工作流的持久性,请在
SonataFlowCR 中明确设置spec.persistence: {}。此配置可确保工作流不会继承SonataFlowPlatformCR 中的持久性设置。
5.4. 配置集的持久性要求 复制链接链接已复制到粘贴板!
为 SonataFlowPlatform 自定义资源(CR)和 SonataFlow CR 提供的持久性配置同样适用于 preview 和 gitops 配置集。但是,您必须避免将这些配置与 dev 配置集搭配使用,因为此配置集完全忽略它们。
preview 和 gitops 配置集之间的主要区别在于构建过程。
使用 gitops 配置集时,请确保构建过程中将以下 Quarkus 扩展包含在工作流镜像中。
| groupId | artifactId | version |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
如果您使用 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
$ 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
5.5. 数据库架构初始化 复制链接链接已复制到粘贴板!
当您将 SonataFlow 与 PostgreSQL 持久性搭配使用时,您可以通过启用 Flyway 来初始化数据库架构,或使用数据定义语言(DDL)脚本手动应用数据库架构更新。
Flyway 由 kie-addons-quarkus-flyway 运行时模块管理,它默认是禁用的。要启用 Flyway,您必须使用以下方法之一进行配置:
5.5.1. 工作流 ConfigMap 中的 Flyway 配置 复制链接链接已复制到粘贴板!
要在工作流 ConfigMap 中启用 Flyway,您可以添加以下属性:
在工作流 ConfigMap中启用 Flyway 的示例
5.5.2. 使用工作流容器中的环境变量进行 Flyway 配置 复制链接链接已复制到粘贴板!
您可以使用以下示例在 SonataFlow CR 的 spec.podTemplate.container 字段中添加环境变量来启用 Flyway :
使用工作流容器环境变量启用 Flyway 的示例
5.5.3. 使用 SonataFlowPlatform 属性进行 Flyway 配置 复制链接链接已复制到粘贴板!
要将通用 Flyway 配置应用到命名空间中的所有工作流,您可以将属性添加到 SonataFlowPlatform CR 的 spec.properties.flow 字段中,如下例所示:
此配置在工作流部署期间应用。在部署工作流前,请确保设置了 Flyway 属性。
使用 SonataFlowPlatform 属性启用 Flyway 的示例
5.5.4. 使用 DDL 脚本初始化手动数据库 复制链接链接已复制到粘贴板!
如果您希望手动初始化,则必须通过确保 kie.flyway.enabled 属性没有配置或明确设置为 false 来禁用 Flyway。
- 默认情况下,每个工作流都使用与工作流名称相等的 schema 名称。确保为每个工作流手动应用模式初始化。
-
如果您使用
SonataFlow自定义资源(CR)持久性配置,您可以指定自定义模式名称。
流程
- 从 kogito-ddl-9.102.0.redhat-00005-db-scripts.zip 位置下载 DDL 脚本。
- 提取文件。
运行位于目标 PostgreSQL 数据库的根目录中的
.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 的事件。
- 从作业服务发送到数据索引服务的事件。
OpenShift Serverless Logic Operator 利用 Knative Eventing 系统来管理这些服务之间的所有事件通信,确保事件处理高效且可靠的事件处理。
6.1. 平台范围内的事件系统配置 复制链接链接已复制到粘贴板!
要配置平台范围内的事件系统,您可以使用 SonataFlowPlatform 自定义资源(CR)中的 spec.eventing.broker.ref 字段来引用 Knative Eventing 代理。
此配置指示 OpenShift Serverless Logic Operator 使用 preview 或 gitops 配置集自动链接指定命名空间中部署的每个工作流,以通过定义的代理生成和使用事件。
在命名空间中部署的支持服务,没有自定义事件配置也链接到此代理。
在生产环境中,使用生产环境就绪的代理(如 Knative Kafka Broker)来提高可扩展性和可靠性。
以下示例演示了如何为平台范围事件系统配置 SonataFlowPlatform CR:
6.2. 工作流范围的事件系统配置 复制链接链接已复制到粘贴板!
工作流范围的事件系统配置允许详细自定义特定工作流生成和消耗的事件。您可以使用 SonataFlow CR 中的 spec.sink.ref 和 spec.sources[] 字段来配置传出和传入的事件。
6.2.1. 传出事件系统配置 复制链接链接已复制到粘贴板!
要配置传出事件,您可以使用 SonataFlow CR 中的 spec.sink.ref 字段。此配置可确保工作流使用指定的 Knative Eventing Broker 生成事件,包括系统事件和工作流业务事件。
以下示例演示了如何为工作流范围的传出事件系统配置 SonataFlow CR:
6.2.2. 传入事件系统配置 复制链接链接已复制到粘贴板!
要配置传入的事件,您可以使用 SonataFlow CR 中的 spec.sources[] 字段。您可以为需要特定配置的每个事件类型添加一个条目。此设置允许工作流根据事件类型使用来自不同代理的事件。
如果传入的事件类型缺少特定的代理配置,系统会应用事件系统配置优先级规则。
以下示例演示了如何为工作流范围的传入事件系统配置 SonataFlow CR:
spec.sources[] 条目和工作流事件之间的链接正在使用事件类型。
- 1
- 使用指定的 Knative Eventing Broker 将工作流配置为消耗
in-event-type1类型的事件。 - 2
- 发送到此工作流的 Knative Eventing Broker 事件
所使用的Knative Eventing Broker 名称。 - 3
- 可选:如果没有指定值,则参数默认为
SonataFlow命名空间。考虑在与SonataFlow工作流相同的命名空间中创建代理。 - 4
- 使用指定的 Knative Eventing Broker 将工作流配置为消耗
in-event-type2类型的事件。 - 5
- 发送到此工作流的 Knative Eventing Broker 事件
所使用的Knative Eventing Broker 名称。 - 6
- 可选:如果没有指定值,则参数默认为
SonataFlow命名空间。考虑在与SonataFlow工作流相同的命名空间中创建代理。 - 7
SonataFlowCR 中的流定义字段。- 8
SonataFlowCR 中的事件定义字段。- 9
- 传入事件
inEvent1定义示例。 - 10
- Event1
中传入事件的事件类型。工作流事件的链接与对应的spec.sources[]条目的链接通过使用事件类型名称in-event-type1。 - 11
- 传入事件
inEvent2定义示例。 - 12
- 传入事件的事件类型
inEvent2。工作流事件的链接使用对应的 spec.sources[] 条目创建,使用事件类型名称 in-event-type2 创建。
6.3. 集群范围的事件系统配置 复制链接链接已复制到粘贴板!
在 SonataFlowClusterPlatform 设置中,工作流会自动链接到关联的 SonataFlowPlatform CR 中指定的 Broker。这个链接内容遵循 Eventing 系统配置优先级规则。
为确保正确集成,您可以在 SonataFlowClusterPlatform CR 引用的 SonataFlowPlatform CR 中配置 Broker。
以下示例演示了如何配置 SonataFlowClusterPlatform CR 及其对 SonataFlowPlatform CR 的引用:
SonataFlowClusterPlatform CR 可以引用已部署的任何 SonataFlowPlatform CR。
6.4. Eventing 系统配置优先级规则 复制链接链接已复制到粘贴板!
OpenShift Serverless Logic Operator 按照定义的优先级顺序来确定工作流的事件系统配置。
Eventing 系统配置优先级规则如下:
- 如果工作流具有定义的事件系统,通过使用工作流范围传出或传入事件系统配置,则选择配置优先于其他配置并应用到工作流。
-
如果
SonataFlowPlatformCR 隔离工作流配置了平台范围事件系统,则此配置将应用于下一步。 - 如果当前集群配置了集群范围的事件系统,则在没有工作流范围或平台范围配置时应用它。
如果以上配置都没有定义,请查看以下信息:
- 工作流使用直接 HTTP 调用向支持服务发送 SonataFlow 系统事件。
-
工作流通过工作流服务根路径
/上的 HTTP POST 调用来消耗传入的事件。 - 没有事件系统配置为生成工作流业务事件。任何尝试生成此类事件都可能会导致失败。
6.5. 将工作流链接到事件系统 复制链接链接已复制到粘贴板!
OpenShift Serverless Logic Operator 使用 Knative Eventing、SinkBinding 和 triggers 将工作流与事件系统相关联。这些对象由 OpenShift Serverless Logic Operator 自动创建,并简化工作流事件的生产和消耗。
以下示例显示了为使用平台范围事件系统配置的 example-workflow 工作流创建的 Knative Eventing 对象:
example-broker 对象是一个 Kafka 类代理,其配置在 kafka-broker-config 配置映射中定义。
以下示例演示了如何配置用于 SonataFlowPlatform 的 Kafka Knative Broker:
- 1
- Kafka 类用于创建
example-broker对象。
以下示例显示 example-workflow 如何自动链接到 example-namespace 中的用于事件 production 和 consume 的 example-broker :
您可以使用以下命令列出自动创建的名为 example-workflow-sb 的 SinkBinding :
oc get sinkbindings -n example-namespace
$ oc get sinkbindings -n example-namespace
输出示例
NAME TYPE RESOURCE SINK READY example-workflow-sb SinkBinding sinkbindings.sources.knative.dev broker:example-broker True
NAME TYPE RESOURCE SINK READY
example-workflow-sb SinkBinding sinkbindings.sources.knative.dev broker:example-broker True
您可以使用以下命令列出为事件消耗自动创建的触发器:
oc get triggers -n <example-namespace>
$ oc get triggers -n <example-namespace>
输出示例
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
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
第 7 章 管理升级 复制链接链接已复制到粘贴板!
本节提供了将 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 Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
- 您可以访问 OpenShift Management Console 进行 Operator 升级。
-
已安装 OpenShift CLI(
oc)。
7.1.1.1. 使用 dev 配置集删除工作流 复制链接链接已复制到粘贴板!
在升级 Operator 之前,您必须删除使用 dev 配置集运行的工作流,并在升级完成后重新部署它们。
流程
-
确保备份所有必要 Kubernetes 资源,包括
SonataFlow自定义资源定义(CRD)、ConfigMap或任何其他相关的自定义配置。 运行以下命令来删除工作流:
oc delete -f <my-workflow.yaml> -n <target_namespace>
$ oc delete -f <my-workflow.yaml> -n <target_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.1.2. 使用 preview 配置集删除和迁移工作流 复制链接链接已复制到粘贴板!
在升级 Operator 前,您必须删除使用 Preview 配置集运行的工作流,并迁移保留的任何数据。升级完成后,您必须重新部署工作流。
流程
- 如果您使用持久性,备份工作流数据库并确保备份包含数据库对象和表数据。
-
确保备份所有必要 Kubernetes 资源,包括
SonataFlowCRD、ConfigMap或任何其他相关的自定义配置。 运行以下命令来删除工作流:
oc delete -f <my-workflow.yaml> -n <target_namespace>
$ oc delete -f <my-workflow.yaml> -n <target_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果使用持久性,您必须执行以下数据库迁移脚本:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.1.3. 使用 gitops 配置集缩减工作流 复制链接链接已复制到粘贴板!
在升级 Operator 前,您必须使用 gitops 配置集缩减运行的工作流,并在升级完成后再次扩展它们。
流程
修改
my-workflow.yamlCRD,并在升级前将每个工作流缩减为零,如下例所示:spec: podTemplate: replicas: 0spec: podTemplate: replicas: 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来应用更新的 CRD:
oc apply -f <my-workflow.yaml> -n <target_namespace>
$ oc apply -f <my-workflow.yaml> -n <target_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow (可选)运行以下命令来将工作流扩展到
0:oc patch sonataflow <my-workflow> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 0}}}'$ oc patch sonataflow <my-workflow> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 0}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.1.4. 备份数据索引数据库 复制链接链接已复制到粘贴板!
您必须在升级前备份 Data Index 数据库,以防止数据丢失。
流程
对 Data Index 数据库进行完整备份,确保:
- 备份包括所有数据库对象,而不仅仅是表数据。
- 备份存储在安全位置。
7.1.1.5. 备份作业服务数据库 复制链接链接已复制到粘贴板!
在升级前备份 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 Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
- 您可以访问 OpenShift Management Console 进行 Operator 升级。
-
已安装 OpenShift CLI(
oc)。
流程
- 在 Web 控制台中,导航到 Operators → OperatorHub → Installed Operator 页面。
-
从 Installed Namespace 中选择
openshift-serverless-logic命名空间。 - 在安装的 Operator 列表中,找到并点击 OpenShift Serverless Logic Operator。
- 在 Operator 详情页面中,点 Subscription 选项卡。点 Edit Subscription。
- 在 Upgrade status 中,单击 Upgrade available 链接。
- 单击 Preview 安装计划和 Approve 以开始更新。
要监控升级过程,请运行以下命令:
oc get subscription logic-operator-rhel8 -n openshift-serverless-logic -o jsonpath='{.status.installedCSV}'$ oc get subscription logic-operator-rhel8 -n openshift-serverless-logic -o jsonpath='{.status.installedCSV}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出
logic-operator-rhel8.v1.35.0
$ logic-operator-rhel8.v1.35.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
要验证是否安装了新的 Operator 版本,请运行以下命令:
oc get clusterserviceversion logic-operator-rhel8.v1.35.0 -n openshift-serverless-logic
$ oc get clusterserviceversion logic-operator-rhel8.v1.35.0 -n openshift-serverless-logicCopy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出
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
NAME DISPLAY VERSION REPLACES PHASE logic-operator-rhel8.v1.35.0 OpenShift Serverless Logic Operator 1.35.0 logic-operator-rhel8.v1.34.0 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.3. 最终调整升级 复制链接链接已复制到粘贴板!
将 OpenShift Serverless Logic Operator 升级到 1.35.0 后,您必须恢复或扩展工作流并清理旧服务来完成升级过程。这样可确保您的系统在新版本中完全运行,且所有依赖的组件都已正确配置。
根据您的工作流和服务的配置集,请按照以下步骤操作。
先决条件
-
您可以使用
cluster-admin权限访问集群。 - 已在集群中安装了 OpenShift Serverless Logic Operator。
- 您可以使用适当的角色和权限访问 OpenShift Serverless Logic 项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
- 您可以访问 OpenShift Management Console 进行 Operator 升级。
-
已安装 OpenShift CLI(
oc)。
7.1.3.1. 最终调整数据索引升级 复制链接链接已复制到粘贴板!
Operator 升级后,会自动为 Data Index 1.35.0 创建新的 ReplicaSet。您必须手动删除旧的旧内容。
流程
运行以下命令列出所有 ReplicaSet 来验证新的 ReplicaSet 是否存在:
oc get replicasets -n <target_namespace> -o custom-columns=Name:metadata.name,Image:spec.template.spec.containers[*].image
$ oc get replicasets -n <target_namespace> -o custom-columns=Name:metadata.name,Image:spec.template.spec.containers[*].imageCopy to Clipboard Copied! Toggle word wrap Toggle overflow 识别旧的 Data Index ReplicaSet (使用版本 1.34.0)并删除它:
oc delete replicaset <old_replicaset_name> -n <target_namespace>
$ oc delete replicaset <old_replicaset_name> -n <target_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.3.2. 最终调整作业服务升级 复制链接链接已复制到粘贴板!
您必须手动清理旧版本中的 Jobs Service 组件,才能触发版本 1.35.0 组件的部署。
流程
运行以下命令来删除旧的 Jobs Service 部署:
oc delete deployment <jobs-service-deployment-name> -n <target_namespace>
$ oc delete deployment <jobs-service-deployment-name> -n <target_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这将触发旧的 Pod 和 ReplicaSet 自动清理,并使用版本 1.35.0 启动新部署。
7.1.3.3. 使用 dev 配置集重新部署工作流 复制链接链接已复制到粘贴板!
升级后,您必须重新部署使用 dev 配置集和任何关联的 Kubernetes 资源的工作流。
流程
-
确保恢复所有必需的资源,包括
SonataFlowCRD、ConfigMap或任何其他相关的自定义配置。 运行以下命令来重新部署工作流:
oc apply -f <my-workflow.yaml> -n <target_namespace>
$ oc apply -f <my-workflow.yaml> -n <target_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.3.4. 使用 preview 配置集恢复工作流 复制链接链接已复制到粘贴板!
带有 preview 配置集的工作流需要额外的配置步骤,然后才能重新部署。
流程
如果工作流使用持久性,请将以下属性添加到与工作流关联的
ConfigMap中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
确保重新创建所有必需的资源,包括
SonataFlowCRD、ConfigMap或任何其他相关的自定义配置。 运行以下命令来重新部署工作流:
oc apply -f <my-workflow.yaml> -n <target_namespace>
$ oc apply -f <my-workflow.yaml> -n <target_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.3.5. 使用 gitops 配置集扩展工作流 复制链接链接已复制到粘贴板!
带有之前扩展的 gitops 配置集的工作流必须扩展才能继续操作。
流程
修改
my-workflow.yamlCRD,并在升级前将每个工作流扩展到一个,如下例所示:spec: podTemplate: replicas: 1spec: podTemplate: replicas: 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令来应用更新的 CRD:
oc apply -f <my-workflow.yaml> -n <target_namespace>
$ oc apply -f <my-workflow.yaml> -n <target_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow (可选)运行以下命令来将工作流扩展至
1:oc patch sonataflow <my-workflow> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 1}}}'$ oc patch sonataflow <my-workflow> -n <target_namespace> --type=merge -p '{"spec": {"podTemplate": {"replicas": 1}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.3.6. 验证升级 复制链接链接已复制到粘贴板!
恢复工作流和服务后,务必要验证升级是否成功,并且所有组件都按预期工作。
流程
输入以下命令检查所有工作流和服务是否正在运行:
oc get pods -n <target_namespace>
$ oc get pods -n <target_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确保与工作流、数据索引和作业服务相关的所有 pod 都处于
Running或Completed状态。输入以下命令验证 OpenShift Serverless Logic Operator 是否正确运行:
oc get clusterserviceversion logic-operator-rhel8.v1.35.0 -n openshift-serverless-logic
$ oc get clusterserviceversion logic-operator-rhel8.v1.35.0 -n openshift-serverless-logicCopy to Clipboard Copied! Toggle word wrap Toggle overflow 预期输出
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
NAME DISPLAY VERSION REPLACES PHASE logic-operator-rhel8.v1.35.0 OpenShift Serverless Logic Operator 1.35.0 logic-operator-rhel8.v1.34.0 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令检查 Operator 日志是否有任何错误:
oc logs -l control-plane=sonataflow-operator -n openshift-serverless-logic
$ oc logs -l control-plane=sonataflow-operator -n openshift-serverless-logicCopy to Clipboard Copied! Toggle word wrap Toggle overflow