共計 5484 個字符，預計需要花費 14 分鐘才能閱讀完成。

這篇文章主要為大家展示了“Docker+Rancher 中如何創建持續集成流水線”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓丸趣 TV 小編帶領大家一起研究并學習一下“Docker+Rancher 中如何創建持續集成流水線”這篇文章吧。

在《構建環境容器化》中，我們開始了構建持續集成流水線的第一步工作——構建系統（Build System）的創建。我們分析了【Build】這一環節的常見的三大挑戰——依賴管理、管理環境依賴、復雜項目的漫長構建時間，以及如何用傳統工具與方法解決這些問題。接著，我們分享了如何利用 Docker 創建容器化的構建系統以更輕松地解決那些傳統挑戰，包括如何將構建環境容器化、如何使用 Docker 打包應用程序、如何使用 Docker Compose 創建構建環境，最終創造一個可重復的、集中管理的、良好隔離的、并行化的構建系統。

現在我們已經將【Build】系統創建好了，那么在本文中，我們將為示例的應用創建一個持續集成流水線。這樣我們既可以確保遵循最佳實踐，又可以確保彼此沖突的那些變化不會相互作用、引發問題。不過，在我們為代碼建立持續集成之前，我們先花一點時間討論如何將代碼劃分到分支中。

分支模式

在我們實現持續集成流水線的自動化時，一個需要考慮的重點是團隊遵循的開發模式。這個模式通常由團隊如何使用版本控制系統來決定。由于我們的應用程序托管在 git 倉庫中，因此我們使用 git-flow 模型進行分支、版本化以及發布我們的應用程序。它是基于 git 倉庫上最常用的模型之一。簡而言之，該模型的思想是維護兩個分支：一個開發（者）分支，一個主分支。每當我們想開發新功能時，就會從開發分支創建出新的分支，并在功能開發完成時，將它合并回來。所有功能分支都有開發人員單獨管理。一旦將代碼提交到開發分支，CI 服務器將負責確保分支始終能夠編譯、通過自動化測試并且可以在服務器上進行 QA 測試和評審。當我們準備進行發布時，可以從開發分支創建一個發布，并將其合并到主分支中。被發布的特定的 commit hash 也會使用版本號進行標記。被標記好的發布項接著就可以被推送到 Staging/Beta 或者生產環境中。

下面我們將使用 git-flow 工具來幫助管理我們的 git 分支。安裝 git-flow 請參考這里的說明：https://github.com/nvie/gitflow/wiki/Installation。安裝好 git-flow，你就可以通過下面所示的 git flow init 命令配置你的倉庫。Git flow 會問一些問題，我們建議你使用默認的設置即可。執行過 git-flow 命令后，它將創建一個開發分支（如果原先沒有開發分支的話），并將其檢出作為工作分支。

現在，我們使用 git flow 輸入 git flow feature start [feature-name] 命令創建一個新功能。通常做法是用 ticket/issue id 用作功能的名稱。比如，如果你使用的是 Jira 處理 ticket，那么 ticket id（例如，MSP-123）就可以作為功能名稱。你還會發現當你使用 git-flow 創建新功能時，它將自動切換到功能分支。

到了這一步，你可以去完成該功能所需的全部內容，然后運行自動化測試套件以確保一切正常運轉。一旦你準備好發布工作，只需告訴 git-flow 去完成這一功能即可。根據你對該功能的實際需要，你想要進行多少次提交都可以。在我的這個示例中，從我們的目的來看，我們只需更新 README 文件，并通過輸入“git flow feature finish MSP-123”來完成更新。

需要注意的是，git flow 合并了開發分支的功能，刪除了功能分支并且返回到了開發分支。此時，你可以將開發分支推送到遠程倉庫（git push origin develop:develop）。當你提交了開發分支，CI 服務器就會接管持續集成流水線。對于更大的團隊來說，一種更合適的模式是在完成功能之前將功能分支推送到遠程，讓它們經評審（review）后，使用 pull request 來合并到開發分支中。

使用 Jenkins 創建 CI 流水線

在這一節，我們假設你已啟動并運行了一個 Jenkins 集群。如果沒有的話，你可以在這里使用官方的 Jenkins 鏡像：https://hub.docker.com/_/jenkins/，在這里可以看到更多關于建立可擴展 Jenkins 集群的內容：https://rancher.com/deploying-a-scalable-jenkins-cluster-with-docker-and-rancher/。在你有了運行的 Jenkins 集群后，我們需要在 Jenkins 服務器上安裝下面的插件和依賴項：

Jenkins Plugins 2.32.2+

Git Parameter Plugin 0.8.0+

Parameterized Trigger Plugin 2.33+

Copy Artifact Plugin 1.38.1+

Build Pipeline Plugin 1.5.6+

Mask Passwords Plugin 2.9+

Docker 1.13.1+

Docker Compose 1.11.1+

安裝好需要的插件后，我們就可以在【Build 流水線】中創建最初的三個任務：編譯、打包和集成測試。這些將作為我們持續集成和部署系統的起點。

構建應用

序列中的第一個任務將會在每次提交后從源碼控制中檢出最新的代碼并且確保其可編譯。它還會運行單元測試。如果要在我們的示例項目中設置第一個任務，選擇 New Item- Freestyle Project。進入項目配置視圖中，選擇 General 選項卡以及“The project is parameterized”選項。添加一個叫做 GO_AUTH_VERSION 的 git 參數，將參數類型設置為 Branch（分支）或者 Tag（標記）。接下來選擇 Advanced 配置參數，使用 Tag Filter 設置獲取匹配“v”的所有標記（比如 v2.0）。將 Default Value 設置成 develop（開發分支）。這將有助于從 Git 獲取版本標簽列表，并為該任務填充選項菜單。如果該任務要在沒有給定值的情況下自動觸發，那么 GO_AUTH_VERSION 默認設成 develop（開發）分支。

接下來，在 Source Code Management 選項卡部分添加倉庫 url，指定分支為 ${GO_AUTH_VERSION}，這樣手動構建時將會使用 git 參數來選擇分支或標記進行構建及設置輪詢間隔。這樣一來，Jenkins 就會持續追蹤我們開發分支的未來所有更改，在我們的 CI（和 CD）流水線中自動觸發第一個任務。這里要注意的是，GO_AUTH_VERSION 的默認值（比如開發分支）將用于自動檢測到的更改。

現在在 Build 選項卡部分選擇 Add Build Step Execute Shell 并從本章前面部分復制 docker run 命令粘貼到這。這樣可以從 Github 獲得最新的代碼，并將代碼構建到 go-auth 可執行文件中。這里需要安裝并運行 docker。如果你使用的是 Linux 服務器，可能還需要在 docker 客戶機命令中添加 sudo 以便能夠訪問 docker 守護進程。

在構建步驟之后，我們需要添加兩個后續步驟，其中 Archive the Artifacts（工件歸檔）將 go-auth 二進制文件和幫助腳本歸檔到項目中。我們在任務中需要指定下列的工件進行歸檔。

接著我們使用 Trigger parameterized builds（觸發器參數化構建）啟動流水線中的下一個任務，如下圖所示。在添加 Trigger parameterized build 時，請確保是從 Add Parameters 中添加的 Current build parameters。這樣可以讓當前任務的全部參數（比如 GO_AUTH_VERSION）用于下一個任務。請留意在 Trigger parameterized build 部分中用于下游任務的參數名稱，我們將在下面的步驟中用到。

構建任務的日志輸出應該像下面展示的這樣。你可以看到我們使用了 docker 化的容器來執行構建。構建時將使用 go fmt 來修復代碼中任何格式的不一致，并且執行我們的單元測試。如果出現測試失敗或者編譯不通過，Jenkins 就會檢測到失敗。此外，你應該通過 email 或者 chat integrations（例如 Hipchat 或者 Slack）設置通知，這樣在構建失敗時就能通知到你的團隊，快速地修復它。

打包應用

代碼編譯通過了，接下來我們就能將它打包進 Docker 容器中。創建打包任務的方式是，選擇 New Item Freestyle Project 并給你的第二個任務起一個名稱，該名稱對應于在先前任務中指定的內容。和之前一樣，該任務也是一個帶有 GO_AUTH_VERSION 參數的參數化構建。要注意的是，這里和所有后續的任務中，GO_AUTH_VERSION 只是一個默認值為 develop（開發分支）的 string 參數。我們希望它的值是從上游傳過來的。

和之前一樣，添加構建步驟來執行 shell。注意這里你不需要指定 SCM 設置，因為我們將從前一個構建生成的工件中提取所需的二進制文件和腳本。注意一下，我們這里是先創建未標記的 usman/go-auth，之后再重新標記，這樣我們就可以在后面執行集成測試，搭建好未打標記的容器環境。

為了構建 Docker 容器，我們還需要前一步中構建的可執行文件。為此，我們增加一個構建步驟復制上游構建中的工件。這樣可以保證我們有可用于 Docker 構建命令的可執行文件，該命令可以打包到 Docker 容器中。注意這里我們選擇了 flatten 目錄來保證所有工件都復制到當前項目的根目錄中。

我們一直在使用 GO_AUTH_VERSION 變量標記我們正在構建的鏡像。在默認情況下，開發分支的變更，總會構建 usman/go-auth：develop 并覆蓋現有的鏡像。在下一章中，我們會發布應用程序的新版本并重新審視這個流水線。

和之前相同，使用了 Trigger parameterized builds 下（包含了 Current build parameters）的后構建（post-build）來觸發流水線中的下一個任務，該任務將使用我們剛剛構建好的 Docker 容器以及在之前章節中詳述的 Docker Compose 來執行集成測試。

執行集成測試

接下來是執行集成測試，先要創建一個新任務。和打包任務相同，新任務是一個使用 GO_AUTH_VERSION string 變量的參數化構建。然后從構建任務中復制工件。這一次我們將使用上面的 Docker Compose 模板來搭建一個多容器測試環境，并對我們的代碼執行集成測試。集成測試（不同于單元測試）通常是與正在測試的代碼完全隔離的。因此，我們會用到一個 shell 腳本，它可以針對我們的測試環境執行 http 查詢。在執行 shell 命令中，將目錄修改為 go-auth 并執行 integrationtest.sh。

腳本的內容可以在這里找到：https://github.com/usmanismail/go-messenger/blob/master/go-auth/integration-test.sh。我們用 Docker Compose 搭建我們的環境，然后使用 curl 發送 http 請求到搭建的容器中。這項任務的日志將會和下圖顯示的相似。Compose 將會啟動一個數據庫容器，并將它連接到 goauth 容器。數據庫連接之后你應該會看到一些列“Pass: …”信息，說明各項測試都在運行和驗證。測試完成后，compose 模板將會自行清理數據庫和 go-auth 容器。

經過了三個任務的設置，你就可以在 Jenkins 視圖中選擇【+ 選項卡】，選擇 build pipeline view 來創建一個新的構建流水線視圖。在彈出的配置界面中，選擇你編譯 / 構建的任務作為初始任務，然后選擇 ok。現在你應該能看到 CI 流水線已經成型。這將給你一個可視化引導，展示每個提交是如何通過你的構建和部署流水線的。

當你更改開發分支時，你會注意到流水線是由 Jenkins 自動觸發的。如果要手動觸發流水線，選擇你第一個（構建）任務，運行它。系統會要求你選擇 git 參數的值（比如 GO_AUTH_VERSION）。不指定的話會執行默認值，并且會運行針對開發分支中最新內容的 CI 流水線。當然，你可以直接在流水線視圖中單擊“Run”。

我們快速回顧一下到現在為止我們所做的工作。我們通過以下步驟為我們的應用程序創建了 CI 流水線：

使用 git-flow 添加新功能，并將他們合并到開發分支中。

跟蹤開發分支的變化，在一個容器化環境中構建我們的應用程序

將我們的應用程序打包到 docker 容器中

使用 Docker Compose 搭建短生命周期環境

執行集成測試以及清理環境

通過上面的 CI 流水線，每當新功能（或者修復）合并到開發分支時，CI 流水線就會執行上述所有的步驟，創建出“usman/go-auth:develop”Docker 鏡像。此外，我們在接下來的章節中將構建更深層的集成部署流水線。另外因為該視圖有清晰的測試階段，你還可以使用此視圖將應用程序版本推廣到各種部署環境中。

以上是“Docker+Rancher 中如何創建持續集成流水線”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！