入坑不亏！我们最终决定将 70w+ 核心代码全部开源

作者 ｜ 一啸

来源 ｜ 尔达 Erda 公众号

背景故事

2017 年初，我们基于 DC/OS (mesos + marathon) 开始构建端点自己的 PaaS 平台，核心任务就是解决公司的软件开发和部署交付效率问题，建设公司的研发效能(DevOps)、智能监控运维(APM、Monitoring) 等技术平台。

​

其实 DC/OS 还是很好用的：

​

• 首先，它集大成了一个完整的容器平台，不需要过于关注各个细节模块，比如网络。
• 其次，它在多服务的一键编排部署方面也是非常方便的，现在 K8s 主要还是依赖 Helm 来实现，但 DC/OS 存在的最大问题就是用户数仍太少，问题出现后，需要自行探索解决问题。（估计我们团队是国内 DC/OS 运维最专业的团队之一，分母不大于 3。）

这里讲述一件让我们团队记忆非常深刻的故事：2018 年夏天的一个周六，我们到公司加班，准备保障业务团队的发布，结果公司的整个 DC/OS 的网络都挂了！！原本，我们计划保障完业务的发布就去聚餐吃饭，结果被硬生生折腾了一个通宵。

​

这天夜里，我们尝试了所有能找到的方法和建议，把所有能做的事情都做了，结果还是没有用，仍然没有办法恢复网络。最终，我们决定清理掉整个集群的网络元数据，重建网络，事情才被真正解决（事实上，摸索出 “清理所有元数据，重建网络” 这个方法就花了很长时间）。

​

好了，现在拉回正题。基于 DC/OS 的 PaaS 在 2018 年 4 月完成了第一个正式客户的生产部署后，又陆续交付生产了好几个客户。就这样，我们一路磕磕跘跘地走完 2018 年，在 2019 年就决定要开始转型到 K8s 了。

Erda 的发展之路

在架构设计 PaaS 平台的第一天，就决定要把底层的容器平台 (DC/OS) 给抽象屏蔽掉，所以我们采用了 infrastructure as code 的理念定义了一个 dice.yaml 的规范 (dice 是 PaaS 平台的名字) ，dice.yaml 规范的核心就是：“以应用为中心，以开发者为中心”去定义、使用基础设施资源等。“以应用为中心” 其实并不是什么新概念，Heroku 早已提出并实践，我们只是把这个概念做得更极致了些，当然，Heroku 的基础架构并不算先进，甚至有点落后。

“以应用为中心，以开发者为中心” 对于端点来说是非常重要的，我们一定要让业务开发的同学只关注业务本身，不用去理解：容器是什么？K8s Deployment、Statefulset、Service、 Ingress、Pod 等这些东西是什么？更不需要关心应用跑在一个什么样的网络上？也不用关注应用的监控接入、监控覆盖、诊断分析这些事情。其实，这对绝大多数企业来讲都是非常重要的。

​

“抽象、屏蔽掉底层的容器平台“ 这个设计除了给业务开发降低了极大的门槛，同时也给我们团队自身带来了很大的便利。主要体现在转型 K8s 的时候，只需要针对性的开发一个 K8s 插件就完成了（不是给 K8s 开发插件，是给我们 PaaS 平台开发插件）。其实，在支持 K8s 之前，我们还和阿里云的 EDAS 合作开发了 EDAS 插件，支持将应用部署到 EDAS 上，On EDAS 这个模式也陆陆续续地交付了好几个客户。我们将容器平台插件化后，对接 Openshift/Rancher 等也是一件非常容易的事情，这对很多企业私有云环境是非常友好的。

​

从支持自建 K8s，再到支持阿里云容器服务、然后又是 AWS、Azure 等，我们一路支持的客户越来越多。我们发现：如今，在公有云上要从 0 创建一个企业的 IT 环境（测试、生产）还是要做非常多的事情，并且还需要具备非常专业的技能知识， 比如需要涉及 ECS、网络、存储、数据库、SLB、中间件、容器服务、安全等等。在我们的部分客户中，上述从 0 创建云环境的事情都是由我们帮客户完成的。所以，我们需要提效，需要将这些麻烦的事情给自动化掉，于是就基于 terraform 开发了整个自动化流程。作为一个产品型团队，我们做任何事情都会想着产品化，一开始就将 terraform 自动化的云资源编排流程做到云管平台产品里了。

​

越往后走，我们开发的功能越来越多，平台覆盖的范围也越来越大，后续又支持了边缘计算管理、快数据平台、移动开发等。这些功能的原始诉求都来自于端点的真实场景，比如 pos 应用就是一个边缘场景。

​

4 年走来，让我们感到最欣慰的事情，并不是做了多少产品功能，而是从 2018 年中开始，我们就坚持每月发布一个版本，并且给所有客户升级到最新版，从来没有出现过代码分叉维护，包括前面提到从 DC/OS 转到 K8s 的大迁移、大升级（这是我个人心里觉得做得很牛的一件事情）。时至今日，我们的平台已经管理了上百个 K8s 集群的应用，我们的目标之一就是 “成为管理最大规模 K8s 应用的平台”。

我们为什么要开源？

2021 年初（春节前），我们在思考 21 年规划时，才开始意识到自己做了很多事情，开发了一个很强大的产品，我们在产品开发这条路上走得很扎实、很专注，完全忽略了分享给更多的人、回馈社区、建设影响力等重要的事情。

​

所以，在春节后，我们团队全力投入将整个平台完全开源。做开源这件事情，我们想得很清楚，要做就是全部开源，不留所谓的高级功能（私货），不留内部代码分支，整个团队的日常迭代开发全部转移到 GitHub 上执行。我们希望做一个长期主义者，用 3 年、5 年，甚至更长的时间持续建设一个足够好的开源社区，打造一个顶级的开源项目。

​

放眼全球，我们可以找到非常多的优秀开源项目，但大多数开源项目都是以工具属性为主，比如：前端 js 库、开发框架、基础服务器软件等，直接开源产品（或者称之为商品）的项目却不多，我个人认为开源产品逐渐会成为这个领域的新趋势，社会肯定朝着更高效、低成本的方向去演进，基础工具或技术将会是真正的基础设施 ，对大多数人来说都不用过于关注它；面向用户群，解决大多数用户的直接问题（第一问题）才是社会价值的最大化。

​

直接开源产品也给我们带了新的麻烦，我们希望、也欢迎大家免费使用开源的产品，但肯定不希望某一个公司或组织直接将我们的开源产品进行二次销售（含服务），所以我们决定先采用 AGPLv3 协议进行开源。采用 AGPLv3 的出发点不是为了限制个人、企业自己内部使用，仅仅是防止软件或服务再销售。

​

4 年来我们的 PaaS 平台一直叫 Dice，目前已经做到了 4.0 版本，所以我们非常纠结在开源社区的第一个版本是 4.0 还是 1.0，如果是 4.0 对社区来讲看上去会非常奇怪。最终，我们为了和公司所有的产品命名保持一致，把 Dice 改名成 Erda。Erda 是《基地》小说中地球的别名，Terminus (端点)、Erda、Trantor、Gaia 等都是源自于这部小说中的星球名称。完成改名后，新名字新起点，所以开源社区从 1.0 版本开始发布，也就显得很自然了。

​



Erda 开源项目有一个小小的愿景：“能够在 Erda 平台上构建任何类型的应用，持续提升应用研发效能；能够将应用部署、分发到任何云、任何地方；能以应用为中心持续完成应用的监控、诊断、治理”。

​

尔达 Erda 公众号快速玩转指南

Erda 作为开源的一站式云原生 PaaS 平台，旨在为开发者提供稳定可靠、功能全面、兼容生态、开源开放的云原生 PaaS 平台和最佳实践，也希望能够和广大开发者不断交流，共同进步，而这也正是我们开创【尔达 Erda】公众号的初衷：为广大开发者提供一个技术交流聚集点。

​

在这里，除了可以自由分享观点外，你还可以定期看到我们准备的以下内容：

​

• 产品动态
  • 技术最新进展
  • 行业趋势分析
  • 技术解读
  • 最佳实践
• 技术分享
  • 相关技术解读
  • 行业大会现场演讲图文回顾
• 活动分享
  • 活动动态
  • 技术直播发布
• ······

如果你有其它想要了解的内容，也欢迎到公众号后台留言，或者添加小助手微信（Erda202106）加入交流群！

欢迎参与开源

四年风雨，终归要历遍山河。

​

Erda 作为开源的一站式云原生 PaaS 平台，具备 DevOps、微服务观测治理、多云管理以及快数据治理等平台级能力。点击下方链接即可参与开源，和众多开发者一起探讨、交流，共建开源社区。欢迎大家关注、贡献代码和 Star！

• Erda Github 地址：https://github.com/erda-project/erda
• Erda Cloud 官网：https://www.erda.cloud/