智能運維 | 如何作好持續集成——Jenkins on Mesos 實踐

今天小數給你們帶來的又是十足的乾貨：當運維遇到雲計算，當Docker遇到Mesos和Jenkins，會擦出怎樣的火花呢？且看來自數人云運維工程師金燁的演講實錄分享——

持續集成的價值

首先講一下持續集成的優點。過去公司作測試可能須要十幾、二十幾個組件，集成一次每每要一兩個小時，費力費時，並且複雜容易出錯，而一旦配置出錯的話耗時會更久。所以，一次集成測試一週纔會作一次，測出Bug要到下一週才能更新，再作測試，這個週期會很是漫長。而持續集成的意義就在於減小風險，和重複的過程，最終提升工做效率。

Docker

Docker是如今很是火的一門技術，使用Docker首先解決的是環境的問題。由於開發環境和運維的部署環境千奇百怪，依賴的環境和包各不同。其次，Docker是能夠實現更快速地交付和部署，只要寫一個Dockerfile，把服務打成一個鏡像，而後再遷移到各類服務器上就好了，部署的過程也很是方便，服務器只要有Docker的環境就能夠運行。由於是內核級虛擬化解決方案，Docker利用的額外資源不多，同時，它的更新管理也很是容易，只須要把Dockerfile修改一兩行，其餘的服務器則不須要作改動，也不須要下載其它的安裝依賴包，打好Docker鏡像直接就能夠部署鏡像、直接運行。這些都是它的優點。

Mesos

Apache Mesos是一款開源集羣管理軟件。Mesos通過了Facebook，Twitter這些大型公司的萬臺主機驗證，在國內，愛奇藝、去哪網，小米網等公司也擁有大規模的Mesos集羣應用。Mesos實現了兩級調度架構，能夠管理多種類型的應用程序。第一級調度是Master的守護進程，管理Mesos集羣中全部節點上運行的Slave守護進程。集羣由物理服務器或虛擬服務器組成，用於運行應用程序的任務，好比Hadoop和MPI做業。第二級調度由被稱做Framework的「組件」組成。Framework包括調度器（Scheduler）和執行器（Executor）進程，其中每一個節點上都會運行執行器。Mesos能和不一樣類型的Framework通訊，每種Framework由相應的應用集羣管理。圖中只展現了Hadoop和MPI兩種類型，其它類型的應用程序也有相應的Framework。Mesos支持多種Framework，好比說Hadoop，Spark，Storm等等，各種型的Framework在它上面均可以運行。

Marathon

Marathon是Mesosphere爲Mesos生態圈打造的一個輕量級管理服務APP框架，它能夠用RESTful API方便地進行操做。

Marathon 協調應用和Frameworks

下圖是在Marathon上發佈各類的服務，它們均可以經過Marathon發到Mesos的集羣資源中。

擴展和故障恢復

例如咱們發了三個服務，分別是有一個節點的，三個節點的和五個節點的。

咱們想拓展這些服務的話，能夠調用Marathon的API進行擴展，秒級擴展到下圖。

若是有一臺主機宕掉了， Marathon會均勻地把服務遷移到其餘的機器上，選擇資源有空餘的機器進行遷移。這樣能就保證服務是動態的調度，保證服務的高可用，而且這些都是它內部自行處理的，不須要手動干預。

Jenkins

介紹

Jenkins是Java開發的一種持續集成的工具，咱們在它的基礎上作了一些重複的工做，好比版本發佈、測試代碼，以及調用外部接口。Jenkins支持不少插件，能夠很方便地選擇使用適合本身團隊的插件工具。

問題

Jenkins爲咱們提供了便利，固然Jenkins自己也有它本身的問題，好比傳統的Jenkins是單點的，任務大可能是須要排隊的，若是每一個任務都本身建一套Jenkins的話，資源會很是浪費。爲了解決這些問題，咱們引入了Jenkins On Mesos。

Jenkins On Mesos

Jenkins 分爲Master 節點和Slave 節點，Master 進行調度，Slave節點負責負責執行Job任務。

Jenkins master

首先咱們把Jenkins的Master經過Marathon發佈，Marathon 去調用 Mesos Master，以後Mesos Master再去Slave節點起Jenkins的Master。這個機制保證了Jenkins Master的高可用，Marathon會監控Jenkins Master的健康狀態，當Jenkins Master出現崩潰掛掉，Marathon會自動再啓動一個Jenkins Master的任務。Jenkins Master使用Mesos整個大的資源池，Mesos的資源池是一個資源共享的狀態，資源利用率也會更高一些。

Jenkins Slave

Jenkins Master作的是調度，Jenkins Slave則是真正執行構建任務的地方。Jenkins Master會在Mesos Master上註冊一個它本身的Framework，若是有任務須要構建的話，Jenkins Master 會通知 Jenkins Framework 調用 Mesos Master構建一個任務。以後Mesos Master 再調用 Mesos Slave去起一個Jenkins Slave的節點去構建任務，它是實時的，用戶資源可能被分配到各個機器上，在不一樣的機器上並行存在。此外，Jenkins還具有動態調度功能，也就是說，當任務運行完後必定時間，資源會再返還給Mesos，實現合理地利用整個集羣的資源，提升集羣的資源利用率。

Mesos 總體流程

這張圖是Mesos總體的調度流程。第一步，它的集羣有三個Mesos Slave節點資源，資源上報到Mesos Master，Mesos Master收集到這些資源以後把這些資源再提供給Marathon，Marathon若是要發任務，它確認一個Offer1，Offer1足夠任務來運行，就拒絕其餘的Offer，並把這個任務發送給Mesos Master，以後Mesos Master去找Slave1起Marathon的任務。這是Marathon的任務啓動過程。Mesos自己能夠和多框架進行通訊，Jenkins Master要跑一個任務，Mesos Master一樣提供資源給Jenkins，提供的資源包括了Marathon 任務使用剩下的資源，好比Task1 確認的 Offer1沒有用完和沒有使用的資源，Mesos也會它提供給Jenkins。而Jenkins也會選擇，好比Jenkins選擇了Offer3，拒絕了其餘的Offer，把Jenksin的任務再經過Mesos Master去Mesos Slave中起起來。

Jenkins On Mesos Docker化

Jenkins部署起來很是麻煩，須要安裝各類依賴，若是代碼是從Git上下載的，那麼還須要安裝一些Git包。而動態調度須要每臺機器上都裝這些依賴，爲了解決這種問題，咱們把服務所有進行了Docker化，主機上只須要有Docker環境就能夠運行咱們的服務。

遇到的坑

進行Docker化以後就會面臨Docker化的問題，由於Docker和 Mesos都是比較新的技術，咱們遇到了不少坑，也須要去解決。

咱們遇到的第一個問題是Jenkinson Mesos須要調度Mesos的Lib庫，若是Docker化以後是隔離的，就調不到Mesos Lib。

第二個問題是Docker化的數據，由於Jenkins是沒有數據庫的，數據都是存在本地的JENKINS_HOME目錄中，若是Jenkins Master掛掉以後，相應的數據就沒有了。

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

解決

爲了解決這些問題，首先咱們將Mesos打成一個基礎鏡像，在這個基礎鏡像上安裝Jenkins的服務製做成一個Jenkins的鏡像，這樣就能夠調用Mesos的Lib庫文件了。

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

第三對於Jenkins升級或其插件的升級，咱們如今的作法是把它從新打一個鏡像，從新在Mararhton發佈Jenkins Master。

Jenkins Slave On Docker 工做流程

首先Jenkins Master若是要構建一個Job，讓Mesos Slave起一個Jenkins Slave這樣的容器，容器裏面是沒有Docker環境的，由於容器裏面再裝一個Docker環境就過重了。咱們如今的作法是把Jenkins Slave用到的命令掛載，其中包括 /usr/bin/docker /var/lib/docker /sys/fs/cgroup /var/run/docker.sock ，這樣在容器內部就能夠操做主機上的Docker環境，Jenkins Slave 能夠在容器內部進行一些Docker Build，Docker Run，Docker Push等工做。

Jenkins Job List

這是咱們運維平臺一些Job List，左下角是Mesos各個Slave的節點，每個節點上都有任務，這些任務都是並行的。由於咱們的服務模塊比較多，可能一個模塊一天提交十幾回，這麼多的模塊在一天提交幾十次或者上百次的狀況也出現過。手動更新、構建的話是很是難作到的。如今，作成Jenkins 分佈式執行Job的模式，一天構建幾百上千次也沒有問題，它會把構建的任務均勻的分佈在主機資源裏。

數人云運維平臺持續集成實踐

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

首先Jenkins觸發任務，Jenkins調用Configserver提供的API，這個API就去Github上獲取最新代碼的Tag，並對比現有的已經更新過的Tag。若是不須要更新，這個任務就完成了，結束了。若是須要更新的話，就進行第三步，把從Github拉的代碼放到Configserver上，Jenkins Slave的節點會從Configserver去拉取代碼到Slave的容器之中。把代碼下載以後再去Pull一個咱們編譯環境的鏡像，而後再用這個鏡像去編譯咱們的代碼。好比編譯出來一個二進制代碼，咱們把這個二進制從新打一個運行時的鏡像。這個Runtime鏡像打好以後咱們再使用Docker Push把它推到私有的Registry，鏡像Push到Registry後，就能夠發佈到各類的環境，好比說Dev Demo生產環境，調用Marathon API直接發佈就能夠了。一樣在Jenkins Slave，推完鏡像以後就能夠去調用。這樣一個總體構建鏡像再部署的任務就構建完成了。

若是有一些安裝包，好比咱們的Agent包，它不須要發佈Marathon，須要上傳到CDN，也是在Jenkins Slave 中執行的。

配置管理

問題

由於咱們引入了Docker，並且是分佈式動態調度的，傳統的配置工具如Ansible、Puppet 、SaltStack都已經不適用了，沒辦法去管理Docker內部的東西。這些配置文件修改起來很是麻煩。

配置中心一期

講一下如何進行配置的更新。首先咱們作了一個配置中心的一期，把鏡像嵌入本身的腳本，這個腳本實現的功能就是 根據傳入的ENV CONFIG_SERVER和 SERVICE ，訪問 Configserver的API，API返回的數據就是這個服務須要下載的配置文件的列表，以及它須要下載到哪一個目錄底下。Configserver也很是簡單，起一個Nginx，去Vim手動修改。容器一重啓，就會自動拉這些配置文件，把配置進行更新。

一期的問題

一期完成以後，由於是多種環境，如Dev Demo環境、預生產環境、生產環境等等，雖然把這些配置都在Configserver上集中配置，但還須要手動修改這些配置。手動修改容易出錯，例如Dev更新了一個服務，可能過了一週纔會更新到生產環境。那個時候再去修改生產就很容易出錯，致使沒法運行。此外，若是配置發生了Bug須要回滾，手動修改也是不合適的。

配置中心二期

爲了解決這些問題，咱們作了ConfigCenter的二期。其中有咱們本身開發的一個運維平臺，以及Github和Gitlab。Github是個存儲項目的代碼，Gitlab是用了存儲配置模板和最終配置文件的。咱們用Jenkins把它們總體的串起來，咱們的第一個工做是把全部的配置文件抽象化，各類環境的文件抽象出來一個模板，放在Gitlab上。它的數據是放在數據庫裏面，這樣組合起來是一個完整的配置文件。各個環境的值是不同的。 咱們的運維平臺觸發Jenkins，Jenkins去調度咱們的ConfigCenter API，它傳入兩個參數，一個是須要更新的環境，第二個是更新哪一個服務。以後API去作對比，從數據庫去讀現有的配置文件的模板Tag，再去讀新模板的Tag進行對比。若是這個文件須要更新，把它從數據庫拉過來，數據作匹配，渲染成咱們最終的配置文件，再傳到Gitlab上。剩下的經過Jenkins 觸發 Configserver去調Gitlab下載最新的配置文件到Configserver服務器，Jenkins再去調用Marathon去重啓服務，服務就會成功更新配置文件。

這裏有兩個須要注意的點，一方面模板須要更新，另外一方面值要更新，這是兩種模式。模板更新是全部的流程都要走一遍，若是模板沒有更新，只是值更新的話，咱們只須要在運維平臺上作修改。修改的同時它會作一個標記，說明這個服務配置文件是須要更新的，以後就會生成一個最新的配置繼續下面的操做。若是這兩個都不須要更新的話就返回，再也不操做。