建站
咨詢
售后
建站咨詢
新聞中心
前言
近些年來Docker、 Kubernetes、 Helm、 云原生如火如荼，Jenkins 憑借開源社區(qū)的貢獻(xiàn)以及類似 CloudBees 團(tuán)隊(duì)的加持。緊跟技術(shù)發(fā)展趨勢，產(chǎn)出了集成于 Docker、 Kubernetes、 Helm、AWS等各種工具插件，還有 Jenkins X，原來配置頁的 Manage Nodes 也"悄悄地"變成了 Manage Nodes and Clouds。 另一方面，自研能力不錯(cuò)的企業(yè)，也紛紛基于 Jenkins API開發(fā)一套 Devops CICD 平臺(tái)，給 Jenkins那個(gè)"老頭"套上了一層年輕的外衣，效果也十分理想。
Jenkins開源的特性，還有浩瀚如海的插件，學(xué)習(xí)門檻低等等，都讓其成為一個(gè)不錯(cuò)的選擇。至少可以在有限資源的條件下，針對項(xiàng)目中需要搭建少數(shù)的幾個(gè)流水線這樣的需求而言，Jenkins再合適不過了。
縱使作為一個(gè)新技術(shù)的愛好者，當(dāng)你用戶其他新的CI工具時(shí)，也不妨回過頭來看一看這個(gè)“老頭”，其中包含的一些通用法則、思想會(huì)讓你明白如何才能搭建使用于某個(gè)項(xiàng)目易用、易擴(kuò)展、易維護(hù)的流水線。
提高代碼復(fù)用性之Shared Library
如果你為一個(gè)項(xiàng)目里的多個(gè)Code Repo寫多個(gè)jenkinsfile，你八成會(huì)遇到多個(gè)不同流水線中有大量重復(fù)代碼的情況，尤其在服務(wù)眾多的微服務(wù)的項(xiàng)目當(dāng)中。很多時(shí)候?yàn)榱朔奖闶∈挛覀兌际侵苯訌?fù)制粘貼類似的邏輯代碼到不同的jenkinsfile中去，但如果某一天你需要更改一個(gè)小小的命令，那你就要受點(diǎn)小罪了。
而Shared Library便是解決代碼重復(fù)的方法之一，只需根據(jù)流水線段落的合理劃分，將流水線邏輯重復(fù)或共通的部分進(jìn)行抽象和封裝，便可在所有的流水線中簡單地引用這些共享庫下面的代碼，并可大大縮短jenkinsfile中的代碼行數(shù)，也顯得更加易讀、易維護(hù)。
而后期之秀中的Azure Pipelines, Github Actions 似乎深知復(fù)用功能函數(shù)的好處，并將其常用的Tasks/Actions放置到了公共的Marketplace中。開發(fā)者即可直接使用，也可以自行開發(fā)后上傳到Marketplace中供更多人使用。使用者更是免于維護(hù)一個(gè)單獨(dú)的類似于Jenkins Shared Libray的代碼倉庫，一舉多得。另外，云原生工具中的Tekton， 其中的Task也有類似的實(shí)踐。
共享庫越來越大，調(diào)用關(guān)系越來越復(fù)雜時(shí)，不得不考慮代碼質(zhì)量的問題。那就需要測試代碼來保證質(zhì)量，如何對Shared Library進(jìn)行測試?當(dāng)然可以編寫Jenkinsfile放到Jenkins中創(chuàng)建Job去運(yùn)行，跑一跑便知代碼是否有問題。但無疑這種方法不太優(yōu)雅，推薦使用JenkinsPipelineUnit(一個(gè)共享庫單元測試的框架)。
模板化之 JTE
正如一套開發(fā)框架一樣，目的是為了快速地搭建起一個(gè)標(biāo)準(zhǔn)化的許多項(xiàng)目，模板提供的功能也是如此：對于同一類型的流水線而言，大多數(shù)的構(gòu)建過程均是一樣的，甚至連運(yùn)行的命令也是一模一樣，這樣的流水線 配置文件相似度自然也是非常的高。那么 Jenkins Templating Engine就是針對這樣的場景的一個(gè)非常好的解決方案。
例如，在微服務(wù)的大型項(xiàng)目中，往往一個(gè)系統(tǒng)是由數(shù)十個(gè)小的微服務(wù)組成的，而著數(shù)十個(gè)微服務(wù)均需要各自的CICD的流水線，來完成打包、部署的過程，彼此之間又是同一套開發(fā)框架，所需要的構(gòu)建環(huán)境、工具、測試流程、發(fā)布策略等等均是一個(gè)模子刻出來的。
"人"如其名， Jenkins Templating Engine就是用來做流水線模板化的工具，簡稱 JTE。從 JTE 主頁可看到誕生時(shí)間是2019年5月份，相當(dāng)年輕。針對不同類型的項(xiàng)目，比如Maven、 Gradle來做一些模板化的規(guī)定，簡單而言就是用來統(tǒng)一內(nèi)部流水線的Stage、Steps中的邏輯、參數(shù)等。
在完成上述代碼，以及安裝JTE插件、正確配置 Jenkins的前提下，在具體業(yè)務(wù)代碼中添加默認(rèn)文件pipeline_config.groovy之后，新建流水線時(shí)針對 build configuration 選項(xiàng)去選擇Jenkins Templating Engine，即可完成流水線的搭建，只需要簡簡單單的2、3行。
而反觀 JTE 的優(yōu)勢，便是以下三點(diǎn)：
(來源于 https://www.jenkins.io/blog/2019/05/09/templating-engine/)
而去其他CICD工具中尋找一下，也可見到類似實(shí)踐的身影。例如 Gocd 的Pipeline Templates, Azure Pipelines 的 templates。
集中管理之Job DSL
如果你正在經(jīng)歷一個(gè)微服務(wù)項(xiàng)目，Code Repo 數(shù)量眾多，而每個(gè)Repo都需要通過一個(gè)Jenkinsfile定義一個(gè)流水線。當(dāng)你面對幾十上百個(gè)Repo，分散地管理維護(hù)它們便些許繁瑣。Job DSL Plugin 允許使用DSL以編程方式創(chuàng)建項(xiàng)目，將作業(yè)創(chuàng)建的操作通過腳本實(shí)現(xiàn)，使你能夠自動(dòng)化和標(biāo)準(zhǔn)化 Jenkins 配置。
這款插件不單單能夠創(chuàng)建各種類型的Job(Maven jobs、Freestyle jobs、流水線 jobs...)，還能創(chuàng)建 Folder、 Dashboard View、 List View等等。形象生動(dòng)的效果如下圖，“埋下一顆種子，收獲幾顆大樹”。
在代碼庫的目錄層級上，首先建議按照 Project 劃分，給每個(gè) Project 定義單獨(dú)的 Seed Job;其次將Job等的定義與邏輯實(shí)現(xiàn)隔離，這樣能確保 xxx.jenkinsfile 里的內(nèi)容的獨(dú)立性，且在采納Job DSL插件后，針對原先的 jenkinsfile 無需做很大幅度的修改，拿過來便可使用。
該工具無疑將Pipeline As Code的理念又進(jìn)化了一步，將流水線的創(chuàng)建過程也代碼化了。然后在 Jenkins 實(shí)踐中，如果想追求更多的配置代碼化，不妨看看 Jenkins Configuration as Code，簡稱 JCasC。這個(gè)工具能完全將大部分的Jenkins的資源、配置代碼化，安裝插件、配置Github Server、管理憑證、新建任務(wù)等等都可通過文件完成，不需要在UI界面上做任何的操作。
后記
以上幾種思想在本文中都提供了對應(yīng)的一種實(shí)現(xiàn)方式，但遠(yuǎn)遠(yuǎn)不止于所提及的方法，當(dāng)然還有或多或少類似的方法，但萬變不離其宗。縱使今后有更多的CICD新工具的出現(xiàn)，或許在一些小的地方上可以另辟蹊徑，但大體的解決方案也繞不開已有的這些解決問題的思想。例如在Azure Pipelines中, Templates的功能能提供類似 Shared Library 和 JTE的功能，只是實(shí)現(xiàn)形式不同，核心思想?yún)s還是一致的。
具體使用還需要結(jié)合項(xiàng)目屬性、分支策略、發(fā)布策略、權(quán)限管理、服務(wù)器環(huán)境情況等多個(gè)方面綜合考慮，另外也有很多類似于 Nightly Build 這種構(gòu)建策略值得我們借鑒?！皸l條道路通羅馬”，怎么省時(shí)、省力的達(dá)成我們最終的目標(biāo)，以及達(dá)成之后如何維護(hù)好流水線，都值得好好思考與設(shè)計(jì)。
當(dāng)前題目：部署流水線的通用法則
URL標(biāo)題：http://www.5511xx.com/article/dpedoji.html
