一. 建木介紹

1.建木簡介

第一次聽說”建木“是建木的一個(gè)發(fā)起人談到，這名字聽著感覺有新意，但當(dāng)時(shí)不甚了解，后來查了相關(guān)資料，才有所認(rèn)識(shí)。摘錄官網(wǎng)一條介紹：

“建木”是上古先民崇拜的一種圣樹，傳說建木是溝通天地人神的橋梁。伏羲、黃帝等眾帝都是通過這一神圣的梯子上下往來于人間天庭?！痘茨献印椥斡?xùn)》亦曰 ：“建木在都廣，眾帝所自上下。日中無景，呼而無響，蓋天地之中也?！?/span>

DevOps 是從需求到研發(fā)、到落地的一種自動(dòng)化和平臺(tái)設(shè)計(jì)的一種理念，是溝通過程中各個(gè)階段的橋梁，作為 DevOps 落地工具的”建木“，取之其名甚妙也。

2.初試建木

知道建木這個(gè) DevOps 工具后，決定在實(shí)際項(xiàng)目中試一試，翻了一遍建木的文檔，把建木給安裝上了，開始使用。

開始使用時(shí)，低代碼的配置方式，讓 ”Hello world“ 起來非常方便。但要更進(jìn)一步的時(shí)候，卻感覺無從下手了，對比自己熟悉的 Jenkins 來，時(shí)間緊張的項(xiàng)目工期還是迫使自己放棄進(jìn)一步嘗試。

于是雖然一直在建木社區(qū)群里，只是長期潛水。

3.再試建木

雖然沒有在項(xiàng)目落地建木，但也對建木持續(xù)關(guān)注著，看著出品方一個(gè)個(gè)版本的發(fā)布，感覺功能越來越強(qiáng)大了、也更加有吸引力了，總想著什么時(shí)候再來一探究竟。

近期公司要上一新項(xiàng)目，DevOps 工具首選自然還是 Jenkins，但想到 Jenkins 配置的繁瑣，心里嘀咕著，決定試一下建木，看看這個(gè)傳說中北半球第二好用的 DevOps 工具，到底能給工作帶來怎樣的體驗(yàn)。

于是，開始進(jìn)一步的實(shí)踐嘗試。

二. 建木實(shí)踐

1.建木的安裝

建木的安裝極其方便，官方提供 Docker 鏡像，支持 docker-compose 和 kubernetes 部署，一鍵完成。

2.開始使用

建木的界面非常簡潔，運(yùn)行的插件采用了 Docker 化的底層支持，省掉了一堆麻煩的插件安裝和配置的過程。

下面就用建木最新版本 v2.6.2 本地化部署，以一個(gè)簡單的 maven 構(gòu)建過程作為演示流程，介紹一下建木的入門級(jí)使用。

（1）主界面

非常簡潔的主界面。

（2）密鑰管理

配置流程前，可以將一些常用的變量、密鑰配置到”密鑰管理“中，建木除了默認(rèn)的密鑰存儲(chǔ)方式外，也支持對接 vault 進(jìn)行存儲(chǔ)，安全性有了進(jìn)一步的保障。

配置界面如下：

（3）流程配置

點(diǎn)擊主界面的”圖形項(xiàng)目“圖標(biāo)，進(jìn)入流程配置界面。

頁面左邊為執(zhí)行節(jié)點(diǎn)，官方提供了比較豐富的節(jié)點(diǎn)庫，社區(qū)也有大量有心人士提供的節(jié)點(diǎn)。

選擇 ”git clone“ 節(jié)點(diǎn)，拖拽到頁面中間的配置區(qū)，點(diǎn)擊節(jié)點(diǎn)圖標(biāo)，頁面右側(cè)出現(xiàn)該節(jié)點(diǎn)的配置項(xiàng)，按需要填寫節(jié)點(diǎn)配置信息。

再增加一個(gè) "maven構(gòu)建" 節(jié)點(diǎn)，在兩個(gè)節(jié)點(diǎn)間建立連接，選擇節(jié)點(diǎn)相關(guān)的 JDK 版本后，再配置相關(guān)參數(shù)，保存后返回。

一個(gè)流程就這樣創(chuàng)建完成了。

上面的流程，可以用 DSL 語法實(shí)現(xiàn)同樣的配置：0

name: workflow測試
description: ""
global:
  concurrent: false
pipeline:
  node_0:
    alias: git clone
    type: _/git_clone:1.2.5
    param:
      username: ((tisvc_key.git_username))
      password: ((tisvc_key.git_password))
      remote_url: http://gitlab.tyun.cn/tyun/tiops-agent.git
      ref: refs/heads/master
      commit_id: ""
      depth: 1
  node_1:
    alias: maven構(gòu)建
    type: _/maven_build:1.3.1-jdk11
    param:
      workspace: ${node_0.git_path}/src
      mvn_action: package
      extra_arge: ""
      nexus_username: admin
      nexus_password: "123456"
      maven_public_id: public
      maven_public_url: https://maven.aliyun.com/repository/public
      maven_release_id: release
      maven_release_url: ""
      maven_snapshot_id: snapshot
      maven_snapshot_url: ""
      docker_username: jianmudev
      docker_password: "123456"
      image_name: imagename
      image_tag: latest
      vc_pom_dir: .

（4）流程執(zhí)行

在主界面點(diǎn)擊流程的”觸發(fā)“按鈕，觸發(fā)流程執(zhí)行，進(jìn)入流程執(zhí)行信息界面后，可以查看每個(gè)節(jié)點(diǎn)執(zhí)行的輸出日志。

這樣，一個(gè)簡單的流程采用了更加簡單的配置過程，就這么簡單地實(shí)現(xiàn)了。

在建木中，除了采用圖形項(xiàng)目的方式外，也可采用代碼項(xiàng)目的方式，使用 DSL 描述語法，來創(chuàng)建 DevOps 流程，除了創(chuàng)建的方法不同外，執(zhí)行的邏輯是完全相同的。

三. 深入探索

1.遇到一個(gè)問題

在當(dāng)前項(xiàng)目實(shí)際使用中，因目前處于開發(fā)階段，對于 DevOps 流程來說，模塊的拆分及更新，希望流程也能拆分來實(shí)施。

建木 Docker 化的節(jié)點(diǎn)運(yùn)行方式，是其優(yōu)點(diǎn)，也是其有些不適應(yīng)的地方，就從上面演示流程中的 "git clone" 和 "maven 構(gòu)建" 節(jié)點(diǎn)來說：

（1）“git clone” 節(jié)點(diǎn)本地存儲(chǔ)采用的是 Docker 臨時(shí)創(chuàng)建的目錄，該目錄在同一條流水線中可以共享，但流程結(jié)束后該目錄也會(huì)被清理，在多模塊拆分流程的情況下，每一次執(zhí)行都需要全部重新 clone；

（2）“maven構(gòu)建” 節(jié)點(diǎn)每一次構(gòu)建后的中間文件和結(jié)果文件，隨著流程的結(jié)束消失了，這樣每次構(gòu)建都需要從頭構(gòu)建；

（3）“maven構(gòu)建” 本地緩存目錄設(shè)置在 Docker 中，節(jié)點(diǎn)運(yùn)行結(jié)束后容器也就結(jié)束，每一次構(gòu)建都需要從 maven 遠(yuǎn)程倉庫重新拉取依賴包。

上面的問題，在頻繁執(zhí)行流程的時(shí)候，不好的感覺就會(huì)被放大。于是去社區(qū)尋求答案，但在開源社區(qū)看到技術(shù)團(tuán)隊(duì)有明確表示對類似問題暫時(shí)不考慮，從官方尋求支持就比較困難了。

2.如何解決

在使用的過程中，發(fā)現(xiàn)如果要實(shí)現(xiàn)持久化共享目錄的話，有一個(gè)方法是采用 “SSH執(zhí)行命令” 節(jié)點(diǎn)，但這樣所有的流程都轉(zhuǎn)化為 shell 腳本問題，顯然不是好的解決方案，也無法體現(xiàn)建木在流程方面的優(yōu)勢了。

從 gitee 拉取了建木的源碼，分析建木的幾個(gè)模塊后，確認(rèn)流程的執(zhí)行主要是由三個(gè)模塊完成：jianmu-ci-server、jianmu-worker-docker、runner節(jié)點(diǎn)，那實(shí)現(xiàn)目錄共享可以從這三個(gè)模塊入手。于是計(jì)劃在 DSL 描述語法的 spec 區(qū)域，增加一個(gè)對 runner 節(jié)點(diǎn) VolumeMount 的支持。

動(dòng)手修改了 jianmu-ci-server、jianmu-worker-docker的代碼，在發(fā)布測試 runner 節(jié)點(diǎn)的時(shí)候，沒有通過 DSL 語法的校驗(yàn)，嘗試失敗，此路不通。

上面的路走不通了，但是路還是要走的， 最終決定用比較直接的方法，修改 jianmu-worker-docker 模塊，為 runner 節(jié)點(diǎn)增加一條 /workspace:/workspace 的目錄映射，代碼如下：

// 掛載 /workspace 目錄，以存放希望在流程中持久化的文件
config.Mounts = append(config.Mounts, mount.Mount{
    Type:   mount.TypeBind,
    Target: "/workspace",
    Source: "/workspace",
})

這樣每一個(gè) runner 節(jié)點(diǎn)都能有一個(gè)本地主機(jī)的目錄映射，達(dá)到了目錄共享持久化的目的，至于具體 runner節(jié)點(diǎn) 的使用，則由 runner 節(jié)點(diǎn)自行支持了。

針對上面遇到的問題，在官方的 “git clone” 和 “maven構(gòu)建” runner 節(jié)點(diǎn)的基礎(chǔ)上，添加了兩個(gè)自定義節(jié)點(diǎn)，增加了對 /workspace 目錄的使用。

四. 小結(jié)

通過在項(xiàng)目中對建木的使用，感覺建木在設(shè)計(jì)上是非常符合 DevOps 理念的，并且通過簡單的配置或者簡潔的 DSL 語法，就可以滿足工作中的流程需求，相較于 Jenkins 的使用，非常便利，適合上手、適合上頭。

但目前建木還處于成長期，有些功能還不是很完善，希望技術(shù)團(tuán)隊(duì)能繼續(xù)努力，為 DevOps 領(lǐng)域帶來功能更加強(qiáng)大、使用更加便捷的落地工具。