一. 建木介紹
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 文法實作同樣的配置：
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: . 04
流程執行
在主界面點選流程的”觸發“按鈕，觸發流程執行，進入流程執行資訊界面後，可以檢視每個節點執行的輸出日志。
這樣，一個簡單的流程采用了更加簡單的配置過程，就這麼簡單地實作了。
在建木中，除了采用圖形項目的方式外，也可采用代碼項目的方式，使用 DSL 描述文法，來建立 DevOps 流程，除了建立的方法不同外，執行的邏輯是完全相同的。
三. 深入探索
1.遇到一個問題
在目前項目實際使用中，因目前處于開發階段，對于 DevOps 流程來說，子產品的拆分及更新，希望流程也能拆分來實施。
建木 Docker 化的節點運作方式，是其優點，也是其有些不适應的地方，就從上面示範流程中的 "git clone" 和 "maven 建構" 節點來說：
01
“git clone” 節點本地存儲采用的是 Docker 臨時建立的目錄，該目錄在同一條流水線中可以共享，但流程結束後該目錄也會被清理，在多子產品拆分流程的情況下，每一次執行都需要全部重新 clone；
02
“maven建構” 節點每一次建構後的中間檔案和結果檔案，随着流程的結束消失了，這樣每次建構都需要從頭建構；
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 的目錄映射，代碼如下：
// 挂載 /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 領域帶來功能更加強大、使用更加便捷的落地工具。