几种自建CI工具的调研
Contents
已有开源工具中, 我平时使用的是azure的pipeline(私有项目), 以及travis-ci(公有项目), 个人比较喜欢azure的, 可以自建agent, CI结束之后顺便将部署工作也完成.
自建CI工具的一些调研
部门中使用的git仓库并不是gitlab这样的开源git仓库. 也没有支持第三方应用, 目前只有webhook可以使用, CI工具的选择上少了许多, 即使使用开源的CI工具, 也要自己定制一番. 另外, 由于我已经维护了一个PaaS平台, CI工具也是为它服务, 所以也会考虑这个平台的相关问题.
本文只探讨一些可以自建服务的CI系统, 并就使用功能情况, 用户上手难易程度, 定制难度, 部署难度做一些简单的探讨.
CI工具的大部分资料来源于:
https://ligurio.github.io/awesome-ci/
https://alternativeto.net/software/travis-ci/?platform=self-hosted
Jenkins
Jenkins之前我就自己写过一些配置文件. 个人看法: 独立的大型项目使用jenkins是比较合适的, Jenkinsfile的功能很强大, 可以做到包括启动docker镜像, 生成virtualenv环境, 以及自定义通知的功能.
Jenkins有一点不好就是你需要写的东西太多了, 部署在PaaS平台中的应用不大, 但是比较多. 每个应用开发者都写jenkinsfile既不利于维护, 也增加了成本. PaaS平台中的应用, 所需要的CI都是简单的跑几句单元测试语句, 最多可能需要启动一个mysql或者redis, 使用原生的Jenkinsfile感觉大材小用.
Agola
开发栈: Golang + Vue 数据库: etcd
总体来说, 我并不喜欢agola的文档, 按照它的方案搭建gitea和agola也许可以成功,
但会有一种云里雾里的感觉, 强烈建议大家开始时使用Github的API进行, 而且, 你需要一个公网域名和服务器.
程序有一些BUG, 用户可能会因为一些莫名的错误而产生挫败感, 建议做好hack的心里准备.
我试用了比较多, agola使用oauth2登录的形式进行验证与授权. 它可以作为Github, Gitlab的一个应用进行使用,
agola运行时的流程:
- 申请Github应用, 获得
clientid和secret - 使用
agola remotesource create的方式, 增加其作为Github应用 - 用户登录, 创建项目(程序后台去github中设置hook)
- 当用户修改了代码, 触发hook时, 进行构建
优缺点分析
优点
- 开源自己可以部署
- 完成度比较高, 可以在框架中做一些改动
缺点:
- 用户界面用起来并不是很舒服, 比如有几个按钮不太方便去点击, 点击起来和想象的功能不太一致, 任务页面的标签太大, 显得内容空洞
- 虽然使用yaml文件, 但是有点罗嗦, 看文档也仍然没找到比如redis,mysql这种服务的预先加载功能
- 程序中仍然有一些BUG, 我在页面载入时
/不知为什么会转义成%2F - 构建时的变量设置虽然有这个页面, 但我依旧没有找到从哪里设置
如果PaaS项目中想要接入这个CI工具, 比较可行的方案是:
对PaaS平台:
- 实现一套oauth的认证登录, 以及粗略的授权系统. 使得agola可以利用PaaS平台进行登录, 并有能力获取其中的一些项目.
- webhook需要平台进行中转
- 当前情况, agola的yaml代码比较复杂, 可能需要简单的实现一个yaml转换器
对agola平台:
参照github的oauth增加部分代码, 另外需要修复一些BUG(类似上面的路径问题).
Abstruse CI
开发栈: Golang + Angula
https://github.com/bleenco/abstruse
最后一个release版本是18年12月的, 尝试docker启动之后, 也和agola一样, 可以通过oauth的方式进行接入, 也可以使用自己的用户系统, 但是接入oauth登录之后, 只能看到在github的项目, 但我始终不知道该如何编写CI文件使其运行. 放弃了.
Concourse-CI
开发栈: Golang
有个同学之前已经搭建并写了一篇博客, 我是是参考他的:
https://www.boris1993.com/tools/concourse/concourse-quick-start.html
这一种较为独立的CI工具, 起初我以为它功能孱弱, 但是使用了之后才发现, 它其实更专注于CI/CD的功能.
优缺点分析
优点
- 完成度较高
- 相比于复杂的Jenkins, 它的配置已经十分简单
- pipeline的部分, 文档较为完善, 也有示例项目, 比agola好很多
缺点
- 用户配置界面功能几乎没有, 所有操作需要靠命令行工具
fly实现 - 用户系统需要单独建立, 也无法去支持oauth2这种, 如果一开始要打算支持Gitlab或Github的项目, 那就不要考虑了
比较可行的接入方案
对于Concourse-CI平台:
- 搭建好该平台后, 需要借用OpenID作为校验工具登录
- 需要维护用户组信息
对于PaaS平台:
- 用户创建项目后, 需要渲染一个Concourse-CI的pipeline, 并将pipeline绑定到对应的组中
- 定时同步用户组信息至CI系统中
相比agola, PaaS平台的中的修改可能更少一点, 因为不需要完整的实现一套oauth2系统了.
总结
有两种风格的CI系统, 一种类似TravisCI, 可以自动导入仓库中项目, 并解析项目中的ci文件, 另一种是类似Jenkins, 需要手动创建项目, 指定CI流程.
Agola是一个类似于本地TravisCI的系统, 可以兼容多种在线仓库, 基本上只要提供了oauth的支持, 都可以接入到系统中. 现有的系统想要接入, 最好要提供oauth2的基础系统功能, 未来的扩展性也很强.
Concourse-CI更像是一个精简版的Jeknins, 当然它更加轻量, 使用yaml的描述型语句可能没有groovy这样的语句强大, 但是作为CI已经足够用了, 参考TravisCI的功能, 简单的做一些扩展应该也足够用了. 开发与接入周期短, 因为与现有平台结合相对紧密 未来的扩展性可能没那么强.