关于云原生:终极套娃-20-云原生交付的封装

28次阅读

共计 2898 个字符，预计需要花费 8 分钟才能阅读完成。

我总是喜爱一些比喻，这样能够让咱们更加形象地意识事物。

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 的我的项目制品
通过分组蕴含了多个利用制品（erda、erda-ui 等）

制品的 Addons 详情
其中 rds 和 MySQL 能够互为替换

咱们聚焦一下 Erda 主利用的制品外部，也就是分组 Group 3 中的 erda 主库的利用制品。

因为 Erda 主利用是微服务架构（多服务），所以咱们能看到一串微服务容器列表：

利用如果有多服务
每个服务都有 docker image

以及最外围的 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，能够在开源代码中找到：
https://github.com/erda-proje…

在这个例子中（也就是 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 繁舟聚汇，不终不止。

正文完