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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第三個(gè)問題是Jenkins需要升級(jí)，插件也需要升級(jí)，而鏡像本身沒辦法自動(dòng)升級(jí)。

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

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

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

Jenkins Slave On Docker 工作流程

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

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

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

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

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

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

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

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

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

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