Docker在英雄聯盟游戲中的實踐探索
Riot將Docker和Jenkins相結合，以此來構建流水線（Pipeline）。這篇博客是Riot實踐Docker的系列博客的第一篇，主要介紹了他們的目標和理念；后續博客則以教程的形式一步一步地記錄Riot的Docker實踐。
容器技術已經風靡全球，我們歡迎容器化領域的新霸主們。
然而，他們也給Riot的流水線工程團隊（Pipeline Engineering team）的同事們帶來了新挑戰。我叫Maxfield Stewart，是Riot的工程師，我們組主要負責構建流水線（Pipeline）——從代碼簽入（check in）到部署的一切工作，甚至更多。如果說持續交付是一首主題曲的話，那么我們就是用清唱的方式演唱它。我們運轉的是一個類似云的環境，管理著Riot最 大的一個服務器和虛擬機集群。其中的一個龐然大物是構建集群（Build Farm），由大量的物理機和虛擬機組成。它是從數年前的一個小集群發展而來的，當時只負責構建英雄聯盟的游戲客戶端。
最近，我們已經融入了Docker容器技術。我們是如何將容器與傳統的構建集群集成，并使其越來越像一個自服務的基于云的工作引擎呢？我們能否使 用Dockerfile定義構建環境，并與我們常用的開源架構相結合呢？我們又能不能拋棄傳統的基于虛擬機的云，轉身擁抱容器云呢？
上述問題已經持續了相當長的一段時間，就像寒冰射手（Ashe）的箭一樣。接下來，我將通過一個系列博客介紹我們的團隊是如何嘗試回答上述問題的。本文是 其中第一篇博客，主要是介紹我們的團隊背景，以及我們為什么要整合容器技術。在后續博客中，我將具體地分享如何整合Jenkins和Docker。第一篇 教程是一個 基礎介紹。如果你對于使用容器創建構建集群、持續交付、幫助工程師快速交付，那么這個系列就是你要的。請準備好：我將從基本介紹，逐步深入，最終介紹如何使用Docker承載真正的業務。
一年之前，我們將持續集成引入到了英雄聯盟。在那之前，我們拼命地嘗試以一個常規節奏來發布英雄聯盟，但是我們步履維艱。因此我們打算盡可能自動 化這一切，從構建流水線到創建測試環境，獲得了大量的成果，包括提高交付一致性、減少構建時間、改善總體完成度。英雄聯盟從一天幾次的構建，增長到了每天 30次構建。
構建英雄聯盟可不是開玩笑的，其中包括了超過150個任務，我們構建每個重要的版本。每次構建有各種形式，從傳統的debug構建到新版本，以及專門為了 包括騰訊和Garena在內的全球合作伙伴準備的變種版本。我們可以追蹤到每次構建、什么測試環境、什么測試內容、PBE以及快速部署成產品。我們可以一 鍵創建測試環境，并且可以在幾個星期內從20個測試環境增加到70多個，包括450多個虛擬機。構建英雄聯盟只是構建集群的一部分工作，構建集群本身支持 了Riot各個工程團隊的3300多個構建任務。然而，這一構建流程并不是完美的，這些陳舊的工具有時需要連接起來才能工作。在持續集成中，我們秉持4項 原則：
- 我們認為工程師團隊必須能完全掌控他們的技術棧，包括對于構建環境的管理員權限。
- 我們認為配置即代碼。團隊應當盡可能使用源碼控制來維護他們自己的構建流水線和環境。
- 我們認為每當工程師執行一次構建，都需要針對所有可部署的配置構建一個可交付的版本。一個“構建”并不只是編譯代碼而已，而是所有可部署的組件的集合。
- 我們認為一次交付就是一個產品決策（shipping is a product decision）。只需按一下按鈕，產品團隊就能夠部署并查看最新版本。 </ul>
- 開源版本的Jenkins
- Jenkins的任務DSL插件（Job DSL Plugin）
- Jenkins的構建流插件（Build Flow plugin）
- 將各個組件連接在一起的工程獨創性 </ul>
- 基于Linux構建微服務和網站的工程師們能夠以編程的方式定義他們的構建環境了
- 本地的構建環境和構建集群中的構建環境是完全一致的（在后續博客中，我將介紹如何做到這一點）
- 動態資源分配意味著降低整體計算成本
- 一臺虛擬機可以處理4個不同的組合300多個構建任務，這原本是通過8臺虛擬機完成的 </ul> </li> </ul>
這篇博客僅僅是一個系列話題的介紹，這個系列將覆蓋多個領域，以教程的形式發布，提供實例和源碼。首先，系列博客將介紹如何使用Docker來部 署Jenkins，包括各種最佳實踐，并通過一個真實應用引入Docker的基礎知識；然后，系列博客將探索容器化構建環境的各種方案，并介紹Riot是 如何將Docker融入Jenkins的生態環境；最后，將介紹流水線工程團隊是如何完成最終目標的。
本質上來說，這一系列博客就是記錄了這個旅程。就像之前宣稱的，我們知道我們想要的就是Docker容器定義的構建環境，開發團隊可以通過 Dockerfiles來維護它。在已知技術棧的情況下，我們希望能預生成構建流水線，這樣一來，團隊從創建代碼庫的第一天就能維護持續集成的構建流水 線。對于如何實現我們有些想法，但過程是不斷迭代的，而且有很多新的發現，博客的寫法將會遵循這個過程。
我們希望通過系列博客來能分享我們的發現以及遭遇的挫折。這些或許不是什么大秘密，但可能是不容易發現的。我希望我們的系列博客能回報社區，并通過交流和對話學習到更多。
原文鏈接：THINKING INSIDE THE CONTAINER（翻譯：夏彬 校對：魏小紅）
來自： http://dockone.io/article/687本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
我們需要世界一流的技術棧才能達到這些目標。通常有三種選擇：完全重頭編寫、購買別人的工具或者定制化開源項目。
我們選擇了第三種。在這篇博客中，我不想比較各種CI工具。不過，通過修改開源工具來符合我們的需求是一個最好的折中方案：不需要重頭編寫；可以與開源世界合作；如果有必要的話，可以輕易脫離它。
因此，我們的技術棧非常簡單：
我們選擇和繼續使用Jenkins，是因為它是靈活的、開源的、易于處理我們的基本構建操作。總體來說，Jenkins是易于創建一個構建流水線 的，符合我們持續交付的核心需求（如上所述）。作為一款廣泛應用的開源工具，我們有一個極具活力的社區在與我們合作。與重頭編寫自定義工具相比，工程師團 隊可以利用開源標準的實現，這是很有幫助的，也是具有風險的。開源標準經常變化，昨天的一個好主意明天就可能變成一個壞主意。然而，利用合適的插件和技術 訣竅，我們只用了少量的代碼、配置和開銷，就完成了一個全自動的持續集成鏈。
那么，Docker發揮了什么作用呢？讓我們回想一下我提到的持續交付的核心原則。最近，我們團隊遇到的一個挑戰是構建環境的所有權。之前，工程 師們通過Packer.io定義自己的虛擬機鏡像，然后給產品團隊集群的root權限。本質上，我們需要通過Jenkins這一個工作流引擎定義一個內部 的云環境。我們探索了幾個通用的配置管理工具，如Puppet和Chef，來實現虛擬云環境，并使工程師們能控制這些機器。
然后，Docker出現了。
這件事情就變得簡單了：Dockerfile比其他工具更易于維護。在Docker的幫助下，我們意識到容器更容易管理了。如果我們把Docker中Dockerfile的概念和構建環境的所有權結合起來，我們就進入了工程天堂。
Docker很善于解決部署中的挑戰。我主要關注Docker是如何幫助工作流引擎、構建系統和流水線，同時也熟悉了如何將其作為一個部署工具和方法論。 Riot管理著大量的微服務，而容器和微服務的組合就像花生醬和巧克力的組合。因為Docker成為了一個“Thing（tm）”，我們也會使用它來解決 其他的一些問題。
流水線工程團隊的夢想變得更真實了：我們想要一個流水線構建工具，它能動態地加速持續交付流水線，使用框架代碼來按需地一鍵構建環境。為了創建一個完整的構建流水線，我們之前是通過自動化配置虛擬機來實現的，現在我們認為使用Docker容器來完成。
需要說明的是，Docker并不是一個完美的整體解決方案。它不能解決Windows和OSX的構建環境中的問題，也不能和我們使用的每個工具結 合。但是，Docker確實解決了Linux平臺中我們遇到的很多困難。在Riot，我們在平臺和后端上進行了大量的工程工作。包括核心的后臺服務在內， 幾乎所有的特性都是通過跑在Linux上的微服務來提供的。因此，如何優化解決方案空間是值得我們投入時間和精力的。
我們已經開始將Docker與現有的構建棧結合，并獲得了一些早期的成就。我們創建了Jenkins的一鍵部署環境，在容器中部署，加速了測試和 調試過程。我們從一個小型集群（大概500個任務）開始，使用容器作為構建環境，在所有權和迭代速度上團隊也提供了積極的反饋，包括：