本文從目前業(yè)界實現(xiàn)Jenkins的高可用的實現(xiàn)方案,分析各方案的優(yōu)缺點,引入vivo目前使用的Jenkins高可用方案,以及目前Jenkins資源的調(diào)度方案的設(shè)計實踐和目前的落地運行效果。
一、前言
現(xiàn)在的企業(yè)很多都在用Jenkins做持續(xù)集成,各個業(yè)務(wù)端都依靠Jenkins,vivo Devops也是使用Jenkins來進(jìn)行持續(xù)構(gòu)建,部署Jenkins服務(wù)時如何保障服務(wù)的高可用變得尤為重要。
下面是目前Jenkins存在的一些問題。
Jenkins本身是單體的,即只能有一個Jenkins Master。雖然你也可以在多臺機器上部署多個Jenkins Master,但這些Master之間沒有聯(lián)系,都是各自把任務(wù)交給手下的slave去執(zhí)行,沒有任何交集。
也許某個master下的slave很忙,而另一個master下的slave卻很閑,資源得不到充分利用。
當(dāng)其中一個slave宕機之后,該slave上的運行的job任務(wù)沒有版本重新進(jìn)行分配,需要用戶重新執(zhí)行。并且slave節(jié)點離線之后沒有通知管理員。
當(dāng)系統(tǒng)業(yè)務(wù)量比較大的時候業(yè)務(wù)請求集中在Jenkins Master上,會對Jenkins造成壓力,甚至的造成Jenkins服務(wù)不可用。
當(dāng)有job任務(wù)在jenkins Master上隊列排隊的時候,Jenkins Master宕機后,隊列任務(wù)不可持久化。
Jenkins Workspace沒有自動清理功能,會導(dǎo)致磁盤空間不足,任務(wù)執(zhí)行不了的情況。
基于以上情況,vivo Devops對Jenkins的部署架構(gòu)進(jìn)行優(yōu)化搭建,并且配套了一套Jenkins資源調(diào)度系統(tǒng)用于管理Jenkins資源。
二、業(yè)界實現(xiàn)
目前業(yè)界也包含一些Jenkins 高可用的設(shè)計方式,但是并不能完全的滿足解決上述問題,比如:
2.1 方案一 Gearman + Jenkins
這是OpenStack團隊使用的方案。這個方案使用了gearman, gearman是個任務(wù)分發(fā)框架。
需要在每個Master上安裝好gearman的插件,并配置好能連接到gearman server,同時在每個Master必須建立相同的job。
之后運行任務(wù)的流程如下:
gearman worker運行在各個Jenkins Master中等待gearman server分發(fā)任務(wù);
gearman client向gearman server發(fā)出運行job的請求;
gearman server通知各個gearman worker有任務(wù)拉,第一個閑著的worker會接受任務(wù),如果所有的worker都忙,則放入gearman的任務(wù)隊列,得worker空閑時再分配;
gearman worker閑下來后會從任務(wù)隊列里取job來執(zhí)行,執(zhí)行完之后,將結(jié)果發(fā)回給gearman server;
gearman server將結(jié)果返回給 gearman client。
優(yōu)點:
這樣各個salver資源可以得到充分利用,某個master掛掉另外的master可以繼續(xù)服務(wù)。
弊端:
每個master的slave必須配置一致,否則會造成job調(diào)度錯誤,同時會造成一些資源的浪費。當(dāng)一個master出現(xiàn)問題,該master的任務(wù)不會進(jìn)行自動重新分配。
2.2 方案二 改造Jenkins的文件存儲方式
目前Jenkins的配置文件都是直接在硬盤上以文件形式存儲的,你在JENKINS_HOME的個文件夾下能看到各種.xml文件。
有些公司在Jenkins上進(jìn)行二次開發(fā),將Jenkins的數(shù)據(jù)存儲方式改為數(shù)據(jù)庫存儲,這樣前端可以起多個Jenkins服務(wù),后端連相同的數(shù)據(jù)庫即可。數(shù)據(jù)庫也有比較成熟的高可用方案。
優(yōu)點:
可以達(dá)到Jenkins的高可用也就是某個master掛掉另外的master可以繼續(xù)服務(wù)。
弊端:
需要對Jenkins進(jìn)行二次開發(fā),使用數(shù)據(jù)庫會降低讀取資源效率下降。
2.3方案三 最簡單的Jenkins一主一備模式
平時讓Jenkins A機器提供服務(wù),并使用SCM Sync configuration plugin保存數(shù)據(jù),JenkinsA機器修改配置后觸發(fā)Jenkins B更新配置,一旦Jenkins A出現(xiàn)問題掛掉后,切換到備機Jenkins B上。
優(yōu)點:
可以達(dá)到Jenkins的高可用,當(dāng)master宕機后會進(jìn)行切換到備機上。
弊端:
會有一批Jenkins備機存在資源浪費,切換master時間過長,會導(dǎo)致有段時間Jenkins服務(wù)不可用。
三、vivo Jenkins Scheduler系統(tǒng)目標(biāo)
由于目前業(yè)界的一些實現(xiàn)還不能完全的滿足我們目前的需求,所以我們進(jìn)行了vivo jenkins scheduler系統(tǒng)的設(shè)計與實現(xiàn)。該系統(tǒng)需要達(dá)到如下的目的:
提升整個構(gòu)建服務(wù)可靠性時長。
保證jenkins集群的高可用,解決目前master-slave的單點問題,保證整個構(gòu)建服務(wù)的可靠性時長。
降低災(zāi)難時服務(wù)恢復(fù)時長。
①提供精準(zhǔn)流控方式,在jenkins構(gòu)建出現(xiàn)請求量過高的時候可以進(jìn)行流控和持久化操作,減少對目前系統(tǒng)的沖擊。
②當(dāng)系統(tǒng)壓力減少后,放開流控可以快速的對堆積的請求進(jìn)行分配執(zhí)行。
有效分配任務(wù)至各個子節(jié)點,保證資源的有效利用。
能保證災(zāi)難時的及時切換任務(wù)至可用節(jié)點上,同時能快速的通知管理員進(jìn)行處理。
能進(jìn)行數(shù)據(jù)的可視化分析,能提供一系列幫助改善開發(fā)效率的視圖,比如構(gòu)建時長報表、構(gòu)建量報表等。
四、 vivo Jenkins Scheduler設(shè)計
該系統(tǒng)我們從兩大部分進(jìn)行了設(shè)計,首先,我們不采用原生的Jenkins部署方案,而是采用全master的方式。第二,設(shè)計并開發(fā)了一套用于管理Jenkins集群的調(diào)度系統(tǒng)。
五、底層 Jenkins 工具部署方案
不采用目前單master的搭建方案,采用多master的搭建方案,master下不進(jìn)行掛載slave機器,任務(wù)直接有master進(jìn)行處理,master之間的關(guān)系、任務(wù)分配、離線、插件安裝等由調(diào)度系統(tǒng)進(jìn)行管理。這樣由于vivo Jenkins Scheduler系統(tǒng)為高可用的,解決了目前Jenkins的單點問題。
六、系統(tǒng)架構(gòu)圖
七、系統(tǒng)說明
7.1 API-Gateway
主要提供系統(tǒng)的外部請求,網(wǎng)關(guān)系統(tǒng),功能包含:
權(quán)限校驗:校驗用戶發(fā)送集群管理系統(tǒng)的請求的權(quán)限。
智能路由:接收外部一切請求,并轉(zhuǎn)發(fā)到后端的外服上去。
限流:與監(jiān)控線程配合(當(dāng)構(gòu)建請求達(dá)到某個閾值時),進(jìn)行限流操作。
API日志統(tǒng)一收集:類似于一個aspect切面,記錄接口的進(jìn)入和出去時的相關(guān)日志。
數(shù)據(jù)處理:對請求的參數(shù)進(jìn)行數(shù)據(jù)的轉(zhuǎn)換處理。
7.2 事件中心
是整個系統(tǒng)通信調(diào)用的主要模塊,采用的是Spring的Event機制實現(xiàn),主要核心事件如下:
Jenkins注冊事件
(EVENT_REGIST_JENKINS):
Jenkins啟動后,通過自定的插件會向系統(tǒng)發(fā)送注冊請求時,系統(tǒng)接收到后會觸發(fā)Jenkins管理模塊將Jenkins的信息注冊至調(diào)度系統(tǒng)中。
Jenkins宕機事件
(EVENT_DOWN_JENKINS) :
監(jiān)控管理輪詢檢查Jenkins狀態(tài),當(dāng)發(fā)現(xiàn)有Jenkins宕機的情況會觸發(fā)該事件,Jenkins管理模塊處理將Jenkins的信息狀態(tài)設(shè)置為不可用狀態(tài),從而是任務(wù)不能分配至該臺jenkins。
任務(wù)從分配事件 (EVENT_JOB_REDO) :
當(dāng)Jenkins宕機后,如果該臺jenkins上存在未執(zhí)行完的任務(wù)時候,由job監(jiān)控模塊觸發(fā),job管理莫管處理,會對該Jenkins上未執(zhí)行的job進(jìn)行重新分配。
任務(wù)接受事件 (EVENT_JOB_RECIVE) :
當(dāng)job管理模塊接受到創(chuàng)建請求,會觸發(fā)該事件,由job管理模塊放入Redis執(zhí)行隊列。
任務(wù)執(zhí)行事件 (EVENT_JOB_EXECUTE) :
job管理模塊中的執(zhí)行線程(10s執(zhí)行一次,會從Redis隊列中彈出任務(wù)),彈出任務(wù)后觸發(fā)該事件,由調(diào)度中心選取合適的jenkins進(jìn)行執(zhí)行。
7.3 調(diào)度中心
是整個系統(tǒng)的核心模塊,主要的功能是進(jìn)行執(zhí)行job時候能選取合適的jenkins進(jìn)行處理任務(wù),包含兩個核心算法:
7.3.1 Jenkins分組算法
每臺jenkins都可以使用標(biāo)簽的方式,打上多個標(biāo)簽,比如jenkins可以構(gòu)建java程序,使用的構(gòu)建工具可以是maven和gradle,這個時候我們就可以給其打上java、maven、gradle三個標(biāo)簽。
標(biāo)簽的維度主要有以下幾個:
標(biāo)簽配置: 判斷構(gòu)建配置是否配置了標(biāo)簽,根據(jù)標(biāo)簽選擇對應(yīng)標(biāo)簽的Jenkins,比如配置了(docker等)。
構(gòu)建語言: 根據(jù)構(gòu)建配置的語言,比如Java、C++、Python、Go等。
構(gòu)建工具和版本: 比如Maven、gradle、Ant,Cmark、Blade等。
JDK版本:比如JDK7、JDK8等。
Go語言版本:比如1.15.x.、1.16.x等。
GCC版本:如6.x、4.x等。
Python版本:2.x、3.x等。
是否存活:判斷Jenkins是否存活,如果宕機直接過濾。
(可選策略)選擇執(zhí)行過該job的Jenkins,減少下載代碼的過程:(第一次構(gòu)建還是會比較慢,可以采用預(yù)執(zhí)行的方式,在配置構(gòu)建配置的時候,就預(yù)先執(zhí)行一次,這樣在用戶執(zhí)行的時候就使用該job執(zhí)行過得workspace,減少代碼下載的時間)。
(可選策略)根據(jù)job的構(gòu)建的平均構(gòu)建時長,如果構(gòu)建時長達(dá)到某個配置閾值時,優(yōu)先選擇構(gòu)建器空閑多的Jenkins進(jìn)行執(zhí)行,并指出Jenkins的鎖定功能。其他的job不允許分配上來。
如果我們給Jenkins打上標(biāo)簽,那么我們就可以使用標(biāo)簽為維度將Jenkins進(jìn)行分組,并且存入至Redis中緩存,方便后續(xù)選取Jenkins用來執(zhí)行任務(wù):
7.3.2 Jenkins選取算法
當(dāng)Jenkins分組好了后,我們接受到執(zhí)行的job的信息就可以使用Jenkins選取算法進(jìn)行快速的選取合適的Jenkins進(jìn)行處理job,如下圖所示。
其中l(wèi)abel子線程、語言子線程……就是我們上面的Jenkins分組的維度,有多少維度,那么這里就會有多少子線程處理。
構(gòu)建任務(wù)進(jìn)入主線程,然后主線程會按照分組維度分組操作并進(jìn)行過濾,然后獲取到每個分組中合適的Jenkins,再進(jìn)行取交集(這個時候就獲取到可以執(zhí)行該構(gòu)建任務(wù)的Jenkins了),在判斷是否需要經(jīng)過可選策略,最終得到Jenkins。
7.4 流控管理&隊列管理
調(diào)度系統(tǒng)中的的任務(wù)接受采用的是隊列的方式實現(xiàn),當(dāng)系統(tǒng)請求量達(dá)到閥后,系統(tǒng)將不會進(jìn)入Redis隊列,會將請求持久化至MySQL。
后續(xù)如果有請求過來,job管理模塊會檢查數(shù)據(jù)庫MySQL中是否有請求,如果有請求,會將請求放入Redis隊列,如果沒有請求就會將當(dāng)前請求放入Redis隊列,具體流程如下:
其中基于Redis實現(xiàn)的消息隊列的時序圖如下:
7.5 回調(diào)中心
該模塊主要是監(jiān)控任務(wù)的狀態(tài),當(dāng)任務(wù)開始執(zhí)行、中斷執(zhí)行、執(zhí)行成功、執(zhí)行失敗的時候進(jìn)行通知業(yè)務(wù)并存儲數(shù)據(jù),用于保存構(gòu)建記錄,方便后續(xù)數(shù)據(jù)的統(tǒng)計,用來完成數(shù)據(jù)的可視化。
八、實施效果
目前該系統(tǒng)已經(jīng)投入生產(chǎn)環(huán)境運行,Jenkins任務(wù)已采用調(diào)度系統(tǒng)進(jìn)行調(diào)度執(zhí)行,運行穩(wěn)定,運行效果。
九、后續(xù)展望
隨著vivo Jenkins 調(diào)度系統(tǒng)的功能慢慢完善,Jenkins的機器也越來越多,目前還大多數(shù)運行在虛擬機上,從資源利用率和業(yè)務(wù)發(fā)布效率來看,未來的業(yè)務(wù)發(fā)布形態(tài)將會是以容器為主。目前公司也在大力發(fā)展k8s的容器生態(tài)建設(shè),
所以我們希望將Jenkins工具后期進(jìn)行容器化、池化,在提高資源利用率和發(fā)布效率的同時也可以為用戶提供可靠的、簡潔的、穩(wěn)定調(diào)度執(zhí)行。
審核編輯:劉清
-
數(shù)據(jù)存儲
+關(guān)注
關(guān)注
5文章
1008瀏覽量
52203 -
python
+關(guān)注
關(guān)注
56文章
4849瀏覽量
89126 -
MYSQL數(shù)據(jù)庫
+關(guān)注
關(guān)注
0文章
96瀏覽量
10134 -
API串口
+關(guān)注
關(guān)注
0文章
13瀏覽量
4932 -
gcc編譯器
+關(guān)注
關(guān)注
0文章
78瀏覽量
3889
原文標(biāo)題:vivo自研Jenkins資源調(diào)度系統(tǒng)設(shè)計與實踐
文章出處:【微信號:OSC開源社區(qū),微信公眾號:OSC開源社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
Arbor Networks推出Pravail可用性保護系統(tǒng)
企業(yè)服務(wù)器網(wǎng)絡(luò)的可用性設(shè)計
Jenkins遠(yuǎn)程部署Linux服務(wù)器的過程
基于開源系統(tǒng)的高可用性集群應(yīng)用

云計算平臺對PACS的高可用性支持
如何確保冗余云存儲的可用性
Sentinel如何通過限流實現(xiàn)服務(wù)的高可用性
如何使用馬爾可夫鏈與服務(wù)質(zhì)量提高網(wǎng)絡(luò)可用性的性能模型說明

如何確保SQL Server在云端的高可用性
在線服務(wù)提供商利用Brocade提高數(shù)據(jù)中心的可用性和可靠性

華為云耀云服務(wù)器 L 實例:保障網(wǎng)站的穩(wěn)定性和高可用性

評論