云原生时代的DevOps平台设计之道( 三 )


那么 DevOps 工程师就有必要考虑,如何在开发人员对容器技术一无所知的情况下,使之可以直接从代码开始部署业务系统 。
在这个方面,Heroku 是无可争议的先行者 。Heroku 是一个支持多种编程语言的云平台即服务产品 。在2010年被 Salesforce.com 收购 。Heroku 作为最元祖的云平台之一,从2007年6月起开发,当时它仅支持 Ruby,但后来增加了对 Java、Node.js、Scala、Clojure、Python 以及 PHP 和 Perl 的支持 。
开发人员在使用云原生平台时,只需要在界面中填写代码仓库的地址,对应的用户名密码等基础信息,就可以等待代码构建成为镜像,并自由的运行在 Kubernetes 云环境中去 。
现有开源产品也在这方面给予了一定的支持:
RancherKubeSphereRainbond实现方式通过集成 Epinio 项目,继而深入集成了Paketo Buildpacks 来实现源码构建提供定制化的基础镜像来结合用户代码构建项目基于 Heroku buildpack 定制的源码构建能力支持语言类型Java、GraalVM、Golang、.NetCore、Nodejs、PHP、Ruby、PythonJava、Nodejs、PythonJava、Golang、.NetCore、Nodejs、PHP、Python、Html静态使用体验全部命令行操作,使用复杂图形化操作,直接提供代码地址,构建产出镜像,进而部署业务图形化操作,提供代码地址即可完成构建与部署,构建参数可配置,自由度高更进一步的设计,是将代码的提交、检测、部署等流程都集成到 CI/CD 流水线中去,开发人员只需要进行代码的提交,后续的流程会自动触发完成,生成检测报告,并完成代码的上线部署 。而与之相关的第三方工具集,由 DevOps 团队负责进行维护,开发人员可以充分的发扬拿来主义——拿来用就好 。
在这方面 KubeSphere 做的更加全面,通过集成 Jenkins 实现了基于图形化的流水线配置,这种方式对于以前就在使用 Jenkins 的团队很友好 。并且这种实现继承了 Jenkins 生态原有的高自由度,可以更好的将其他第三方CI工具纳入流程之中 。
Rainbond 通过在构建流程中加入自制的自动触发能力,也可以完成部分流水线工作 。这种配置相对编写 Jenkinsfile 来说更简单一些,能够满足一些基本场景 。然而其扩展性和自由度不足,能够接纳的第三方CI工具不够丰富 。
Rancher 并没有在产品中集成 CI 方面的能力,在 CD 方面通过集成 fleet 项目来实现 GitOps,使用的门槛较高 。

云原生时代的DevOps平台设计之道

文章插图
这样的使用体验还有一个优点,从始至终都不需要开发人员去编写格式严苛的 Kubernetes 声明式配置文件 。这对开发人员而言无疑是一个极大的利好,Kubernetes 虽好,但学习曲线非常陡峭 。Kubernetes 默认通过 yaml 格式的声明式配置文件来部署业务系统,其中绝大多数的字段定义都是运维特征的体现,换句话说,绝大多数的字段定义,都不应该是开发人员关注的事情 。
DevOps 工程师应该抓住开发人员使用 Kubernetes 的痛点,避免其接触复杂运维事务 。云原生平台理应提供这种使用体验,让开发人员对 Kubernetes 完全无感知的情况下,完成业务系统的部署工作 。换句话说,让 Kubernetes 变得对开发人员“透明” 。
从这个方面来说,通过对三款开源云原生平台的体验,发现 Rancher 和 KubeSphere 虽说均可以基于图形化界面来部署自己的业务组件,然而这些图形化配置只是 yaml 声明式配置文件的 “翻译”,对于 Kubernetes 不够熟悉的用户想要顺利使用,还是有一定的门槛 。Rainbond 这一点则做的非常不错,部署业务时完全感受不到 Kubernetes 的存在,对于不熟悉 Kubernetes 的用户而言非常友好 。然而产品化定制的程度越高,跟随 Kubernetes 前进的脚步就越难,上游 Kubernetes 不断在推出新的功能特性,如何将新特性抽象成为用户易于理解的功能将会是个挑战 。最新版本的 Rainbond 推出了 Kubernetes 属性这一功能特性,允许用户以 yaml 形式编辑 workload,也是为打破自设的“天花板” 。

经验总结扩展阅读