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-service
or-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 事件系统或作业服务事件系统配置,则支持服务配置具有优先权。
-
如果
SonataFlowPlatform
CR 认为支持服务配置了平台范围事件系统,则该配置具有优先权。 - 如果当前集群配置了集群范围的事件系统,则该配置将具有优先权。
- 如果以前配置没有存在,支持服务通过直接 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
中配置该命名空间来覆盖任何命名空间中的这些集群范围的服务。