開源 DevOps 工具《建木》實踐
一. 建木介紹
1.建木簡介
第一次聽說”建木“是建木的一個發(fā)起人談到，這名字聽著感覺有新意，但當(dāng)時不甚了解，后來查了相關(guān)資料，才有所認識。摘錄官網(wǎng)一條介紹：
“建木”是上古先民崇拜的一種圣樹，傳說建木是溝通天地人神的橋梁。伏羲、黃帝等眾帝都是通過這一神圣的梯子上下往來于人間天庭。《淮南子·墬形訓(xùn)》亦曰 ：“建木在都廣，眾帝所自上下。日中無景，呼而無響，蓋天地之中也。”
DevOps 是從需求到研發(fā)、到落地的一種自動化和平臺設(shè)計的一種理念，是溝通過程中各個階段的橋梁，作為 DevOps 落地工具的”建木“，取之其名甚妙也。
2.初試建木
知道建木這個 DevOps 工具后，決定在實際項目中試一試，翻了一遍建木的文檔，把建木給安裝上了，開始使用。
開始使用時，低代碼的配置方式，讓 ”Hello world“ 起來非常方便。但要更進一步的時候，卻感覺無從下手了，對比自己熟悉的 Jenkins 來，時間緊張的項目工期還是迫使自己放棄進一步嘗試。
于是雖然一直在建木社區(qū)群里，只是長期潛水。
3.再試建木
雖然沒有在項目落地建木，但也對建木持續(xù)關(guān)注著，看著出品方一個個版本的發(fā)布，感覺功能越來越強大了、也更加有吸引力了，總想著什么時候再來一探究竟。
近期公司要上一新項目，DevOps 工具首選自然還是 Jenkins，但想到 Jenkins 配置的繁瑣，心里嘀咕著，決定試一下建木，看看這個傳說中北半球第二好用的 DevOps 工具，到底能給工作帶來怎樣的體驗。
于是，開始進一步的實踐嘗試。
二. 建木實踐
1.建木的安裝
建木的安裝極其方便，官方提供 Docker 鏡像，支持 docker-compose 和 kubernetes 部署，一鍵完成。
2.開始使用
建木的界面非常簡潔，運行的插件采用了 Docker 化的底層支持，省掉了一堆麻煩的插件安裝和配置的過程。
下面就用建木最新版本 v2.6.2 本地化部署，以一個簡單的 maven 構(gòu)建過程作為演示流程，介紹一下建木的入門級使用。
（1）主界面
非常簡潔的主界面。
（2）密鑰管理
配置流程前，可以將一些常用的變量、密鑰配置到”密鑰管理“中，建木除了默認的密鑰存儲方式外，也支持對接 vault 進行存儲，安全性有了進一步的保障。
配置界面如下：
（3）流程配置
點擊主界面的”圖形項目“圖標(biāo)，進入流程配置界面。
頁面左邊為執(zhí)行節(jié)點，官方提供了比較豐富的節(jié)點庫，社區(qū)也有大量有心人士提供的節(jié)點。
選擇 ”git clone“ 節(jié)點，拖拽到頁面中間的配置區(qū)，點擊節(jié)點圖標(biāo)，頁面右側(cè)出現(xiàn)該節(jié)點的配置項，按需要填寫節(jié)點配置信息。
再增加一個 "maven構(gòu)建" 節(jié)點，在兩個節(jié)點間建立連接，選擇節(jié)點相關(guān)的 JDK 版本后，再配置相關(guān)參數(shù)，保存后返回。
一個流程就這樣創(chuàng)建完成了。
上面的流程，可以用 DSL 語法實現(xiàn)同樣的配置：0
（4）流程執(zhí)行
在主界面點擊流程的”觸發(fā)“按鈕，觸發(fā)流程執(zhí)行，進入流程執(zhí)行信息界面后，可以查看每個節(jié)點執(zhí)行的輸出日志。
這樣，一個簡單的流程采用了更加簡單的配置過程，就這么簡單地實現(xiàn)了。
在建木中，除了采用圖形項目的方式外，也可采用代碼項目的方式，使用 DSL 描述語法，來創(chuàng)建 DevOps 流程，除了創(chuàng)建的方法不同外，執(zhí)行的邏輯是完全相同的。
三. 深入探索
1.遇到一個問題
在當(dāng)前項目實際使用中，因目前處于開發(fā)階段，對于 DevOps 流程來說，模塊的拆分及更新，希望流程也能拆分來實施。
建木 Docker 化的節(jié)點運行方式，是其優(yōu)點，也是其有些不適應(yīng)的地方，就從上面演示流程中的 "git clone" 和 "maven 構(gòu)建" 節(jié)點來說：
（1）“git clone” 節(jié)點本地存儲采用的是 Docker 臨時創(chuàng)建的目錄，該目錄在同一條流水線中可以共享，但流程結(jié)束后該目錄也會被清理，在多模塊拆分流程的情況下，每一次執(zhí)行都需要全部重新 clone；
（2）“maven構(gòu)建” 節(jié)點每一次構(gòu)建后的中間文件和結(jié)果文件，隨著流程的結(jié)束消失了，這樣每次構(gòu)建都需要從頭構(gòu)建；
（3）“maven構(gòu)建” 本地緩存目錄設(shè)置在 Docker 中，節(jié)點運行結(jié)束后容器也就結(jié)束，每一次構(gòu)建都需要從 maven 遠程倉庫重新拉取依賴包。
上面的問題，在頻繁執(zhí)行流程的時候，不好的感覺就會被放大。于是去社區(qū)尋求答案，但在開源社區(qū)看到技術(shù)團隊有明確表示對類似問題暫時不考慮，從官方尋求支持就比較困難了。
2.如何解決
在使用的過程中，發(fā)現(xiàn)如果要實現(xiàn)持久化共享目錄的話，有一個方法是采用 “SSH執(zhí)行命令” 節(jié)點，但這樣所有的流程都轉(zhuǎn)化為 shell 腳本問題，顯然不是好的解決方案，也無法體現(xiàn)建木在流程方面的優(yōu)勢了。
從 gitee 拉取了建木的源碼，分析建木的幾個模塊后，確認流程的執(zhí)行主要是由三個模塊完成：jianmu-ci-server、jianmu-worker-docker、runner節(jié)點，那實現(xiàn)目錄共享可以從這三個模塊入手。于是計劃在 DSL 描述語法的 spec 區(qū)域，增加一個對 runner 節(jié)點 VolumeMount 的支持。
動手修改了 jianmu-ci-server、jianmu-worker-docker的代碼，在發(fā)布測試 runner 節(jié)點的時候，沒有通過 DSL 語法的校驗，嘗試失敗，此路不通。
上面的路走不通了，但是路還是要走的， 最終決定用比較直接的方法，修改 jianmu-worker-docker 模塊，為 runner 節(jié)點增加一條 /workspace:/workspace 的目錄映射，代碼如下：
這樣每一個 runner 節(jié)點都能有一個本地主機的目錄映射，達到了目錄共享持久化的目的，至于具體 runner節(jié)點 的使用，則由 runner 節(jié)點自行支持了。
針對上面遇到的問題，在官方的 “git clone” 和 “maven構(gòu)建” runner 節(jié)點的基礎(chǔ)上，添加了兩個自定義節(jié)點，增加了對 /workspace 目錄的使用。
四. 小結(jié)
通過在項目中對建木的使用，感覺建木在設(shè)計上是非常符合 DevOps 理念的，并且通過簡單的配置或者簡潔的 DSL 語法，就可以滿足工作中的流程需求，相較于 Jenkins 的使用，非常便利，適合上手、適合上頭。
但目前建木還處于成長期，有些功能還不是很完善，希望技術(shù)團隊能繼續(xù)努力，為 DevOps 領(lǐng)域帶來功能更加強大、使用更加便捷的落地工具。
