Apache DolphinScheduler 云上部署实战：基于 Terraform 与 Packer 在 AWS 一键搭建调度平台-平芜编程栈

任务调度
大数据
后端
前端

【免费下载链接】dolphinscheduler

Apache DolphinScheduler is the modern data orchestration platform. Agile to create high performance workflow with low-code

项目地址：https://gitcode.com/gh_mirrors/do/dolphinscheduler

点击查看免费下载

Apache DolphinScheduler 是一个现代的云原生数据编排平台，其官方仓库在 deploy/terraform 目录下提供了完整的 IaC（基础设施即代码）方案：借助Packer 构建预装 DolphinScheduler 的 AMI，再通过Terraform 一键拉起 VPC、RDS、S3、ZooKeeper 与各服务组件实例，实现 standalone（单机）或 cluster（集群）两种模式在 AWS 上的分钟级部署。读完本文，你将掌握从编写pkrvars.hcl/tfvars变量文件，到构建 AMI、apply 资源、打开 Web UI 的完整实战链路，并能对照源码理解每一层基础设施的用途。

方案总览：两条部署路径

官方 Terraform 方案将部署拆分为两个阶段，对应仓库中的两套脚本：

构建 AMI 阶段：使用 deploy/terraform/aws/packer/ds-ami-official.pkr.hcl（官方发行包）或 deploy/terraform/aws/packer/ds-ami-local.pkr.hcl（本地构建产物）制作自定义 AMI。
创建资源阶段：使用 deploy/terraform/aws 目录下的.tf文件创建网络、数据库、对象存储、ZooKeeper 以及 DolphinScheduler 各组件（master、worker、alert、api、standalone-server）的 EC2 实例。

整体目录结构如下：

deploy/terraform/ ├── README.md # 方案总入口 └── aws/ ├── README.md # AWS 部署操作手册 ├── packer/ # 两个 AMI 构建模板 │ ├── ds-ami-official.pkr.hcl │ └── ds-ami-local.pkr.hcl ├── templates/ # cloud-init 用户数据模板 │ ├── cloud-init.yaml │ └── zookeeper/cloud-init.yaml ├── dolphinscheduler-{master,worker,alert,api,standalone}.tf ├── network-main.tf # VPC / 子网 / 路由 ├── rds-main.tf # PostgreSQL RDS ├── s3-main.tf # S3 桶与 IAM 用户 ├── zookeeper-main.tf # 单节点 ZooKeeper（演示用） └── *.tf # provider、变量、输出等

前置条件

在开始之前，需要在本地环境安装两个 HashiCorp 工具（按官方文档安装即可）：

Packer：用于构建 AMI，官方仓库要求其版本支持amazon-ebsbuilder 与github.com/hashicorp/amazon插件（见 ds-ami-official.pkr.hcl 中required_plugins声明，版本要求>= 0.0.1）。
Terraform：用于编排 AWS 资源，当前配置使用的 AWS provider 由 provider-main.tf 定义，直接读取aws_access_key、aws_secret_key、aws_region三个变量。

同时需要准备好具有相应权限的 AWS 访问密钥（Access Key / Secret Key），并确认目标区域（示例默认使用cn-north-1）。

第一步：构建 DolphinScheduler AMI

AMI（Amazon Machine Image）是本次部署的"基础镜像"。Packer 会基于 Amazon Linux 2022（al2022-ami-*）官方镜像，安装 Java 8（java-1.8.0-amazon-corretto），并将 DolphinScheduler 发行包解压到/opt/dolphinscheduler，最后对所有start.sh脚本赋予可执行权限。

编写 Packer 变量文件

首先创建ds-ami.pkrvars.hcl，按需填写以下变量：

cat <<EOF > ds-ami.pkrvars.hcl aws_access_key = "" aws_secret_key = "" aws_region = "cn-north-1" ds_ami_name = "my-test-ds-2" # 如果使用官方发行 tar，只需把 ds_version 设为你想要的版本号 ds_version = "3.1.1" # 如果使用本地构建的发行 tar，则把 ds_tar 指向 tar 文件位置 ds_tar = "~/workspace/dolphinscheduler/dolphinscheduler-dist/target/apache-dolphinscheduler-3.1.3-SNAPSHOT-bin.tar.gz" EOF

两个 Packer 模板共有的变量包括：aws_access_key（AWS Access Key，必填）、aws_secret_key（AWS Secret Key，必填）、aws_region（区域，默认cn-north-1）、ds_ami_name（AMI 名称，默认dolphinscheduler-ami）。区别在于发行包的来源：

ds-ami-official.pkr.hcl 使用ds_version变量（默认3.1.1），构建时通过curl从 Apache 归档地址拉取对应版本的apache-dolphinscheduler-${var.ds_version}-bin.tar.gz并解压到/opt/dolphinscheduler；
ds-ami-local.pkr.hcl 使用ds_tar变量（必填），通过provisioner "file"将本地 tar 上传到实例后解压，适合验证本地修改过的源码构建产物。

两种构建命令

使用官方发行包构建：

packer init --var-file=ds-ami.pkrvars.hcl packer/ds-ami-official.pkr.hcl packer build --var-file=ds-ami.pkrvars.hcl packer/ds-ami-official.pkr.hcl

使用本地构建的发行包构建：

packer init --var-file=ds-ami.pkrvars.hcl packer/ds-ami-local.pkr.hcl packer build --var-file=ds-ami.pkrvars.hcl packer/ds-ami-local.pkr.hcl

packer init会按模板中的required_plugins自动安装 amazon 插件，packer build则执行构建。构建产物是一个名为ds_ami_name的私有 AMI，后续 Terraform 通过 os-versions.tf 中的data "aws_ami" "dolphinscheduler"（owners = ["self"]，按var.ds_ami_name过滤且取most_recent）来引用它——这正是要求terraform.tfvars中ds_ami_name必须与 Packer 变量文件一致的原因。

第二步：创建 AWS 资源

编写 Terraform 变量文件

创建terraform.tfvars，注意ds_ami_name必须与上面ds-ami.pkrvars.hcl中保持一致：

cat <<EOF > terraform.tfvars aws_access_key = "" aws_secret_key = "" aws_region = "" name_prefix = "test-ds-terraform" ds_ami_name = "my-test-ds" ds_component_replicas = { master = 1 worker = 1 alert = 1 api = 1 standalone_server = 0 } EOF

ds_component_replicas是部署形态的开关：当standalone_server设为0、其余组件各设1时，部署的是cluster（集群）模式（master / worker / alert / api 四个独立进程，通过 ZooKeeper 注册与协作）；反之，若只将standalone_server设为1、其余全为0，则部署standalone（单机）模式——所有服务打包在一个standalone-server进程中。两种模式可以共存（例如集群之外再开一台演示机）。

执行 apply

terraform init -var-file=terraform.tfvars terraform apply -var-file=terraform.tfvars -auto-approve

terraform init初始化 provider 与模块（S3 bucket 使用了社区模块terraform-aws-modules/s3-bucket/aws，见 s3-main.tf），terraform apply开始创建资源。整个过程会依次完成以下基础设施的编排。

资源拓扑：Terraform 到底创建了什么

对照 deploy/terraform/aws 目录下的.tf文件，一次 apply 大致创建以下资源：

网络层（network-main.tf）

一个 VPC（默认 CIDR10.0.0.0/16，启用 DNS hostname）；
一个 Internet Gateway；
公网子网（默认 1 个，CIDR 从10.0.1.0/24起）与私网子网（默认 2 个，CIDR 从10.0.101.0/24起），分别绑定公网/私网路由表；
各组件实例都落在公网子网并绑定公网 IP（vm_associate_public_ip_address默认全为true），便于直接访问 UI 与 SSH。

数据库层（rds-main.tf）

一个 PostgreSQL 14.5 的 RDS 实例（aws_db_instance，标识符dolphinscheduler，默认db.t3.micro，5GB 存储，skip_final_snapshot = true适合测试场景）；
数据库名、用户、密码分别来自db_name（固定dolphinscheduler）、db_username（默认dolphinscheduler）、db_password（必填）；
安全组只放行 master、worker、alert、api、standalone 五个安全组访问 5432 端口。

对象存储层（s3-main.tf）

一个以dolphinscheduler-test-为前缀的私有 S3 桶（force_destroy = true，方便测试销毁）；
一个名为${name_prefix}-s3的 IAM 用户及一对 Access Key，仅对该桶授予s3:*权限；
这些密钥会通过 cloud-init 注入common.properties，作为 DolphinScheduler 的资源存储（resource.storage.type=S3）。

ZooKeeper 层（zookeeper-main.tf）

仅当zookeeper_connect_string为空时创建（count = var.zookeeper_connect_string != "" ? 0 : 1）：一台 Amazon Linux 2022 实例，cloud-init 安装并启动 Docker 后，通过 remote-exec 运行docker run ... -p 2181:2181 zookeeper:3.5容器提供单节点 ZooKeeper；
该变量注释明确提示"仅用于演示，不要在生产环境使用"——生产环境应传入已有的 ZooKeeper 连接串。

组件实例层（dolphinscheduler-{master,worker,alert,api,standalone}.tf）

每个组件都包含一个安全组 + 一个aws_instance，实例数量由ds_component_replicas对应键控制，并通过user_data注入 templates/cloud-init.yaml 渲染后的启动脚本。各组件端口规划如下：

组件	监听端口	安全组放行规则（源码位置）
api-server	12345（对外 HTTP）	对`0.0.0.0/0`开放，见 dolphinscheduler-api.tf
master-server	5678	仅放行 api 安全组与 worker 安全组，见 dolphinscheduler-master.tf
worker-server	1234	仅放行 master 与 api 安全组，见 dolphinscheduler-worker.tf
alert-server	50052–50053	仅放行 worker 安全组，见 dolphinscheduler-alert.tf
standalone-server	12345（对外 HTTP）	对`0.0.0.0/0`开放，见 dolphinscheduler-standalone.tf

所有组件实例的 root 卷与 data 卷都启用加密（encrypted = true），默认规格见 dolphinscheduler-variables.tf（如 master / worker 默认t2.medium、api / standalone 默认t2.small、alert 默认t2.micro）。

cloud-init：从 AMI 到运行中的服务

cloud-init.yaml 是理解整套自动化关键的一环，它完成了三件事：

创建系统用户ds：免密 sudo，并注入 SSH 公钥（来自aws_key_pair，由 key-pair-main.tf 动态生成）；
写入两个 systemd 单元：
- dolphinscheduler-schema.service（oneshot）：以ds用户执行/opt/dolphinscheduler/tools/bin/upgrade-schema.sh，通过SPRING_DATASOURCE_URL等环境变量连接 RDS，完成数据库 schema 初始化；
- dolphinscheduler.service：Requires=dolphinscheduler-schema.service，以bash -l /opt/dolphinscheduler/${dolphinscheduler_component}/bin/start.sh启动对应组件进程，并注入REGISTRY_ZOOKEEPER_CONNECT_STRING（ZooKeeper 地址，集群模式下必填）、WORKER_ALERT_LISTEN_HOST（alert 服务地址）等环境变量，Restart=always保证进程崩溃自动拉起；
runcmd 初始化：通过sed批量改写所有common.properties，把资源存储切换为 S3 并写入 IAM 密钥、region、桶名；随后依次systemctl start dolphinscheduler-schema、systemctl start dolphinscheduler，先初始化 schema 再启动服务。

因此，terraform apply结束后，各 EC2 实例上的组件会自动完成注册并对外提供服务，无需再手工登录机器配置。

第三步：打开 DolphinScheduler UI

apply 成功后，通过 Terraform 的 output 可以拿到 api-server（或 standalone-server）的公网 DNS：

open http://$(terraform output -json api_server_instance_public_dns | jq -r '.[0]'):12345/dolphinscheduler/ui

api_server_instance_public_dns来自 dolphinscheduler-output.tf 中定义的 output（值为aws_instance.api[*].public_dns的列表），配合jq取第一个元素拼出完整 URL。默认账号密码为 DolphinScheduler 的初始管理员账号admin/dolphinscheduler123。

输入变量全表（Inputs）

以下是 AWS 方案的完整输入变量表（来自 deploy/terraform/aws/README.md 与各*-variables.tf文件）：

Name	Description	Type	Default	Required
aws_access_key	AWS access key	`string`	n/a	yes
aws_region	AWS region	`string`	`"cn-north-1"`	no
aws_secret_key	AWS secret key	`string`	n/a	yes
db_instance_class	Database instance class	`string`	`"db.t3.micro"`	no
db_password	Database password	`string`	n/a	yes
db_username	Database username	`string`	`"dolphinscheduler"`	no
ds_ami_name	Name of DolphinScheduler AMI	`string`	`"dolphinscheduler-ami"`	no
ds_component_replicas	Replicas of the DolphinScheduler Components	`map(number)`	`{alert=1, api=1, master=1, standalone_server=0, worker=1}`	no
ds_version	DolphinScheduler Version	`string`	`"3.1.1"`	no
name_prefix	Name prefix for all resources	`string`	`"dolphinscheduler"`	no
private_subnet_cidr_blocks	Available CIDR blocks for private subnets	`list(string)`	`["10.0.101.0/24","10.0.102.0/24","10.0.103.0/24","10.0.104.0/24"]`	no
public_subnet_cidr_blocks	CIDR blocks for the public subnets	`list(string)`	`["10.0.1.0/24","10.0.2.0/24","10.0.3.0/24","10.0.4.0/24"]`	no
s3_bucket_prefix	n/a	`string`	`"dolphinscheduler-test-"`	no
subnet_count	Number of subnets	`map(number)`	`{private=2, public=1}`	no
tags	Tags to apply to all resources	`map(string)`	`{Deployment="Test"}`	no
vm_associate_public_ip_address	Associate a public IP address to the EC2 instance	`map(bool)`	`{alert=true, api=true, master=true, standalone_server=true, worker=true}`	no
vm_data_volume_size	Data volume size of the EC2 Instance	`map(number)`	`{alert=10, api=10, master=10, standalone_server=10, worker=10}`	no
vm_data_volume_type	Data volume type of the EC2 Instance	`map(string)`	`{alert="gp2", api="gp2", master="gp2", standalone_server="gp2", worker="gp2"}`	no
vm_instance_type	EC2 instance type	`map(string)`	`{alert="t2.micro", api="t2.small", master="t2.medium", standalone_server="t2.small", worker="t2.medium"}`	no
vm_root_volume_size	Root Volume size of the EC2 Instance	`map(number)`	`{alert=30, api=30, master=30, standalone_server=30, worker=30}`	no
vm_root_volume_type	Root volume type of the EC2 Instance	`map(string)`	`{alert="gp2", api="gp2", master="gp2", standalone_server="gp2", worker="gp2"}`	no
vpc_cidr	CIDR for the VPC	`string`	`"10.0.0.0/16"`	no
zookeeper_connect_string	Zookeeper connect string, if empty, will create a single-node zookeeper for demonstration, don't use this in production	`string`	`""`	no

几个需要特别留意的参数：

aws_access_key / aws_secret_key / db_password必填，其余都有合理默认值，最小化改动即可运行；
ds_component_replicas是控制"集群 vs 单机"以及各组件扩缩容的核心参数，且由于实例用count创建，改小后terraform apply会直接销毁多余的实例；
zookeeper_connect_string为空时脚本会自动创建演示用单节点 ZooKeeper，官方注释明确警示生产环境必须显式提供连接串；
所有vm_*系列的map参数都按组件维度配置，可以为不同组件分配不同机型、磁盘大小和磁盘类型。

输出变量全表（Outputs）

terraform apply之后可用terraform output查看的资源属性（定义于 dolphinscheduler-output.tf、rds-output.tf、s3-outputs.tf、zookeeper-output.tf），每个实例类输出都是按 replica 数量的列表：

Name	Description
alert_server_instance_id	Instance IDs of alert instances
alert_server_instance_private_ip	Private IPs of alert instances
alert_server_instance_public_dns	Public domain names of alert instances
alert_server_instance_public_ip	Public IPs of alert instances
api_server_instance_id	Instance IDs of api instances
api_server_instance_private_ip	Private IPs of api instances
api_server_instance_public_dns	Public domain names of api instances
api_server_instance_public_ip	Public IPs of api instances
db_address	Database address
db_name	Database name
db_port	Database port
master_server_instance_id	Instance IDs of master instances
master_server_instance_private_ip	Private IPs of master instances
master_server_instance_public_dns	Public domain names of master instances
master_server_instance_public_ip	Public IPs of master instances
s3_access_key	S3 access key
s3_address	S3 address
s3_bucket	S3 bucket name
s3_regional_domain_name	S3 regional domain name
s3_secret	S3 access secret
vm_server_instance_id	Instance IDs of standalone instances
vm_server_instance_private_ip	Private IPs of standalone instances
vm_server_instance_public_dns	Public domain names of standalone instances
vm_server_instance_public_ip	Public IPs of standalone instances
worker_server_instance_id	Instance IDs of worker instances
worker_server_instance_private_ip	Private IPs of worker instances
worker_server_instance_public_dns	Public domain names of worker instances
worker_server_instance_public_ip	Public IPs of worker instances
zookeeper_server_instance_id	Instance IDs of zookeeper instances
zookeeper_server_instance_private_ip	Private IPs of zookeeper instances
zookeeper_server_instance_public_dns	Public domain names of zookeeper instances
zookeeper_server_instance_public_ip	Public IPs of zookeeper instances

这些输出可直接用于编写访问脚本、配置负载均衡或接入监控系统，例如本文打开 UI 的命令就是基于api_server_instance_public_dns构造的。

源码阅读指引：进一步定制

如果需要对这套 Terraform 方案做二次定制，建议从以下入口深入：

AMI 构建细节：ds-ami-official.pkr.hcl 与 ds-ami-local.pkr.hcl——修改基础操作系统、Java 版本或安装路径；
组件启动逻辑：templates/cloud-init.yaml——两个 systemd 单元定义了"先建 schema、再启服务"的依赖顺序，如需调整启动参数（如 JVM 内存、超时）改这里；
存储配置注入：templates/cloud-init.yaml——sed改写的正是 DolphinScheduler 的common.properties（资源存储类型、AWS 密钥、region、桶名、endpoint）；
组件安全组与实例规格：dolphinscheduler-master.tf、dolphinscheduler-worker.tf、dolphinscheduler-alert.tf、dolphinscheduler-api.tf、dolphinscheduler-standalone.tf；
依赖中间件：network-main.tf、rds-main.tf、s3-main.tf、zookeeper-main.tf。

需要注意的是，这套 Terraform 方案定位是"快速拉起一套可用的演示/测试环境"：RDS 使用db.t3.micro、ZooKeeper 为单节点 Docker 容器且安全组对公网开放了 SSH 与 UI 端口，因此在生产环境使用时应按实际规模调整实例规格、收紧安全组，并显式指定已有的 ZooKeeper 集群连接串。

小结

Apache DolphinScheduler 的 Terraform 部署方案把"AMI 构建 + 资源编排 + cloud-init 自动初始化"三层自动化串联起来：Packer 负责把发行包固化进 AMI，Terraform 负责网络、数据库、对象存储、注册中心与各组件实例的声明式管理，cloud-init 则负责在实例启动瞬间完成 schema 初始化、配置注入与服务拉起。掌握了ds-ami.pkrvars.hcl、terraform.tfvars两份变量文件，即可在几分钟内获得一套可访问 Web UI 的 standalone 或 cluster 模式的调度平台，并通过 Inputs/Outputs 表自由调整规模与机型。