使用 Apache DolphinScheduler 构建和部署大数据平台，将任务提交至 AWS 的实践经验

作者介绍

李庆旺 - 软件开发工程师，思科

引言

大家好，我是李庆旺，来自思科的软件开发工程师。我们的团队已经使用Apache DolphinScheduler搭建我们自己的大数据调度平台近三年时间。从最初的2.0.3版本开始至今，我们与社区一同成长，今天给大家分享的技术思路是基于3.1.1版本进行的二次开发，增加了一些社区版本中未包含的新功能。

今天，我将分享我们如何使用Apache DolphinScheduler构建大数据平台，将我们的任务提交部署到AWS上，期间遇到的一些挑战和我们的解决方案。

架构设计与调整

初始我们所有的服务均部署在Kubernetes（K8s）上，包括API、Alert、以及Zookeeper（ZK）、Master和Worker等组件。

大数据处理任务

我们对Spark、ETL和Flink等任务进行了二次开发：

• ETL任务：我们团队开发了一种简单的拖拉拽形式的工具，用户可以通过这种方式快速生成ETL任务。
• Spark支持：早期版本仅支持在Yarn上运行的Spark，我们通过二次开发使其支持在K8s上运行。目前社区的最新版本已支持Spark on K8s。
• *Flink 二次开发: 同样，我们新增了Flink On K8s的流任务，同时还有SQL任务和Python任务On K8s的支持。

支持Job上AWS

随着业务的扩展和数据政策的需求，我们面临必须在不同地区运行数据任务的挑战。这需要我们构建一个能够支持多集群的架构。以下是我们的解决方案和实施过程的详细描述。

我们的当前架构包括一个集中控制终端，即一份单一的Apache DolphinScheduler服务，它负责管理多个集群。这些集群分布在不同的地理位置，例如欧盟和美国，以遵守当地的数据政策和隔离需求。

架构调整

为了满足这一需求，我们进行了如下调整：

• 保持Apache DolphinScheduler服务的集中管理：我们的DolphinScheduler服务仍然部署在自建的Cisco Webex DC中，保持了管理的集中性和一致性。
• 支持AWS EKS集群：同时，我们扩展了架构的能力，以支持多个AWS EKS集群。这样，可以满足任务运行在EKS集群上的新业务需求，而不影响其他Webex DC集群的运行和数据隔离。

通过这种设计，我们能够在保证数据隔离和政策遵守的同时，灵活应对不同的业务需求和技术挑战。

接下来介绍下如何处理Apache DolphinScheduler在Cisco Webex DC中运行任务时的技术实现和资源依赖。

资源依赖和存储

由于我们所有的任务都在Kubernetes（K8s）上运行，对我们来说，以下几点是至关重要的：

Docker 镜像

• 存储位置：之前，我们所有Docker镜像都存储在Cisco的一个Docker仓库中。
• 镜像管理：这些镜像为我们运行的各种服务和任务提供了必要的运行环境和依赖。

资源文件和依赖

• Jar包和配置文件等：我们使用Amazon S3 Bucket作为资源存储中心，存储用户的 Jar包和可能的依赖配置文件。
• 安全性资源管理：包括数据库密码、Kafka的加密信息和用户依赖的密钥等，这些敏感信息都存储在Cisco的Vault服务中。

安全访问和权限管理

对于访问S3 Bucket这一需求，我们需要配置和管理AWS凭证：

IAM 账户配置

• 凭证管理：我们使用IAM账户来管理对AWS资源的访问权限，包括访问密钥（Access Keys）和秘密密钥（Secret Keys）。
• K8s集成：这些凭证信息被存储在Kubernetes的Secret中，由Api-Service引用，从而安全地访问S3 Bucket。
• 权限控制和资源隔离：通过IAM账户，我们可以实现精细的权限控制，确保数据安全和业务的合规性。

IAM账户访问密钥的过期问题及对策

在使用IAM账户管理AWS资源的过程中，我们面临着访问密钥过期的问题。这里详细介绍我们如何应对这一挑战。

访问密钥过期问题

• 密钥周期：IAM账户的AWS密钥通常设置为每90天自动过期，这是为了增强系统的安全性。
• 任务影响：一旦密钥过期，所有依赖这些密钥访问AWS资源的任务都将无法执行，这需要我们及时更新密钥以保持业务的连续性。

针对这种情况，我们给任务设置了定期重启，同时设置了对应的监控，如果 AWS 的账号在未到过期时间之内出现了问题，那么就需要通知到我们相应的开发人员，去做一些处理。

支持 AWS EKS

随着业务扩展到AWS EKS，我们需要对现有架构和安全措施进行一系列调整。

比如像刚才说的 Docker image，我们之前是放到 Cisco 自己的 Docker repo 里，那现在就需要把 Docker image 放到 ECR 上。

多个 S3 Bucket 的支持

由于AWS集群的分散性和不同业务的数据隔离需求，我们需要支持多个S3 Bucket来满足不同集群的数据存储需求：

• 集群与Bucket的对应：每个集群将访问其对应的S3 Bucket，以确保数据的局部性和合规性。
• 修改策略：我们需要调整我们的存储访问策略，以支持从多个S3 Bucket读写数据，不同的业务方要访问自己对应的 S3 bucket。

密码管理工具的变更

为了提高安全性，我们从Cisco的自建Vault服务迁移到了AWS的Secrets Manager（ASM）：

• ASM的使用：ASM提供了一个更加集成的解决方案来管理AWS资源的密码和密钥。

我们采取了使用IAM Role和Service Account的方式，以增强Pod的安全性：

• 创建IAM Role和Policy：首先创建一个IAM Role，为其绑定必要的Policy，确保只有必要的权限被授予。
• 绑定K8s Service Account：随后创建一个Kubernetes Service Account，并将其与IAM Role关联。
• Pod的权限集成：在运行Pod时，通过关联到Service Account，Pod可以直接通过IAM Role获取所需的AWS凭证，从而访问必要的AWS资源。

这些调整不仅提升了我们系统的可扩展性和灵活性，还加强了整体的安全架构，确保在AWS环境中的运行既高效又安全。同时也避免了之前密钥自动过期需要重启的问题。

优化资源管理与存储流程

为了简化部署流程，我们计划直接将Docker镜像推送到ECR，而不是通过二次中转：

• 直接推送：修改当前的打包流程，使Docker镜像在构建后直接推送到ECR，减少时间延迟和潜在的错误点。

改动实施

• 代码级调整：我们在DolphinScheduler的代码中进行了修改，使其能够支持多个S3 Client，增加了对多个S3Client的缓存管理，。
• 资源管理UI调整：允许用户通过界面选择不同的AWS Bucket名称进行操作。
• 资源访问：修改后的Apache DolphinScheduler服务现在可以访问多个S3 Bucket，允许在不同的AWS集群之间灵活管理数据。

AWS资源的管理和权限隔离

集成AWS Secrets Manager（ASM）

我们对Apache DolphinScheduler进行了扩展，以支持AWS Secrets Manager，使得用户可以在不同的集群类型中选择密钥：

ASM的功能集成

• 用户界面改进：在DolphinScheduler的用户界面中，增加了对不同secret类型的展示和选择功能。
• 自动密钥管理：运行时将保存了用户选定的secret的文件路径映射到实际的Pod环境变量中，确保了密钥的安全使用。

动态资源配置和初始化服务（Init Container）

为了更灵活地管理和初始化AWS资源，我们实施了一个名为Init Container的服务：

• 资源拉取：Init Container在Pod执行前，会自动拉取用户配置的S3资源，并将其放置到指定目录下。
• 密钥和配置管理：根据配置，Init Container会检查并拉取ASM中的密码信息，随后将其存放在文件中，并通过环境变量映射，供Pod使用。

Terraform在资源创建和管理中的应用

我们通过Terraform自动化了AWS资源的配置和管理过程，简化了资源分配和权限设定：

• 资源自动化配置：使用Terraform创建所需的AWS资源，如S3 Bucket和ECR Repo。
• IAM策略和角色管理：自动创建IAM策略和角色，确保每个业务单元可以按需访问其所需的资源。

权限隔离和安全性

我们通过精细的权限隔离策略，确保不同业务单元在独立的Namespace中操作，避免了资源访问冲突和安全风险：

实施细节

• Service Account的创建和绑定：为每个业务单元创建独立的Service Account，并将其与IAM角色绑定。
• Namespace隔离：每个Service Account操作在指定的namespace内，通过IAM角色访问其对应的AWS资源。

集群支持与权限控制的改进

集群类型的扩展

我们增加了一个新的字段 cluster type，以支持不同类型的K8S集群，这不仅包括标准的Webex DC集群和AWS EKS集群，还可以支持具有更高安全要求的特定集群：

集群类型管理

• 集群类型字段：通过引入cluster type字段，我们可以轻松地管理和扩展对不同K8S集群的支持。
• 代码级别的定制：针对特定集群的独特需求，我们可以进行代码级别的修改，以确保在这些集群上运行job时能够满足其安全和配置要求。

增强的权限控制系统（Auth系统）

我们开发了Auth系统，专门用于细粒度的权限控制，包括project、resource和namespace间的权限管理：

权限管理功能

• 项目和资源权限：用户可以通过项目维度控制权限，一旦拥有项目权限，即拥有该项目下所有资源的访问权。
• namespace权限控制：确保特定团队只能在指定的namespace中运行其项目的job，从而保证运行资源隔离。

比如说 A team，那么它的 A namespace 上面只能运行某一些 project job，那么比如说像 B 用户，他就不能去在 A 用户的那些 namespace 上面去运行job。

AWS资源的管理和权限申请

我们通过Auth系统和其他工具，管理AWS资源的权限和访问控制，使得资源分配更加灵活和安全：

• 多AWS Account支持：在Auth系统中可以管理多个AWS账户，并绑定不同的AWS资源如S3 Bucket、ECR和ASM等。
• 资源映射和权限申请：用户可以在系统中对已有的AWS资源进行映射和权限申请，这样在运行job时可以轻松地选择需要访问的资源。

Service Account的管理和权限绑定

为了更好地管理服务账户和其权限，我们实现了以下功能：

Service Account的绑定和管理

• Service Account唯一区分：通过特定的集群、namespace和项目名称绑定Service Account，确保其唯一性。
• 权限绑定界面：用户可以在界面上将Service Account绑定到具体的AWS资源，如S3、ASM或ECR，从而实现权限的精确控制。

简化操作和资源同步

刚才说了很多，但实际对于用户来说操作其实比较简单，整个申请的流程那些都其实都是一次性的工作，为了进一步提高Apache DolphinScheduler在AWS环境中的用户体验，我们采取了一系列措施来简化操作流程和增强资源同步功能。

给大家总结一下：

简化的用户操作界面

在DolphinScheduler中，用户可以轻松配置其作业运行的具体集群和namespace：

集群和namespace选择

• 集群选择：用户在提交作业时，可以选择希望作业运行的集群。
• namespace配置：根据选择的集群，用户还需要指定作业运行的namespace。

Service Account和资源选择

• Service Account展示：页面将根据选定的项目、集群和namespace自动展示相应的 Service Account。
• 资源访问配置：用户可以通过下拉列表选择与服务账户关联的S3 Bucket、ECR地址和ASM秘钥。

未来展望

针对于现在的设计，还有一些地方可以优化改进可以提升用户提交和方便运维：

• 镜像推送优化：考虑跳过Cisco的中转打包流程，直接将包推送至ECR，尤其是针对特定于EKS的镜像修改。
• 一键同步功能：我们计划开发一键同步功能，允许用户将一个上传到S3 Bucket的资源包，勾选自动同步到其他S3 Bucket，减少重复上传的工作。
• 自动映射至Auth系统：Aws资源通过Terraform创建后，系统将自动将这些资源映射到权限管理系统中，避免用户手动进行资源录入。
• 权限控制优化：通过自动化的资源和权限管理，用户的操作变得更加简洁，减少了设置和管理的复杂性。

通过这些改进，我们期望能够帮助用户使用Apache DolphinScheduler更有效地部署和管理他们的作业，无论是在Webex DC还是在EKS上，同时提高资源管理的效率和安全性。

本文由 白鲸开源科技 提供发布支持！