面向多场景而设计的 Erda Pipeline

作者｜林俊（万念）
来源｜尔达 Erda 公众号

Erda Pipeline 是端点自研、用 Go 编写的一款企业级流水线服务。截至目前，已经为众多行业头部客户提供交付和稳定的服务。

为什么我们坚持自研，而不用 jenkins 等产品呢？在当时，至少有以下几点理由：

• 时至今日，开源社区仍没有一个事实上的流水线标准
• K8s、DC/OS 等的 Job 实现都偏弱，上下文传递等缺失，不满足我们的需求，更不要说 Flow 了
• 自研能更快地响应业务需求，进行定制化开发

作为基础服务，Pipeline 在 Erda 内部支撑了 CI/CD、快数据平台、自动化测试平台、SRE 运维链路等产品化场景。本文就从几个方面来介绍一下 Pipeline。

为什么会有 Pipeline

这就需要从应用构建开始说起。Pipeline 的前身是 Packer 和 CI。

Packer

Erda 最开始是端点内部使用的 PaaS 平台。从 2017 年开始，Erda 就管理了公司所有的研发项目。项目下每个应用都逃不开 代码 -> 编译 -> 镜像制作 -> 部署 的标准流程。这个时候我们开发了 Packer，顾名思义，它是一个专门负责 打包 的组件。用户需要提供 Dockerfile，这在当时还是有着较高学习成本的。

CI

随着 CI/CD（持续集成、持续交付）概念的深入人心，我们也推出了 Packer 的升级版 CI 。同时，基础设施即代码（IaC）的理念也在这里得到了实践：通过 erda.yaml 1.0 语法同时声明应用的微服务架构和构建过程。

在用户体验上，我们不再直接暴露 Dockerfile，而是把最佳实践以 BuildPack 大礼包的方式给到使用者，使用者甚至不需要声明应用的开发语言和构建方式，就可以通过 BuildPack 的自动探测和识别，完成 CI/CD 流程。

受限于单容器的运行方式，当时我们也遇到了一些问题，譬如把 CI 构建过程自定义能力开放、构建环境多版本问题等，这些问题在 Pipeline 里都迎刃而解。

Pipeline

今天回过头来看，从 CI 升级到 Pipeline 是一个很自然的过程：因为 CI/CD 本身就是一个很标准的流程，我们完全可以抽象出一个更通用的流程引擎，这就是 Pipeline。CI/CD 成为了 Pipeline 最开始支撑的场景。

在设计之初，我们就做了以下改进：

• 对外：通过清晰易用的 pipeline.yaml 语法，降低使用者的上手成本。
• 对内：抽象出任务定义，配合 ActionExecutor Plugin Mechenism（任务执行器插件机制），很方便地对接各个单任务执行平台，譬如 DC/OS Metronome、K8s Job、Flink/Spark Job 等。
• 由 Pipeline 提供一致、强大的流程编排能力。

Pipeline 功能特性

Pipeline 有许多灵活、强大的功能，譬如：

• 配置即代码，通过 pipeline.yaml 语法描述流程，基于 Stage 语法简化编排复杂度。
• 丰富的扩展市场，平台内置超过百款开箱即用的 Action，满足大部分日常场景；同时可轻松扩展你自己的 Action。
• 可视化编辑，通过图形界面交互快速配置流水线。
• 支持嵌套流水线，在流水线级别进行复用，组合出更强大的流水线。
• 灵活的执行策略，包括串并行、循环、分支策略、超时、人工确认等。
• 支持工作流优先队列，优先级可实时调整，保证高优先级流水线优先执行。
• 多维度的重试机制，支持断点重试、全流程重试。
• 定时流水线，同时提供强大的定时补偿功能。
• 动态配置，支持 值 和 文件 两种类型，均支持加密存储，确保数据安全性。
• 上下文传递，后置任务可以引用前置任务的 值 和 文件。
• 开放的 OpenAPI 接口，方便第三方系统快速接入。
• ······

Pipeline 架构

如上图所示，Pipeline 支持 UI / OPENAPI / CLI 多种方式进行交互。

Pipeline 本身支持水平扩展，保证高可用，还可以将其划分为：服务层、核心层和引擎层。下面我们详细介绍一下。

服务层

• yaml parser 解析流程定义文件，支持灵活的变量语法。例如上下文值引用：${ { outputs.preTaskName.key }}；配置管理引用：${ { configs.key }} 等。
• 对接扩展市场获取扩展能力。

核心层

• Cron 守护进程。
• EventManager 抽象内部事件发送，使用适配器模式解耦监控指标上报、发送 ws 消息、支持 webhook 等。
• AOP 扩展点机制（借鉴 Spring），把代码关键节点进行暴露，方便开发同学在不修改核心代码的前提下定制流水线行为。这个能力后续我们还会开放给调用方，包括用户，支持他们去做一些有意思的事情。

目前许多有意思的功能都是通过扩展点机制实现的，譬如自动化测试报告嵌套生成、队列弹出前检查、接口测试 Cookie 保持等：

引擎层

引擎层包括：

• 流程推进器（Reconciler）
• 优先队列管理器
• 任务执行器插件机制

具体内容在下一节会展开讲解。

中间件依赖

我们尽可能做到简化中间件依赖，使部署更简单。

• 使用 MySQL 做数据持久化。
• 使用 etcd watch 功能实现多实例状态同步以及分布式锁。
• 使用 etcd key ttl 实现数据 defer GC。