今天,我打算給 Jenkins 管理員和開發者們介紹一個新的工具 Custom WAR Packager。該工具能夠打包 Jenkins 的自定義 WAR 發行版、 Docker 鏡像以及 Jenkinsfile Runner 包。它能夠打包 Jenkins、插件以及配置爲開箱即用的發行版。 Custom WAR Packager 是咱們曾在一篇博客-- A Cloud Native Jenkins --中介紹過的無狀態 Jenkins master 工具鏈的一部分。這個工具鏈已在 Jenkins X 中被用於構建 serverless 鏡像。git
在這篇文章中,我將會介紹幾種 Custom WAR Packager 常見的使用場景。github
歷史docker
正如 Jenkins 自己同樣,Custom WAR Packager 開始於一個小的開發工具。在 Jenkins 內運行集成測試很長時間以來都是一個難題。對此,咱們有三個主要的框架: Jenkins Test Harness, Acceptance Test Harness, 和 Plugin Compatibility Tester。這些框架都須要一個 Jenkins WAR 文件來運行測試。可是,假如你想在相似 AWS 同樣的自定義環境中進行 Jenkins 測試呢? 或者,你但願基於 Pluggable Storage 的環境也能夠複用 Jenkins 流水線測試,來確保沒有迴歸缺陷,又如何呢?緩存
這並非沒有意義的問題。雲原生 Jenkins、Jenkins Evergreen 以及 Jenkins X, 這些 Jenkins 項目中正在進行的主要活動,都須要大量的集成測試來實現持續交付流程。爲了複用已有的框架,咱們須要打包一個自帶配置的 WAR 文件,以即可以在現有的框架中運行集成測試。這正是 Custom WAR Packager 於 2018年4月 建立的緣由。到 2018年9月,它相繼支持了 Docker 鏡像和 Jenkinsfile Runner,後者由 Kohsuke Kawaguchi 建立並由 Nicolas de Loof 完善。框架
揭開面紗less
Custom WAR Packager 是一個工具,能夠做爲命令行、Maven 插件或者 Docker 程序包來用。該工具能夠從用戶處獲取配置,並根據用戶請求進行打包。全部內容都由一個 YAML 配置文件管理:工具
1544582657(1).jpgpost
該工具支持多種輸入類型。插件列表能夠來自 YAML,pom.xml 或一個 BOM(jep:309[] 提出的 Bill of Materials) 文件。Custom WAR Packager 不只支持發佈版本,還能夠構建部署到 增量倉庫 (Jenkins 核心及插件的 CD 流程 - jep:305[]),甚至直接從 Git 或指定目錄中構建。它容許從任何來源構建包,而無需等待官方版本。因爲插件已經經過 Commit ID 緩存到了本地的 Maven 倉庫中,所以其構建過程也很是快。性能
自定義Custom WAR Packager 還支持下面的配置選項:開發工具
Jenkins 配置即代碼 的 YAMl 文件
Groovy Hooks (例如:預配置的 init hooks)
系統屬性
WAR打包
每當這個庫構建時會打包出來一個 WAR 文件。一般,Custom WAR Packager 會根據下面對 Jenkins 核心和 JCasC 的配置把全部內容打包的一個 WAR 文件中。
樣例配置:
bundle: groupId: "io.jenkins.tools.war-packager.demo" artifactId: "blogpost-demo" vendor: "Jenkins project" description: "Just a demo for the blogpost"war: groupId: "org.jenkins-ci.main" artifactId: "jenkins-war" source: version: 2.138.2plugins:
jenkins.model.Jenkins.slaveAgentPortEnforce: "true"groovyHooks:
Docker 打包
爲了打包 Docker,Custom WAR Packager 使用官方的 Docker 鏡像 jenkins/jenkins 或一樣格式的其餘鏡像。在構建期間,WAR 文件會被該工具構建的文件所替換。這也就意味着鏡像的 全部 特點在該自定義構建中均可用: plugins.txt, Java 選項, Groovy hooks 等等。
...## WAR configuration from above## ...buildSettings: docker: build: true
base: "jenkins/jenkins:2.138.2"
tag: "jenkins/custom-war-packager-casc-demo"
例如:示例 展現了打包帶有將構建日誌存儲到 Elasticsearch 的 Docker 鏡像。 儘管這些已經做爲了 jep:207 和 jep:210 的一部分,你仍是能夠查看這個示例,瞭解該 Docker 鏡像是如何配置、鏈接到 Elasicsearch、而後啓動外部的日誌存儲,而不須要改變日誌的界面。一個 Docker Compose 文件對於運行整個集羣是必要的。
Jenkinsfile Runner 打包
這多是 Jenkinsfile Runner 最微妙的模式。三月,在開發者列表中 宣佈了一個新的項目 Jenkinsfile Runner。大致的思路是,支持在單一 master 上只運行一次並打印輸出到控制檯的 Jenkins 流水線。 Jenkinsfile Runner 做爲命令或一個 Docker 鏡像來運行。雖然只推薦 Docker 的形式,可是 Custom WAR Packager 都可以生成。使用 Jenkinsfile Runner ,你能夠像下面的方式來運行流水線:
docker run --rm -v $PWD/Jenkinsfile:/workspace/Jenkinsfile acmeorg/jenkinsfile-runner
當咱們開始在雲原生特別興趣小組(Cloud Native SIG)中研究無狀態(也就是「一次」)時,有一個想法就是使用 Custom WAR Packager 和其餘已有的工具(Jenkinsfile Runner, Jenkins Configuration as Code 等)來實現。也許只是替換 Jenkinsfile Runner 中的 Jenkins 核心的 JAR 以及插件,但這還不夠。爲了高效,Jenkinsfile Runner 鏡像應該啓動得 很快。在構建流程實現中,咱們使用了 Jenkins 和 Jenkinsfile Runner 一些實驗性的選項,包括:類加載預緩存、插件解壓等等。有了這些後,Jenkins 使用 configuration-as-code 和幾十個插件能夠在幾秒鐘內啓動。
那麼,如何構建自定義 Jenkinsfile Runner 鏡像呢?儘管目前尚未發佈,但這不會影響咱們繼續實現上文提到的內容。
...## WAR Configuration from above##...buildSettings: jenkinsfileRunner: source: groupId: "io.jenkins" artifactId: "jenkinsfile-runner" build: noCache: true source: git: github.com/jenkinsci/j ... r.git commit: 8ff9b1e9a097e629c5fbffca9a3d69750097ecc4 docker: base: "jenkins/jenkins:2.138.2" tag: "onenashev/cwp-jenkinsfile-runner-demo" build: true
你能夠從 這裏 找到用 Custom WAR Packager 打包 Jenkinsfile Runner 的例子。
更多信息
還有不少其餘的特點沒有在本文中提到。例如:它還能夠修改 Maven 構建配置或增長、替換 Jenkins 核心中的庫(例如:Remoting)。請查看 Custom WAR Packager 文檔 獲取更多信息和示例。
若是你有興趣對這個庫作貢獻,請建立 PR 並抄送 @oleg-nenashev 和 Raul Arabaolaza。(編者注:Raul Arabaolaza 是第二位正在研究 Jenkins 自動化測試流程的維護者。)
下一步
還有不少值得改進的地方可使這個工具更加高效:
增長對插件依賴傳遞的檢查以便在構建過程當中發現衝突
容許在 YAML 配置文件中設置各類系統屬性和 Java 選項
改進 Jenkinsfile Runner 的性能
集成到 Jenkins 集成測試流程中,(查看 Jenkins 流水線庫中的 essentialsTest())
即便目前,該工具已經可以讓 Jenkins 用戶構建他們本身的發行版,從理論上來說,仍有許多其餘任務能夠在 Custom WAR Packager 中實現。