一. 建木介紹

1.建木簡介

第一次聽說”建木“是建木的一個發起人談到，這名字聽著感覺有新意，但當時不甚了解，后來查了相關資料，才有所認識。摘錄官網一條介紹：

“建木”是上古先民崇拜的一種圣樹，傳說建木是溝通天地人神的橋梁。伏羲、黃帝等眾帝都是通過這一神圣的梯子上下往來于人間天庭。《淮南子·墬形訓》亦曰 ：“建木在都廣，眾帝所自上下。日中無景，呼而無響，蓋天地之中也。”

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

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構建
    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）流程執行

在主界面點擊流程的”觸發“按鈕，觸發流程執行，進入流程執行信息界面后，可以查看每個節點執行的輸出日志。

這樣，一個簡單的流程采用了更加簡單的配置過程，就這么簡單地實現了。

在建木中，除了采用圖形項目的方式外，也可采用代碼項目的方式，使用 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 的目錄映射，代碼如下：

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

這樣每一個 runner 節點都能有一個本地主機的目錄映射，達到了目錄共享持久化的目的，至于具體 runner節點 的使用，則由 runner 節點自行支持了。

針對上面遇到的問題，在官方的 “git clone” 和 “maven構建” runner 節點的基礎上，添加了兩個自定義節點，增加了對 /workspace 目錄的使用。

四. 小結

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

但目前建木還處于成長期，有些功能還不是很完善，希望技術團隊能繼續努力，為 DevOps 領域帶來功能更加強大、使用更加便捷的落地工具。