一. 建木介紹

1.建木簡介

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

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

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

2.初試建木

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

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

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

3.再試建木

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

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

于是，開始進一步的實踐嘗試。

二. 建木實踐

1.建木的安裝

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

2.開始使用

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

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

（1）主界面

非常簡潔的主界面。

（2）密鑰管理

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

配置界面如下：

（3）流程配置

點擊主界面的”圖形項目“圖標，進入流程配置界面。

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

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

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

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

上面的流程，可以用 DSL 語法實現(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構建
    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í)行

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

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

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

三. 深入探索

1.遇到一個問題

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

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

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

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

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

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

2.如何解決

在使用的過程中，發(fā)現(xiàn)如果要實現(xiàn)持久化共享目錄的話，有一個方法是采用 “SSH執(zhí)行命令” 節(jié)點，但這樣所有的流程都轉化為 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 的目錄映射，代碼如下：

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

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

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

四. 小結

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

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