我总是喜爱一些比喻，这样可以让咱们更加形象地知道事物。
Erda 是一个 PaaS 渠道，底层用到的技能从前从 marathon + mesos 切换到现在的 K8s，它们一般被认为是“容器层”。Erda 在“容器层”之上又堆叠了 CI/CD Pipeline、集群和布置办理、运用监控、自动化测验等等才能，这样分层的表现十分像网络的分层，每一层各司其职，不过我更喜爱将其比喻为「编程言语」。
封装是为了削减“失误”
一门高阶编程言语具有更契合人类了解的语法，其经过编译成汇编或许机器码来完成运转，或许是编译成低阶言语再进行二次编译。
与此类似，Erda 经过对“容器层”的封装，对咱们的用户呈现了具有“Erda 理念”的功用设计和运用体会。而所谓封装最重要的便是削减人为的“失误”，就好像高阶言语经过受限和高雅的语法、智能的编译提示以及丰富的类库，大大削减开发者的心智担负，可以轻松地写出强健的代码。而在其之上的程序设计办法、最佳实践，为高速交给完成提供理论支撑。
何为制品
Erda 的身骨是以「运用」为中心打造的，假设 Erda 只能剩下一个功用的话，那便是运用的“交给”。
交给可以十分简略，我称之为**“两步走”**：
- 将代码编译成运用安装包
- 在客户要求的环境中安装运用
实践的情况会稍显杂乱，但不会改变这个中心的进程，大略是多几步的问题。
假如要追究细节的话，这两步可以一直向下打开。Erda 做的工作便是让运用者无须深究这些细节，就像咱们运用个人电脑观看视频时无须知道编码、传输和解码的进程，也无须知道有损和无损的区别。
当然，做这样的比喻不代表 Erda 有意阻拦用户进行深化探求，相反若懂得底层原理，更可以加深对 Erda 功用设计的了解！
具体而言，Erda 标准了可在云上交给的“软件安装包”格局，这样的安装包咱们称之为**“Erda 制品”**（下文称之为“制品”），咱们简略罗列一下制品的特性，这样咱们可以有一个整体的形象：
- 制品是对 docker 镜像的进一步抽象，类似 docker-compose.yml，涵盖了多个镜像（服务）的整体描绘，以及互相之间的依靠联系
- 制品是对运用交给环境的声明（结构化、可被系统辨认的软件安装布置说明书），不只声明每个镜像服务的资源限制，也可以声明所需求的中间件（比方 mysql）
需求补充一下，因为 Erda 是一个多运用架构（中心的主库 erda、前端运用 erda-ui、监控相关的 telegraf、fluentbit 等），所以 Erda 交给的时候是多个运用一起交给，咱们称之为项目制品。项目制品在包含多个运用制品的一起还支撑分批布置等特性。
这是 Erda 自己的制品（项目制品）：
咱们聚焦一下 Erda 主运用的制品内部，也便是分组 Group 3 中的 erda 主库的运用制品。
因为 Erda 主运用是微服务架构（多服务），所以咱们能看到一串微服务容器列表：
以及最中心的 dice.yml：
version: "2.0"
envs:
ETCDCTL_API: "3"
services:
cluster-agent:
cmd: /app/cluster-agent
deployments:
replicas: 1
envs:
DEBUG: "false"
resources:
cpu: ${request_cpu:1}
max_cpu: 1
max_mem: 1024
mem: ${request_mem:1024}
addons:
mysql:
plan: mysql:basic
为了便利阅览咱们只列出了关键的信息，假如咱们需求看到完整的 dice.yml，可以在开源代码中找到：
github.com/erda-projec…
在这个例子中（也便是 Erda 自身的运用制品），咱们可以充分感受到 Erda 是怎么将“软件交给”进行封装的。
得益于 docker 对“执行环境”的封装，再组合上 dice.yml 对微服务/多运用整体“交给环境”的封装（实例个数、环境变量、资源消耗、中间件依靠），咱们可以很自傲地说：“开发者只需求关怀其必要知晓的，其他由渠道代为负责”。
交给制品
虽然刚介绍完制品的来龙去脉，咱们仍想再回忆一下制品的关键组成部分：
- 镜像列表（docker images）
-
dice.yml声明晰各个服务（镜像列表所对应的）布置所需的资源，以及需求的中间件
镜像（docker）的常识咱们暂且按下，“开发者只需求关怀其必要知晓的”且只要 dice.yml 的语法标准和装备了。
了解 Erda 的完成，可以知道渠道在布置制品时，读取 dice.yml 内容，并终究转换成“容器层”认知的结构（假如是 K8s 则是 Deployment、Service、Ingress，以及 StatefulSet 或许 Operator），从而交由“容器层”发挥布置动作。熟悉 K8s 会知道，假如让用户手艺编写这些装备，需求了解许多本不必知晓的常识（大多是运维相关），而且简单犯错。
PS：不过针对 Addons（或许说中间件）的布置机制相对杂乱，考虑到比方 Rds 等云厂商提供的外部才能，Erda 独自提供了一套布置和扩展才能
就像开篇讲的，dice.yml 似乎是一门“高阶言语”，而 K8s yml 则是“低阶言语”（咱们这里所指高阶和低阶，并非认为“高阶”一定是“优异”和“正确”的，而是指相对于便利人类认知而言，是更倾向于易于了解和防止犯错的，而且恰恰是“低阶”在性能、灵敏度、操控力以及正确逻辑方面是更有优势的），Erda 经过一次杂乱的“编译”，将用户（咱们无妨说事务研制人员）更简单了解的装备和声明格局或许语法，转变成实践布置的工作负载（Workload）和内生亦或外部的服务（Addons）。
聊了这么多，很简单就能得出 Erda 是怎么交给制品的定论：一键布置。
只需求选择制品，就可以一键创立布置单，等待结果即可
当然真实的出产环境布置相对杂乱，但不会改变中心的一键布置流程。Erda 在此之外打开了十分多额定的流程和功用：比方制品可以导出和导入，咱们一起也开发了 Gallery（集市）便利制品的传播（Gallery 一起也承载了 Addons 以及 Pipeline 的 Action）；制品也内置了 migration 的才能，可以在布置的进程中进行数据搬迁；等等。
当然最重要的是 Pipeline 也便是流水线的才能，经过其编排的中心 CI/CD 逻辑：“代码 -> 制品 -> 布置”，可以从流程上操控出产环境（也包含测验或许其他环境）的准入，Pipeline 的 Action 扩展机制为便利对接外部流程节点提供或许，当然 Erda 内置提供了十分多开箱即用的才能诸如质量扫描、单元测验、自动化测验等等。
最终
本文仅仅从一个很小的侧面：制品，讲述了 Erda 怎么交给自身，也包含怎么交给各个其他软件，但“制品”又是在 Erda 中最为重要最为中心的概念，也可以说是 Erda 至此不变的“理念”。这是 Erda 的起点、原点，此前 Erda 未有身骨，仅仅内部无名的打包布置渠道；尔后 Erda 繁舟聚汇，不终不止。
