摘要：而持續(xù)集成的意義就在于減少風險，和重復的過程，最終提高工作效率。第二級調(diào)度由被稱作的組件組成。能和不同類型的通信，每種由相應(yīng)的應(yīng)用集群管理。這是的任務(wù)啟動過程。數(shù)人云運維平臺持續(xù)集成實踐這是數(shù)人云運維平臺的持續(xù)集成實踐。

今天小數(shù)給大家?guī)淼挠质鞘愕母韶洠寒斶\維遇到云計算，當Docker遇到Mesos和Jenkins，會擦出怎樣的火花呢？且看來自數(shù)人云運維工程師金燁的演講實錄分享——

首先講一下持續(xù)集成的優(yōu)勢。過去公司做測試可能需要十幾、二十幾個組件，集成一次往往要一兩個小時，費力費時，而且復雜容易出錯，而一旦配置出錯的話耗時會更久。因此，一次集成測試一周才會做一次，測出Bug要到下一周才能更新，再做測試，這個周期會非常漫長。而持續(xù)集成的意義就在于減少風險，和重復的過程，最終提高工作效率。

Docker是現(xiàn)在非常火的一門技術(shù)，使用Docker首先解決的是環(huán)境的問題。因為開發(fā)環(huán)境和運維的部署環(huán)境千奇百怪，依賴的環(huán)境和包各不一樣。其次，Docker是可以實現(xiàn)更快速地交付和部署，只要寫一個Dockerfile，把服務(wù)打成一個鏡像，然后再遷移到各種服務(wù)器上就行了，部署的過程也非常方便，服務(wù)器只要有Docker的環(huán)境就可以運行。因為是內(nèi)核級虛擬化解決方案，Docker利用的額外資源很少，同時，它的更新管理也非常容易，只需要把Dockerfile修改一兩行，其他的服務(wù)器則不需要做改動，也不需要下載其它的安裝依賴包，打好Docker鏡像直接就可以部署鏡像、直接運行。這些都是它的優(yōu)勢。

Apache Mesos是一款開源集群管理軟件。Mesos經(jīng)過了Facebook，Twitter這些大型公司的萬臺主機驗證，在國內(nèi)，愛奇藝、去哪網(wǎng)，小米網(wǎng)等公司也擁有大規(guī)模的Mesos集群應(yīng)用。Mesos實現(xiàn)了兩級調(diào)度架構(gòu)，可以管理多種類型的應(yīng)用程序。第一級調(diào)度是Master的守護進程，管理Mesos集群中所有節(jié)點上運行的Slave守護進程。集群由物理服務(wù)器或虛擬服務(wù)器組成，用于運行應(yīng)用程序的任務(wù)，比如Hadoop和MPI作業(yè)。第二級調(diào)度由被稱作Framework的“組件”組成。Framework包括調(diào)度器（Scheduler）和執(zhí)行器（Executor）進程，其中每個節(jié)點上都會運行執(zhí)行器。Mesos能和不同類型的Framework通信，每種Framework由相應(yīng)的應(yīng)用集群管理。圖中只展示了Hadoop和MPI兩種類型，其它類型的應(yīng)用程序也有相應(yīng)的Framework。Mesos支持多種Framework，比如說Hadoop，Spark，Storm等等，各類型的Framework在它上面都可以運行。

Marathon是Mesosphere為Mesos生態(tài)圈打造的一個輕量級管理服務(wù)APP框架，它可以用RESTful API方便地進行操作。

下圖是在Marathon上發(fā)布各種的服務(wù)，它們都可以通過Marathon發(fā)到Mesos的集群資源中。

例如我們發(fā)了三個服務(wù)，分別是有一個節(jié)點的，三個節(jié)點的和五個節(jié)點的。

我們想拓展這些服務(wù)的話，可以調(diào)用Marathon的API進行擴展，秒級擴展到下圖。

如果有一臺主機宕掉了， Marathon會均勻地把服務(wù)遷移到其他的機器上，選擇資源有空余的機器進行遷移。這樣能就保證服務(wù)是動態(tài)的調(diào)度，保證服務(wù)的高可用，并且這些都是它內(nèi)部自行處理的，不需要手動干預(yù)。

Jenkins是Java開發(fā)的一種持續(xù)集成的工具，我們在它的基礎(chǔ)上做了一些重復的工作，比如版本發(fā)布、測試代碼，以及調(diào)用外部接口。Jenkins支持很多插件，可以很方便地選擇使用適合自己團隊的插件工具。

Jenkins為我們提供了便利，當然Jenkins本身也有它自己的問題，比如傳統(tǒng)的Jenkins是單點的，任務(wù)大多是需要排隊的，如果每個任務(wù)都自己建一套Jenkins的話，資源會非常浪費。為了解決這些問題，我們引入了Jenkins On Mesos。

Jenkins 分為Master 節(jié)點和Slave 節(jié)點，Master 進行調(diào)度，Slave節(jié)點負責負責執(zhí)行Job任務(wù)。

首先我們把Jenkins的Master通過Marathon發(fā)布，Marathon 去調(diào)用 Mesos Master，之后Mesos Master再去Slave節(jié)點起Jenkins的Master。這個機制保證了Jenkins Master的高可用，Marathon會監(jiān)控Jenkins Master的健康狀態(tài)，當Jenkins Master出現(xiàn)崩潰掛掉，Marathon會自動再啟動一個Jenkins Master的任務(wù)。Jenkins Master使用Mesos整個大的資源池，Mesos的資源池是一個資源共享的狀態(tài)，資源利用率也會更高一些。

Jenkins Master做的是調(diào)度，Jenkins Slave則是真正執(zhí)行構(gòu)建任務(wù)的地方。Jenkins Master會在Mesos Master上注冊一個它自己的Framework，如果有任務(wù)需要構(gòu)建的話，Jenkins Master 會通知 Jenkins Framework 調(diào)用 Mesos Master構(gòu)建一個任務(wù)。之后Mesos Master 再調(diào)用 Mesos Slave去起一個Jenkins Slave的節(jié)點去構(gòu)建任務(wù)，它是實時的，用戶資源可能被分配到各個機器上，在不同的機器上并行存在。此外，Jenkins還具備動態(tài)調(diào)度功能，也就是說，當任務(wù)運行完后一定時間，資源會再返還給Mesos，實現(xiàn)合理地利用整個集群的資源，提高集群的資源利用率。

這張圖是Mesos整體的調(diào)度流程。第一步，它的集群有三個Mesos Slave節(jié)點資源，資源上報到Mesos Master，Mesos Master收集到這些資源之后把這些資源再提供給Marathon，Marathon如果要發(fā)任務(wù)，它確認一個Offer1，Offer1足夠任務(wù)來運行，就拒絕其他的Offer，并把這個任務(wù)發(fā)送給Mesos Master，之后Mesos Master去找Slave1起Marathon的任務(wù)。這是Marathon的任務(wù)啟動過程。Mesos本身可以和多框架進行通信，Jenkins Master要跑一個任務(wù)，Mesos Master同樣提供資源給Jenkins，提供的資源包括了Marathon 任務(wù)使用剩下的資源，比如Task1 確認的 Offer1沒有用完和沒有使用的資源，Mesos也會它提供給Jenkins。而Jenkins也會選擇，比如Jenkins選擇了Offer3，拒絕了其他的Offer，把Jenksin的任務(wù)再通過Mesos Master去Mesos Slave中起起來。

Jenkins部署起來非常麻煩，需要安裝各種依賴，如果代碼是從Git上下載的，那么還需要安裝一些Git包。而動態(tài)調(diào)度需要每臺機器上都裝這些依賴，為了解決這種問題，我們把服務(wù)全部進行了Docker化，主機上只需要有Docker環(huán)境就可以運行我們的服務(wù)。

進行Docker化之后就會面臨Docker化的問題，因為Docker和 Mesos都是比較新的技術(shù)，我們遇到了很多坑，也需要去解決。

我們遇到的第一個問題是Jenkinson Mesos需要調(diào)度Mesos的Lib庫，如果Docker化之后是隔離的，就調(diào)不到Mesos Lib。

第二個問題是Docker化的數(shù)據(jù)，因為Jenkins是沒有數(shù)據(jù)庫的，數(shù)據(jù)都是存在本地的JENKINS_HOME目錄中，如果Jenkins Master掛掉之后，相應(yīng)的數(shù)據(jù)就沒有了。

第三個問題是Jenkins需要升級，插件也需要升級，而鏡像本身沒辦法自動升級。

為了解決這些問題，首先我們將Mesos打成一個基礎(chǔ)鏡像，在這個基礎(chǔ)鏡像上安裝Jenkins的服務(wù)制作成一個Jenkins的鏡像，這樣就可以調(diào)用Mesos的Lib庫文件了。

第二是數(shù)據(jù)備份，我們在Jenkins上安裝了一個插件，就是SCM Sync Configuration Plugin 這個插件，它會同步數(shù)據(jù)到Github。如果這個Jenkins Master掛掉了，遷移到另外一臺主機上，它會從Github上面把數(shù)據(jù)克隆下來，數(shù)據(jù)是不會丟失的。此外，如果插件出了故障，或者因為網(wǎng)絡(luò)問題導致Github訪問不了，我們把JENKINS HOME目錄掛在主機上進行備份，進行恢復的時候也會很方便。用以上這兩點來保證數(shù)據(jù)的完整性。

第三對于Jenkins升級或其插件的升級，我們現(xiàn)在的做法是把它重新打一個鏡像，重新在Mararhton發(fā)布Jenkins Master。

Jenkins Slave On Docker 工作流程

首先Jenkins Master如果要構(gòu)建一個Job，讓Mesos Slave起一個Jenkins Slave這樣的容器，容器里面是沒有Docker環(huán)境的，因為容器里面再裝一個Docker環(huán)境就太重了。我們現(xiàn)在的做法是把Jenkins Slave用到的命令掛載，其中包括 /usr/bin/docker /var/lib/docker /sys/fs/cgroup /var/run/docker.sock ，這樣在容器內(nèi)部就可以操作主機上的Docker環(huán)境，Jenkins Slave 可以在容器內(nèi)部進行一些Docker Build，Docker Run，Docker Push等工作。

這是我們運維平臺一些Job List，左下角是Mesos各個Slave的節(jié)點，每一個節(jié)點上都有任務(wù)，這些任務(wù)都是并行的。因為我們的服務(wù)模塊比較多，可能一個模塊一天提交十幾次，這么多的模塊在一天提交幾十次或者上百次的情況也出現(xiàn)過。手動更新、構(gòu)建的話是非常難做到的。現(xiàn)在，做成Jenkins 分布式執(zhí)行Job的模式，一天構(gòu)建幾百上千次也沒有問題，它會把構(gòu)建的任務(wù)均勻的分布在主機資源里。

這是數(shù)人云運維平臺的持續(xù)集成實踐。首先講幾個組件，比如Github，它是存儲代碼的，第二個組件是我們自己開發(fā)了的一個Configserver的API，第三個組件是Jenkins和Marathon。第四個組件是我們的私有Registry，是Docker的一個存儲鏡像的鏡像倉庫。最右下角是CDN，安裝包傳送到達的地方。

首先Jenkins觸發(fā)任務(wù)，Jenkins調(diào)用Configserver提供的API，這個API就去Github上獲取最新代碼的Tag，并對比現(xiàn)有的已經(jīng)更新過的Tag。如果不需要更新，這個任務(wù)就完成了，結(jié)束了。如果需要更新的話，就進行第三步，把從Github拉的代碼放到Configserver上，Jenkins Slave的節(jié)點會從Configserver去拉取代碼到Slave的容器之中。把代碼下載之后再去Pull一個我們編譯環(huán)境的鏡像，然后再用這個鏡像去編譯我們的代碼。比如編譯出來一個二進制代碼，我們把這個二進制重新打一個運行時的鏡像。這個Runtime鏡像打好之后我們再使用Docker Push把它推到私有的Registry，鏡像Push到Registry后，就可以發(fā)布到各種的環(huán)境，比如說Dev Demo生產(chǎn)環(huán)境，調(diào)用Marathon API直接發(fā)布就可以了。同樣在Jenkins Slave，推完鏡像之后就可以去調(diào)用。這樣一個整體構(gòu)建鏡像再部署的任務(wù)就構(gòu)建完成了。

如果有一些安裝包，比如我們的Agent包，它不需要發(fā)布Marathon，需要上傳到CDN，也是在Jenkins Slave 中執(zhí)行的。

因為我們引入了Docker，而且是分布式動態(tài)調(diào)度的，傳統(tǒng)的配置工具如Ansible、Puppet 、SaltStack都已經(jīng)不適用了，沒辦法去管理Docker內(nèi)部的東西。這些配置文件修改起來非常麻煩。

講一下如何進行配置的更新。首先我們做了一個配置中心的一期，把鏡像嵌入自己的腳本，這個腳本實現(xiàn)的功能就是 根據(jù)傳入的ENV CONFIG_SERVER和 SERVICE ，訪問 Configserver的API，API返回的數(shù)據(jù)就是這個服務(wù)需要下載的配置文件的列表，以及它需要下載到哪個目錄底下。Configserver也非常簡單，起一個Nginx，去Vim手動修改。容器一重啟，就會自動拉這些配置文件，把配置進行更新。

一期完成之后，因為是多種環(huán)境，如Dev Demo環(huán)境、預(yù)生產(chǎn)環(huán)境、生產(chǎn)環(huán)境等等，雖然把這些配置都在Configserver上集中配置，但還需要手動修改這些配置。手動修改容易出錯，例如Dev更新了一個服務(wù)，可能過了一周才會更新到生產(chǎn)環(huán)境。那個時候再去修改生產(chǎn)就很容易出錯，導致無法運行。此外，如果配置發(fā)生了Bug需要回滾，手動修改也是不合適的。

為了解決這些問題，我們做了ConfigCenter的二期。其中有我們自己開發(fā)的一個運維平臺，以及Github和Gitlab。Github是個存儲項目的代碼，Gitlab是用了存儲配置模板和最終配置文件的。我們用Jenkins把它們整體的串起來，我們的第一個工作是把所有的配置文件抽象化，各種環(huán)境的文件抽象出來一個模板，放在Gitlab上。它的數(shù)據(jù)是放在數(shù)據(jù)庫里面，這樣組合起來是一個完整的配置文件。各個環(huán)境的值是不一樣的。 我們的運維平臺觸發(fā)Jenkins，Jenkins去調(diào)度我們的ConfigCenter API，它傳入兩個參數(shù)，一個是需要更新的環(huán)境，第二個是更新哪個服務(wù)。之后API去做對比，從數(shù)據(jù)庫去讀現(xiàn)有的配置文件的模板Tag，再去讀新模板的Tag進行對比。如果這個文件需要更新，把它從數(shù)據(jù)庫拉過來，數(shù)據(jù)做匹配，渲染成我們最終的配置文件，再傳到Gitlab上。剩下的通過Jenkins 觸發(fā) Configserver去調(diào)Gitlab下載最新的配置文件到Configserver服務(wù)器，Jenkins再去調(diào)用Marathon去重啟服務(wù)，服務(wù)就會成功更新配置文件。

這里有兩個需要注意的點，一方面模板需要更新，另一方面值要更新，這是兩種模式。模板更新是所有的流程都要走一遍，如果模板沒有更新，只是值更新的話，我們只需要在運維平臺上做修改。修改的同時它會做一個標記，說明這個服務(wù)配置文件是需要更新的，之后就會生成一個最新的配置繼續(xù)下面的操作。如果這兩個都不需要更新的話就返回，不再操作。