“建木”是上古先民崇拜的一种圣树,传说建木是沟通天地人神的桥梁。伏羲、黄帝等众帝都是通过这一神圣的梯子上下往来于人间天庭。《淮南子·墬形训》亦曰 :“建木在都广,众帝所自上下。日中无景,呼而无响,盖天地之中也。”
DevOps 是从需求到研发、到落地的一种自动化和平台设计的一种理念,是沟通过程中各个阶段的桥梁,作为 DevOps 落地工具的”建木“,取之其名甚妙也。
2.初试建木
知道建木这个 DevOps 工具后,决定在实际项目中试一试,翻了一遍建木的文档,把建木给安装上了,开始使用。
开始使用时,低代码的配置方式,让 ”Hello world“ 起来非常方便。但要更进一步的时候,却感觉无从下手了,对比自己熟悉的 Jenkins 来,时间紧张的项目工期还是迫使自己放弃进一步尝试。
于是虽然一直在建木社区群里,只是长期潜水。
3.再试建木
虽然没有在项目落地建木,但也对建木持续关注着,看着出品方一个个版本的发布,感觉功能越来越强大了、也更加有吸引力了,总想着什么时候再来一探究竟。
近期公司要上一新项目,DevOps 工具首选自然还是 Jenkins,但想到 Jenkins 配置的繁琐,心里嘀咕着,决定试一下建木,看看这个传说中北半球第二好用的 DevOps 工具,到底能给工作带来怎样的体验。
于是,开始进一步的实践尝试。
二. 建木实践
1.建木的安装
建木的安装极其方便,官方提供 Docker 镜像,支持 docker-compose 和 kubernetes 部署,一键完成。
2.开始使用
建木的界面非常简洁,运行的插件采用了 Docker 化的底层支持,省掉了一堆麻烦的插件安装和配置的过程。
下面就用建木最新版本 v2.6.2 本地化部署,以一个简单的 maven 构建过程作为演示流程,介绍一下建木的入门级使用。
(1)主界面
非常简洁的主界面。
(2)密钥管理
配置流程前,可以将一些常用的变量、密钥配置到”密钥管理“中,建木除了默认的密钥存储方式外,也支持对接 vault 进行存储,安全性有了进一步的保障。
配置界面如下:
(3)流程配置
点击主界面的”图形项目“图标,进入流程配置界面。
页面左边为执行节点,官方提供了比较丰富的节点库,社区也有大量有心人士提供的节点。
选择 ”git clone“ 节点,拖拽到页面中间的配置区,点击节点图标,页面右侧出现该节点的配置项,按需要填写节点配置信息。
再增加一个 "maven构建" 节点,在两个节点间建立连接,选择节点相关的 JDK 版本后,再配置相关参数,保存后返回。
一个流程就这样创建完成了。
上面的流程,可以用 DSL 语法实现同样的配置:0
(4)流程执行
在主界面点击流程的”触发“按钮,触发流程执行,进入流程执行信息界面后,可以查看每个节点执行的输出日志。
这样,一个简单的流程采用了更加简单的配置过程,就这么简单地实现了。
在建木中,除了采用图形项目的方式外,也可采用代码项目的方式,使用 DSL 描述语法,来创建 DevOps 流程,除了创建的方法不同外,执行的逻辑是完全相同的。
三. 深入探索
1.遇到一个问题
在当前项目实际使用中,因目前处于开发阶段,对于 DevOps 流程来说,模块的拆分及更新,希望流程也能拆分来实施。
建木 Docker 化的节点运行方式,是其优点,也是其有些不适应的地方,就从上面演示流程中的 "git clone" 和 "maven 构建" 节点来说:
(1)“git clone” 节点本地存储采用的是 Docker 临时创建的目录,该目录在同一条流水线中可以共享,但流程结束后该目录也会被清理,在多模块拆分流程的情况下,每一次执行都需要全部重新 clone;
(2)“maven构建” 节点每一次构建后的中间文件和结果文件,随着流程的结束消失了,这样每次构建都需要从头构建;
(3)“maven构建” 本地缓存目录设置在 Docker 中,节点运行结束后容器也就结束,每一次构建都需要从 maven 远程仓库重新拉取依赖包。
上面的问题,在频繁执行流程的时候,不好的感觉就会被放大。于是去社区寻求答案,但在开源社区看到技术团队有明确表示对类似问题暂时不考虑,从官方寻求支持就比较困难了。
2.如何解决
在使用的过程中,发现如果要实现持久化共享目录的话,有一个方法是采用 “SSH执行命令” 节点,但这样所有的流程都转化为 shell 脚本问题,显然不是好的解决方案,也无法体现建木在流程方面的优势了。
从 gitee 拉取了建木的源码,分析建木的几个模块后,确认流程的执行主要是由三个模块完成:jianmu-ci-server、jianmu-worker-docker、runner节点,那实现目录共享可以从这三个模块入手。于是计划在 DSL 描述语法的 spec 区域,增加一个对 runner 节点 VolumeMount 的支持。
动手修改了 jianmu-ci-server、jianmu-worker-docker的代码,在发布测试 runner 节点的时候,没有通过 DSL 语法的校验,尝试失败,此路不通。
上面的路走不通了,但是路还是要走的, 最终决定用比较直接的方法,修改 jianmu-worker-docker 模块,为 runner 节点增加一条 /workspace:/workspace 的目录映射,代码如下:
这样每一个 runner 节点都能有一个本地主机的目录映射,达到了目录共享持久化的目的,至于具体 runner节点 的使用,则由 runner 节点自行支持了。
针对上面遇到的问题,在官方的 “git clone” 和 “maven构建” runner 节点的基础上,添加了两个自定义节点,增加了对 /workspace 目录的使用。
四. 小结
通过在项目中对建木的使用,感觉建木在设计上是非常符合 DevOps 理念的,并且通过简单的配置或者简洁的 DSL 语法,就可以满足工作中的流程需求,相较于 Jenkins 的使用,非常便利,适合上手、适合上头。
但目前建木还处于成长期,有些功能还不是很完善,希望技术团队能继续努力,为 DevOps 领域带来功能更加强大、使用更加便捷的落地工具。