[譯]英雄聯盟是如何使用jenkins和docker的

《容器的深入思考》一文告訴大家如何在容器中構建一個項目。今天，我將向大家展示我的團隊當前是如何綜合運用Jenkins和Docker來為Riot引擎團隊提供服務的。在最近的博文中，我承諾不就將會直接討論實際的salve構建和Jenkins配置。但是，從某種意義上講，這是一件主要的事件：如果你沒有一臺接收salve的Jenkins服務器，最好的辦法是回過去看看我以前的博客。

不過，在正確的開始本教程之前，我們先討論一下方式和方法。通過Docker，有很多種方式來創建 slaves。即使縮小場景，只使用 Jenkins，還是有多種選擇。通過研究與發現，我覺得有兩種主要的方式你可以采用。從概念上講，我將這兩種模式稱之為“Docker execution”和“Docker ephemeral slave”。

這兩種方式的本質區別是Jenkins如何與構建的slave進行連接和通信。在執行模式下，Jenkins使用一種傳統的流行方式連接：在虛擬機或者物理設備上運行一個客戶端，這里指的就是一臺運行的Docker主機。在臨時模式中，Jenkins直接連接Docker容器，將其視為一個構建的slave。這兩者之間的區別很重要，所以我們花一點時間來分解這兩種模式。

DOCKER 執行模式

在執行模式下，我們在結構上假定slave是一臺Docker主機，但是把它當做一臺物理機來處理。當一個Jenkins任務啟動時，它直接在slave上同步/創建一個工作目錄，并通過“docker run”和“docker exec”命令來轉換容器，然后將其掛載到本地的工作空間中。容器是一個虛擬暫存空間，是一個隔離的環境。它可以包含所有的自定義版本的工具和二進制文件（我們需要對裝載到容器的源代碼進行編譯）。

當一個構建任務完成時，所有二進制文件和生成的構建歸檔文件將會發送到傳統Jenkins工作空間中的slave上。然后，Jenkins可以安全的關閉容器，正常的執行后續的清理工作。

該模式的最佳代表是Cloudbees定制構建環境插件（Cloudbees Custom Build Environment Plugin），該插件是一個開源插件，由 Jenkins 源碼庫的主人維護。

DOCKER 臨時 Slave 模式

臨時模式的目的在于利用Docker容器的自主性和隔離性來擴展 Jenkins 的構建范圍，以滿足在Jenkins上的任何需求。相對于傳統的預先分配slave數組或現成的虛擬機，這種模式將容器自身看做是一個slave。

當Jenkins的執行器上有一個需求時，我們需要轉換容器，自動地配置Jenkins以便將該容器視為一個新的slave來接收，然后執行任務，最后關閉容器，回收slave。當然這種模式比執行模式更復雜。

這種方式有幾個相互競爭的插件，這些插件通常都是以如何維護和構建Docker云為中心。迄今為止，這種插件有Kubernetes，Mesos以及“純”Docker方式。

如何選擇模式？

兩種模式都能有效的解決問題。在Riot，我們感興趣的是為特定的目標獲取分配盒子和“執行器”的方式，所以臨時模型對我們有很強的吸引力。我們喜歡用一個容器來代表整個slave的想法。因此，我們使用Docker Plugin 來完成我們的目標。

隨著時間的推移，我們很高興當初的選擇。Docker Plugin的主開發者（KostyaSha）對該插件的維護非常活躍，經常更新，并且有很強大的社區。他負責響應問題，并在GitHub repo 提供了清晰的路線圖。沒有他的工作，我不可能完成這篇文章中提供的教程，該教程是基于 0.16 版本插件的。

此外請注意，KostyaSha最近將“Docker Plugin”分出來一個新的倉庫“Yet Another Docker Plugin”進行繼續開發。由于我們現在的生產環境正在使用的插件是“Docker Plugin”，所以在本文中選擇該插件進行分析。

在以后，我們可能會改變我們的想法。我們盡量保證靈活性，以便在有更好的解決方案時能夠方便的進行轉換。我們采取的方式也受到過教訓-在本教程最后我會對它們進行描述。

教程

這是我寫的最長的教程。所以我決定在這只保存鏈接以節省空間（將實現與方案進行分離）。如果你已經清楚了之前的文章，該教材只需要花費30-45分鐘左右的時間就可完成。你可以從這獲取到完整的教程：

Containerized Jenkins Farm教程

另外，如果你想跳過結構部分，盡快開始并運行起來，你可以從這獲取到完整的教程，然后按照 README 中的說明進行操作：

https://github.com/maxfields2000/dockerjenkins_tutorial/tree/master/tutorial_07

經驗教訓

運營這個平臺有著諸多其自身獨特的挑戰。請記住這個簡短的列表，希望能幫助你節省時間和精力：

運營一個大規模的 DOCKERHOSTS 并不是一個簡單的任務。

磁盤空間是一個大問題。Docker鏡像很消耗空間。每個運行的容器也要耗費空間。有時候，容器掛了也還會占用空間。有的團隊使用卷來創建slave，這需要耗費更多的空間。

在Docker主機上監控磁盤空間是必不可少的，不要等到磁盤消耗完的時候再去處理，要及時的監控并處理。

清理鏡像和容器，就像垃圾回收一樣。

每次一個新的鏡像推送到Docker主機，都會留下“懸浮”的未使用層，清理這些空間應該是日常的操作，否則磁盤空間就會成為問題。

容器的slave有時無法停止或無法清理，關注“退出”和“死亡”的容器是保證Docker主機清潔必不可少的一部分。

增加新的鏡像/SLAVE 到 DOCKERHOSTS 隊列是一個很耗時的操作。

最初，要求工程師必須將他們的鏡像在 Jenkins 中進行配置。很快我們發現這個過程是一個不必要的障礙。根據我們的經驗，在早期的開發中，工程團隊平均每周需要對他們的Dockerfile做多次修改。

我們創建一個稱之為“Harbormaster”的工具，該工具通過 Groovy 的API，能夠自動的驗證工程師提供的鏡像，并自動的配置 Jenkins。Harbormaster 通過一組核心的標準來測試每個鏡像，并驗證salve是否正常工作。然后生成一份測試報告并自動配置Jenkins。

關于 Harbormaster 如何工作的討論可能會導致本文過長。我將在以后的博客對其進行闡述。

風險監控室是必不可少的

關于如何監控 Jenkins 和Docker Swarm，我們也還在不斷的成長中。Docker Cloud 的監控藝術是發展過程中的永恒主題，并且當這個云是一個構建場景而不是應用場景時，還會呈現出一種獨特的扭曲狀態。

正如Harbormaster，在這討論監控也會使得本文太長。同樣，我會在以后的博客中更多的討論生產環境下的監控問題。

JENKINS的審計可能會咬到你

曾經，由于 Jenkins 的崩潰導致磁盤消耗完的問題，導致我們工作到半夜。結果是因為“創建/銷毀”構建的slave時，產生了 100,000 個微小的日志文件。Jenkins保存了所有的創建和銷毀slave時的審計文件；一定要注意，否則你會死的很難看。

當然還有更多的經驗教訓。在以后的博客中我還繼續會討論我們是如何處理某些問題的，所以有問題就趕緊問吧，不要猶豫！

你的生產環境系統和我們的研究結果

隨著本教程的結束，你應該已經有了一個完整功能Docker Jenkins 沙盒。在創建過程中你會遇到一些困難，在生產環境中你也需要做幾件事情。

1.使用Docker Plugin 配置你生產環境的 Jenkins 主服務器，正如你在上述教程中做的一樣（安裝插件）。

2.啟動一個“生產環境”的Docker主機。這可能有點超出了本教程的范圍。我們的流水線團隊使用 Centos 虛擬機來運行 VSphere，不過你也可以使用 AWS 的實例或物理機，任何你想要的有效的Docker主機都行。這就是Docker的強大之處。

3.如果在構建環境的Docker主機中，沒有使用 TLS 安全機制（在安全環境中并不少見），確保在設置中移除“https”和“Docker cert path”。

4.如果你正在使用 TLS，確保在 Jenkins 中配置生產環境的證書。

5.確保你構建的slave鏡像是生產環境下的Dockerhost所能到達的。在 Riot，我們使用一個中央鏡像倉庫。

很多東西都涉及到安裝，所以，請不猶豫，有什么問題就問，并提供必要的點。

對于我們來說，這不是一個“沙盒”或“玩耍”的設置。這個教程中，列出的只是我們在線環境中改變的一個組件。我們生產環境的Dockerhost實際上是一個Docker Swarm 應用，由 10 臺Dockerhost機器支撐。下面這些圖標展示我們現在（發布本文的時候）是如何設置這些東西的

抽象結構

 

物理結構

 

這是來自我們生產系統中的某些統計數據

Jenkins 統計數據：

 

Jenkins 統計數據細節

平均隊列大小：20-30

預備執行器：~650

平均使用的執行器：30-40

構建節點的總數量：~80

每小時的平均任務數：~600

DockerJenkins 統計數據

 

DockerJenkins 統計數據細節

平均隊列大小：3

預備執行器：20（為構建流程控制）

平均使用的執行器：3

任意時間的平均節點數：5

每小時的平均任務數：50

去年初年初，我們將系統部署在Docker很早的版本上（Docker 1.2），Docker Plugin 也是的版本（.8），穩定性是當初關注一個核心問題。不過現在的版本（Docker 1.10 + Docker Plugin 0.16），我非常相信，就我們的需求而言，它是足夠穩定的。在這一年中，我們一直在使用它們，我們從少量的構建任務和幾個早期的使用團隊發展到現在，無論是任務數還是團隊數都有了巨大的增加。很明顯，一旦我們有機會進行完整的測試，我們就會遷移到新的插件“Yet Another Docker Plugin”上。

事實上，我們的Dockerized Jenkins平臺現在構建的任務，大概只占我們整個 Jenkins 平臺所支撐的全部任務（超過4000）的25%。網絡新構建任務創建在傳統Jenkins環境中的幾乎為0，大部分新創建的任務都在我們的Docker平臺上。原因如下：

1、引擎團隊通過自定義Dockerfiles可以完全控制他們的構建環境。

2、通過Docker，可以將他們部署的構建環境復制到本地，這樣那些“構建環境”就可以很容易在本地進行測試。

3、團隊不在需要“系統管理員”來構建虛擬機或其他環境，這些權限“放手”到了每個人手里。

結論

2015年8月，當我開始這一系列博客的寫作之旅時，我們已經有了一個功能性的原型。八個月以后，博客幾乎趕上了我們當前的進度，缺乏監控和擴展。

在這個點上，你應該對Docker基礎有一個很堅實的入門，并且知道一些關于Docker的擴展和安全問題，這些都通過Jekins的真實應用場景演示過。另一方面，你應該有一個功能性配置文件，用于配置一個完整的Jekins測試環境，并通過它來運行你本地的Docker Toolbox Dockerhost，還包括建立自己的構建slave的能力。這幾乎就是“盒子容器中的Jenkins”，在以后的博客中，我將會更深入的挖掘這個生態系統，分析我們創建的工具、API以及監控。

我真心希望你能覺得這些東西是有用的。我們收到的反饋也非常棒，我很喜歡社區的這種熱情。如果你能在下面發表評論，我將會非常感激！

所有有效的文件都在我公開的Github上；這里所有的一切僅僅是開源的魔法！在這里，可以毫不猶豫的發起問題，提出需求等。

來源：微笑0619（簡書作者）