终极套娃 2.0 | 云原生交付的封装

举报
开源小E 发表于 2022/07/11 15:27:48 2022/07/11
【摘要】 我总是喜欢一些比喻,这样可以让我们更加形象地认识事物。Erda 是一个 PaaS 平台,底层用到的技术曾经从 marathon + mesos 切换到现在的 K8s,它们一般被认为是“容器层”。Erda 在“容器层”之上又堆叠了 CI/CD Pipeline、集群和部署管理、应用监控、自动化测试等等能力,这样分层的体现非常像网络的分层,每一层各司其职,不过我更喜欢将其比喻为「编程语言」。封装...

我总是喜欢一些比喻,这样可以让我们更加形象地认识事物。


Erda 是一个 PaaS 平台,底层用到的技术曾经从 marathon + mesos 切换到现在的 K8s,它们一般被认为是“容器层”。Erda 在“容器层”之上又堆叠了 CI/CD Pipeline、集群和部署管理、应用监控、自动化测试等等能力,这样分层的体现非常像网络的分层,每一层各司其职,不过我更喜欢将其比喻为「编程语言」。


封装是为了减少“失误”


一门高阶编程语言拥有更符合人类理解的语法,其通过编译成汇编或者机器码来实现运行,或者是编译成低阶语言再进行二次编译。


与此类似,Erda 通过对“容器层”的封装,对我们的用户呈现了具有“Erda 理念”的功能设计和使用体验。而所谓封装最重要的就是减少人为的“失误”,就好像高阶语言通过受限和优雅的语法、智能的编译提示以及丰富的类库,大大减少开发者的心智负担,可以轻松地写出健壮的代码。而在其之上的程序设计方法、最佳实践,为高速交付实现提供理论支撑。


何为制品


Erda 的身骨是以「应用」为中心打造的,假设 Erda 只能剩下一个功能的话,那就是应用的“交付”。


交付可以非常简单,我称之为“两步走”:


  1. 将代码编译成应用安装包

  2. 在客户要求的环境中安装应用


实际的情况会稍显复杂,但不会改变这个核心的步骤,大抵是多几步的问题。


如果要追究细节的话,这两步可以一直向下展开。Erda 做的事情就是让使用者无须深究这些细节,就像我们使用个人电脑观看视频时无须知道编码、传输和解码的过程,也无须知道有损和无损的区别。

当然,做这样的比喻不代表 Erda 有意阻拦用户进行深入探究,相反若懂得底层原理,更能够加深对 Erda 功能设计的理解!


具体而言,Erda 规范了可在云上交付的“软件安装包”格式,这样的安装包我们称之为“Erda 制品”(下文称之为“制品”),我们简单罗列一下制品的特性,这样大家可以有一个总体的印象:


  1. 制品是对 docker 镜像的进一步抽象,类似 docker-compose.yml,涵盖了多个镜像(服务)的总体描述,以及互相之间的依赖关系
  2. 制品是对应用交付环境的声明(结构化、可被系统识别的软件安装部署说明书),不仅声明每个镜像服务的资源限制,也能够声明所需要的中间件(比如 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-project/erda/blob/master/erda.yml


在这个例子中(也就是 Erda 自身的应用制品),大家可以充分感受到 Erda 是如何将“软件交付”进行封装的。


得益于 docker 对“执行环境”的封装,再组合上 dice.yml 对微服务/多应用整体“交付环境”的封装(实例个数、环境变量、资源消耗、中间件依赖),我们可以很自信地说:“开发者只需要关心其必要知晓的,其他由平台代为负责”。


交付制品


虽然刚介绍完制品的来龙去脉,我们仍想再回顾一下制品的关键组成部分:


  1. 镜像列表(docker images)
  2. 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 繁舟聚汇,不终不止

商品已经以 License 方式上架云市场,华为云商品链接:https://marketplace.huaweicloud.com/contents/a1210d06-82af-4552-915d-d3d9d10a13ea

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200