开源 DevOps 工具《建木》实践

新钛云服已累计为您分享724篇技术干货

一. 建木介绍

1.建木简介

第一次听说”建木“是建木的一个发起人谈到，这名字听着感觉有新意，但当时不甚了解，后来查了相关资料，才有所认识。摘录官网一条介绍：

“建木”是上古先民崇拜的一种圣树，传说建木是沟通天地人神的桥梁。伏羲、黄帝等众帝都是通过这一神圣的梯子上下往来于人间天庭。《淮南子·墬形训》亦曰 ：“建木在都广，众帝所自上下。日中无景，呼而无响，盖天地之中也。”

DevOps 是从需求到研发、到落地的一种自动化和平台设计的一种理念，是沟通过程中各个阶段的桥梁，作为 DevOps 落地工具的”建木“，取之其名甚妙也。

2.初试建木

知道建木这个 DevOps 工具后，决定在实际项目中试一试，翻了一遍建木的文档，把建木给安装上了，开始使用。

开始使用时，低代码的配置方式，让 ”Hello world“ 起来非常方便。但要更进一步的时候，却感觉无从下手了，对比自己熟悉的 Jenkins 来，时间紧张的项目工期还是迫使自己放弃进一步尝试。

于是虽然一直在建木社区群里，只是长期潜水。

3.再试建木

虽然没有在项目落地建木，但也对建木持续关注着，看着出品方一个个版本的发布，感觉功能越来越强大了、也更加有吸引力了，总想着什么时候再来一探究竟。

近期公司要上一新项目，DevOps 工具首选自然还是 Jenkins，但想到 Jenkins 配置的繁琐，心里嘀咕着，决定试一下建木，看看这个传说中北半球第二好用的 DevOps 工具，到底能给工作带来怎样的体验。

于是，开始进一步的实践尝试。

二. 建木实践

1.建木的安装

建木的安装极其方便，官方提供 Docker 镜像，支持 docker-compose 和 kubernetes 部署，一键完成。

2.开始使用

建木的界面非常简洁，运行的插件采用了 Docker 化的底层支持，省掉了一堆麻烦的插件安装和配置的过程。

下面就用建木最新版本 v2.6.2 本地化部署，以一个简单的 maven 构建过程作为演示流程，介绍一下建木的入门级使用。

01

主界面

非常简洁的主界面。

02

密钥管理

配置流程前，可以将一些常用的变量、密钥配置到”密钥管理“中，建木除了默认的密钥存储方式外，也支持对接 vault 进行存储，安全性有了进一步的保障。

配置界面如下：

03

流程配置

点击主界面的”图形项目“图标，进入流程配置界面。

页面左边为执行节点，官方提供了比较丰富的节点库，社区也有大量有心人士提供的节点。

选择 ”git clone“ 节点，拖拽到页面中间的配置区，点击节点图标，页面右侧出现该节点的配置项，按需要填写节点配置信息。

再增加一个 "maven构建" 节点，在两个节点间建立连接，选择节点相关的 JDK 版本后，再配置相关参数，保存后返回。

一个流程就这样创建完成了。

上面的流程，可以用 DSL 语法实现同样的配置：0

04

流程执行

在主界面点击流程的”触发“按钮，触发流程执行，进入流程执行信息界面后，可以查看每个节点执行的输出日志。

这样，一个简单的流程采用了更加简单的配置过程，就这么简单地实现了。

在建木中，除了采用图形项目的方式外，也可采用代码项目的方式，使用 DSL 描述语法，来创建 DevOps 流程，除了创建的方法不同外，执行的逻辑是完全相同的。

三. 深入探索

1.遇到一个问题

在当前项目实际使用中，因目前处于开发阶段，对于 DevOps 流程来说，模块的拆分及更新，希望流程也能拆分来实施。

建木 Docker 化的节点运行方式，是其优点，也是其有些不适应的地方，就从上面演示流程中的 "git clone" 和 "maven 构建" 节点来说：

01

“git clone” 节点本地存储采用的是 Docker 临时创建的目录，该目录在同一条流水线中可以共享，但流程结束后该目录也会被清理，在多模块拆分流程的情况下，每一次执行都需要全部重新 clone；

“maven构建” 节点每一次构建后的中间文件和结果文件，随着流程的结束消失了，这样每次构建都需要从头构建；

02

03

“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 领域带来功能更加强大、使用更加便捷的落地工具。