Jenkins,我都不用手動配置

Jenkins 很是靈活，現在已成爲實現 CI/CD 的事實標準，同時擁有一個活躍的社區來維護幾乎全部工具和用例的插件。可是靈活也是要付出代價的：除了 Jenkins 核心以外，許多插件須要一些系統級別的設置才能正常工做。

在某些狀況下，「Jenkins 管理員」是一個全職職位。Jenkins 管理員在負責維護基礎設施的同時，還要爲一個巨大的 Jenkins master 提供數百個已安裝的插件和數千個託管做業。維護最新的插件版本是一項挑戰，故障轉移（failover）也會是一場噩夢。

這就像幾年前系統管理員必需要爲每一個服務管理特定的機器同樣。 在 2018 年，經過使用基礎架構自動化工具和虛擬化，一切均可以做爲代碼進行管理。須要一個新的應用服務器做爲你的應用的暫存環境嗎？那你只須要部署一個 Docker 容器。基礎設施缺乏資源嗎？那就在你喜歡的雲服務上分配更多資源來使用 Terraform。

在這種狀況下，Jenkins 管理員的角色怎麼樣？他們是否還要花費數小時來點擊網頁表單上的複選框？也許他們已經採用了一些自動化、依賴於 Groovy 腳本或一些本身寫的 XML 模板。

今年早些時候咱們發佈了第一個 alpha 版本的 「Jenkins Configuration-as-Code」 （JCasC），它是一種基於 YAML 配置文件和自動模型發現的 Jenkins 配置管理新方法。Jenkins 已經升級爲 Jenkins 頂級項目。 同時，對應的 Jenkins 加強提案已經被接受。

JCasC 能爲 Jenkins 管理員作些什麼？

JCasC 容許咱們在啓動時或經過 web UI 按需在 Jenkins master 上應用一組 YAML 文件。與 Jenkins 用於實際儲存配置的詳細 XML 文件相比，這些配置文件很是簡潔易讀。這些文件還有用戶友好的命名約定，使管理員可以輕鬆地配置全部 Jenkins 組件。

下面是一個例子： jenkins: systemMessage: "Jenkins managed by Configuration as Code"

securityRealm: ldap: configurations:

• server: ldap.acme.com rootDN: dc=acme,dc=fr managerPasswordSecret: ${LDAP_PASSWORD} cache: size: 100 ttl: 10 userIdStrategy: CaseInsensitive groupIdStrategy: CaseSensitive 如你所見，不須要很長的解釋你就能夠理解這個 YAML 文件如何配置你的 Jenkins master。

優勢

JCasC 最直接的好處就是可重複性。管理員如今可使用徹底相同的配置經過一個簡單的設置來引導新的 Jenkins master。這容許他們建立一個測試實例並檢查升級插件在沙盒環境中的影響。這也使他們對故障轉移和災難恢復方案更有信心。

當管理員開始在源代碼管理中管理 Jenkins 的 YAML 配置文件時，他們也會感覺到相似使用 Terraform 同樣的好處。這樣作可讓他們對 Jenkins master 配置進行審覈，使其具備可逆性。他們能夠創建一個合理的配置改變運行 Jenkins 實例的工做流，並確保在實際應用任何修改到他們的 Jenkins master 以前配置是健康的。

最後也是最重要的是，因爲可以快速設置 Jenkins master 而且能用一組共享的 YAML 配置文件控制它們，管理員如今能夠給每一個團隊提供一個 Jenkins 實例，而且在安裝插件有更高的靈活性。只要他們還在使用 Jenkinsfiles 管理構建定義（build definition），master 就會或多或少地成爲大家團隊的短時間的基礎架構。

使用 Configuration-as-Code，咱們能夠再也不像對待寵物那樣對待咱們的 Jenkins master，而像對待牛那樣管理它們，你也能夠絕不費力地替換它們。 歡迎來到 「as-code」 的世界。

他們仍然很可愛，對吧?

Ok, 那麼以後呢? 你能夠在項目中閱讀有關 Jenkins Configuration-as-Code 插件的更多信息。與社區和貢獻者們交流，加入咱們的 gitter 頻道，或者來咱們的 Jenkins World 一塊兒討論 JCasC 項目及其將來！

另外，不要錯過 Configuration-as-Code 系列的下一篇文章，咱們將會了解 JCasC 如何處理密碼及其餘憑據等敏感數據。