概要描述

本文主要描述如何在 TDH Manager 环境的 TDS 4.1及以上版本部署调度任务外置执行器（Workflow Agent）。

详细说明

外置执行器的作用

未安装外置执行器时，所有的调度任务都会使用容器环境的内置执行器执行。但有时容器内缺少必要的环境导致无法正常运行任务，尤其是 Python 、Java 等代码任务或是依赖用到宿主机某个路径下文件的 Shell 任务等。

此时就建议使用外置执行器，外置执行器直接部署在服务器宿主机上，理论上只要服务器本地可以手动运行这些任务，那么调度任务就能运行成功。

外置执行器部署步骤

下载 RPM 包

在开发场景->执行器页面，可以点击下载执行器rpm安装包。文件大小大约200多MB。

注意，有的版本菜单名称可能会有区别，同时TDS支持自定义菜单显示名称，具体以实际菜单名称为准。

上传 RPM 包

把下载好的 RPM 包上传到想部署外置执行器的服务器上，放在任意目录即可。

hosts 信息检查（跨集群时需要操作）

当想部署外置执行器的服务器不在 TDS 所在的星环集群内时，需要进行本步骤的操作。如果想部署外置执行器的服务器就是 TDS 所在的星环集群内的某个节点，跳过本步骤。

首先需要在 TDS 集群的 Manager 页面，查看 Workflow 服务页面的角色标签页，确认所有的 Workflow Server 和 Workflow Scheduler 部署在哪些节点上。

例如上图的情况，涉及的节点就是gts-131079。如果您的环境 Workflow Server 与 Workflow Scheduler 部署在不同节点，或是部署了多个角色做高可用，则涉及的节点可能是多个。

然后需要在这些节点的/etc/hosts和/etc/transwarp/conf/hosts文件中加上想部署的外置执行器的节点IP与hostname的映射，如图所示。记得所有涉及节点的两个文件都要添加。

如果修改了/etc/hosts和/etc/transwarp/conf/hosts文件，还需要重启 Workflow Server 和 Workflow Scheduler 角色来应用新的 hosts 文件。

在 Manager 页面的 Workflow 服务页面，勾选全部 Workflow Server 和 Workflow Scheduler 角色，再点击右下角的重启按钮即可。注意这个操作会影响所有的 TDS 调度任务，建议在允许操作的窗口时间操作。

然后需要在想部署外置执行器的节点上，更新/etc/hosts文件，把 TDS 的所有 Workflow Server 和 Workflow Scheduler 节点的IP和hostname的映射添加好。

检查并卸载已安装的外置执行器

在想部署外置执行器的节点上，先检查是否已经安装了外置执行器。

执行以下命令：

rpm -qa | grep workflow-executor

如果打印类似如下信息，说明已经安装了外置执行器并会显示版本号。

如上图，已经安装了4.3.0版本的外置执行器。

如果该版本与下载 RPM 包文件名显示的版本号对不上，则需要卸载并重新安装下载的 RPM 包；如果该版本与下载 RPM 包文件名显示的版本号一致，可以跳过卸载步骤，但也建议继续卸载并重新安装，避免小版本兼容性问题；如果未打印已安装的外置执行器信息，说明当前没有安装外置执行器，可以跳过卸载步骤。

在卸载前，需要先停止当前运行的外置执行器服务：

service workflow-executor stop

执行以下命令来卸载当前的外置执行器：

rpm -e workflow-executor-4.3.0-SNAPSHOT20260312142828.noarch

其中workflow-executor-4.3.0-SNAPSHOT20260312142828.noarch需要换成刚才rpm -qa命令查询出来的外置执行器包名，以您的实际情况为准。

安装 RPM 包

在想部署外置执行器的节点上，先进入防止RPM包的路径下，再执行以下命令安装：

rpm -ivh executor-4.3.0.rpm

这里的executor-4.3.0.rpm需要换成实际下载的 RPM 包文件名。

确定 Foundation Web 的 IP 和端口号

在 Manager 中，进入 TDS 的 Foundation 服务页面的角色标签页，然后在所有 Foundation Web 角色后面的服务链接中，记下服务链接的 IP 和端口号。多网卡环境下，可能一个服务链接下会显示好几个IP地址的链接，挑选外置执行器节点能访问的任意一个 IP 地址即可。例如上图例子中，需要记下的是172.18.131.178这个IP地址和28190这个端口号。

注意如果 Foundation 中安装了多个 Foundation Web ，为确保高可用生效，需要每个 Foundation Web 的服务链接都记下一组 IP 和端口号。

修改外置执行器配置文件

外置执行器配置文件路径为/usr/local/workflow-executor/conf/application.yml，以下为常见的配置项，请按需修改。

• eureka地址（必须）

找到如下配置：

eureka:
  client:
    registry-fetch-interval-seconds: 5
    serviceUrl:
      defaultZone: https://gts-131078:28190/eureka/

修改defaultZone的值，将其修改为https://{Foundation Web IP}:{Foundation Web 端口号}/eureka/，例如上面的https://gts-131078:28190/eureka/。

如果存在多个 Foundation Web 角色，此配置项配置为多条并用,隔开，例如：

eureka:
  client:
    registry-fetch-interval-seconds: 5
    serviceUrl:
      defaultZone: https://kv4:28190/eureka/,https://kv3:28190/eureka/

• User Server 地址（4.2及以下版本必须）

找到如下配置：

foundation.log.audit.user-server.host: "https://gts-131078:28190"

修改foundation.log.audit.user-server.host的值，将其修改为https://{Foundation Web IP}:{Foundation Web 端口号}，例如上面的https://gts-131078:28190。

同样地，如果存在多个 Foundation Web 角色，此配置项配置为多条并用,隔开，例如：

foundation.log.audit.user-server.host: https://kv4:28190,https://kv3:28190

如果你发现这个配置项前面被加了注释符号#，或搜索不到该配置项，则无需添加或修改，高版本（例如 4.3 及以上）已经取消了该配置，程序会直接使用上面配置的 eureka 地址。

• 服务运行端口号（可选）

外置执行器默认启动在节点的9103端口，如需修改，可以找到如下配置项修改：

server:
  port: 19103

修改port的值，将其修改为希望运行外置执行器的端口号，例如上面的19103。注意，该端口号需要确保没有被其他程序占用。

• 外置执行器执行用户（可选）

外置执行器安装时会新建workflow用户，作为默认的外置执行器执行用户，后续分配到该外置执行器的调度任务都会使用这个用户来执行。如果想要修改执行用户，可以找到如下配置项修改：

rpm.user: root

修改rpm.user的值，将其修改为期望的外置执行器执行用户，例如上面的root，这表示外置执行器上的任务将使用root用户在节点上执行。

注意，如果修改了执行用户，建议按照后面几步的赋权步骤重新对执行用户赋权避免出现权限问题。

• 外置执行器日志目录（可选）

外置执行器的服务和执行日志默认会保存到服务器的/var/log/workflow-executor目录下。如果想要修改日志保存路径，可以找到如下配置项修改：

logger.file.dir: /var/log/workflow-executor-gts-131078

修改logger.file.dir的值，将其修改为期望的外置执行器日志保存目录，例如上面的/var/log/workflow-executor-gts-131078。

注意，无论是修改过启动用户还是修改过日志目录，都建议手动创建日志目录并赋权。

mkdir -p {日志目录}
# 例如 mkdir -p /var/log/workflow-executor-gts-131078

chown -R {执行用户的用户名}:{执行用户的用户组} {日志目录}
# 例如 chown -R root:root /var/log/workflow-executor-gts-131078

chmod -R 744 {日志目录}
# 按需设置，至少需要600权限。例如 chmod -R 744 /var/log/workflow-executor-gts-131078

• 外置执行器的SQL驱动目录（可选）

一般外置执行器是用于执行 Python 、Java 、Shell 等代码任务的，但也可以将其用于执行 SQL 任务。用于执行 SQL 任务时，需要将驱动程序和认证文件放入特定本地目录中。默认目录为/var/lib/connector/driver和/var/lib/connector/authFile。如需修改，可以找到如下配置项修改：

connector.driver.base-location: /var/lib/connector/driver
connector.driver.auth-file-location: /var/lib/connector/authFile

修改connector.driver.base-location的值，将其修改为期望的外置执行器SQL驱动文件保存目录，例如上面的/var/lib/connector/driver；修改connector.driver.auth-file-location的值，将其修改为期望的外置执行器认证文件保存目录，例如上面的/var/lib/connector/authFile。

注意，无论是修改过启动用户还是修改过SQL驱动目录，都建议手动创建SQL驱动目录并赋权。

mkdir -p {驱动文件保存目录}
# 例如 mkdir -p /var/lib/connector/driver

chown -R {执行用户的用户名}:{执行用户的用户组} {驱动文件保存目录}
# 例如 chown -R root:root /var/lib/connector/driver

chmod -R 744 {驱动文件保存目录}
# 按需设置，至少需要600权限。例如 chmod -R 744 /var/lib/connector/driver

mkdir -p {认证文件保存目录}
# 例如 mkdir -p /var/lib/connector/authFile

chown -R {执行用户的用户名}:{执行用户的用户组} {认证文件保存目录}
# 例如 chown -R root:root /var/lib/connector/authFile

chmod -R 744 {认证文件保存目录}
# 按需设置，至少需要600权限。例如 chmod -R 744 /var/lib/connector/authFile

• 外置执行器工作目录（可选）

外置执行器的任务执行时使用的临时文件默认会存放到/var/lib/workflow-executor目录下。如果想要修改工作目录，可以找到如下配置项修改：

task.working.root.dir: /var/lib/workflow-executor

修改task.working.root.dir的值，将其修改为期望的外置执行器工作目录，例如上面的/var/lib/workflow-executor。

注意，无论是修改过启动用户还是修改过工作目录，都建议手动创建日志目录并赋权。

mkdir -p {工作目录}
# 例如 mkdir -p /var/lib/workflow-executor

chown -R {执行用户的用户名}:{执行用户的用户组} {工作目录}
# 例如 chown -R root:root /var/lib/workflow-executor

chmod -R 744 {工作目录}
# 按需设置，至少需要600权限。例如 chmod -R 744 /var/lib/workflow-executor

外置执行器的启停和运维

外置执行器默认可以使用service命令来管理服务，常用的运维命令有：

# 启动
service workflow-executor start

# 停止
service workflow-executor stop

# 重启
service workflow-executor restart

# 查看状态
service workflow-executor status

注意在修改了外置执行器配置后，必须重启使配置生效。

其他常见运维方式：

• 查看端口号是否监听

netstat -lntp | grep {外置执行器端口号}

• 查看日志文件

tail -200f {外置执行器日志目录}/workflow-executor.log

外置执行器的网络要求

• 外置执行器节点需要可以访问 Foundation 服务的 Foundation Web 角色的端口号（端口配置项foundation.web.http.port，默认为28190）
• 外置执行器节点需要可以访问 Workflow 服务的 Workflow Scheduler 角色的端口号（端口配置项workflow.scheduler.http.port，默认为28912）
• Workflow 服务的 Workflow Scheduler 角色所在节点需要可以访问外置执行器端口（见上面配置修改，默认9103）
• 如果需要使用外置执行器执行SQL任务，外置执行器节点需要可以访问 Foundation 服务的 Foundation Connector 角色的端口号（端口配置项foundation.connector.http.port，默认为28184）
• 如果需要使用外置执行器执行数据加载任务，外置执行器节点需要可以访问 Transporter 服务的 Transporter Server 角色的端口号（端口配置项tdt.server.port，默认为28140）
• 如果需要使用外置执行器执行数据质量任务，外置执行器节点需要可以访问 TDSGovernor 服务的 Data Quality 角色的端口号（端口配置项quality.http.port，默认为28100）
• 如果需要使用外置执行器执行落标检查任务，外置执行器节点需要可以访问 TDSGovernor 服务的 Data Standard 角色的端口号（端口配置项standard.http.port，默认为28381）
• 如果需要使用外置执行器执行数据指标任务，外置执行器节点需要可以访问 MegaIndex 服务的 MegaIndex Web 角色的端口号（端口配置项megaindex.http.port，默认为18151）
• 其他依据任务中用到的外部IP、端口需要自行调整网络，例如 SQL 任务中访问 Oracle 执行SQL，那么外置执行器节点就需要可以访问 Oracle 数据源

常见问题

1 启动时报错证书异常 PKIX path building failed

如果启动时看到类似如下内容的日志信息：

...
... PKIX path building failed: ...
... unable to find valid certification path to requested target
...

这表示当前环境 JDK 中没有信任 eureka 的证书，可以导入并信任。

首先在集群内任意一个 TOS Master 所在节点（通常管理节点即可），执行

kubectl get po -owide | grep foundation-web

可以看到集群中的Foundation Web的pod信息。

如果有多个，根据服务名和IP地址判断一下哪些pod是当前TDS需要的服务的，记下任意一个正确的pod名即可，例如foundation-web-foundation1-566955b9b5-xnvzl。

然后执行以下命令从pod内复制证书文件到日志目录下。

kubectl exec -it foundation-web-foundation1-566955b9b5-xnvzl -- cp -p /srv/oauth2server/ca.crt /var/log/foundation1/foundation-web/ca.crt

上面命令中的pod名、日志目录名需要修改为实际的。

此时在该pod所在的节点，/var/log/foundationX/foundation-web/（X为实际服务编号）目录下即可看到ca.crt证书文件。

然后需要把这个文件放置到外置执行器所在节点，并使用这个命令导入证书。

{节点jdk目录}/jre/lib/security/cacerts" -file "{ca.crt文件路径}" -alias caskeystore

如果提示输入密码，请输入changeit。

再尝试重启外置执行器即可。

2 服务器重启后外置执行器没有自动启动

需要手动设置自动启动即可。

systemctl enable workflow-executor