企業(yè)級掃描平臺EOS-Jenkins集群進階之路

Jenkins 是一個用 Java 編寫的開源自動化工具，常用于持續(xù)集成的系統(tǒng)中。EOS—代碼質量檢測平臺，選用Jenkins實現(xiàn)遠程任務調度，完成掃描流程。然而，隨著EOS掃描工程類型及服務拓展，資源復用，Job數(shù)量、構建頻率及服務壓力激增，問題隨之而來。

• 如果單純的使用 Master 去構建，除了要承擔項目上的編譯、掃描分析等開銷外，還會影響Jenkins 應用本身占用 memory 和 CPU 資源。
• Jenkins支持Master-Slave分布式部署，將不同的Job下發(fā)到多臺機器執(zhí)行，提高jenkins處理能力，但是無法解決服務分布式部署。
• 隨著Job增多，增加Node Slave，面臨重新接入與配置的風險。
• 不同的業(yè)務類型，需要不同的Node配置，維護成本較大。
• 各業(yè)務線單獨維護Jenkins，存在資源重復使用的問題。

解決以上問題，我們設計了一套高可用的Jenkins分布式集群搭建方案。整體方案設計圖如下所示：

• 采用Jenkins分布式架構，Slave集群基于Lable管理：Jenkins Master 上管理Job，構建任務分配到不同的 Slave Node 上運行，提升了Master性能，提高構建速度。使用Label管理Slave集群，增強并發(fā)能力，提高了Slave 集群綜合資源利用率(Disk,CPU)。
• 基于Kubernetes的容器化實踐：基于容器化去構建 Jenkins ，實現(xiàn)按需彈性收縮；資源共享(所有的容器slave可以共享 Kubernetes Cluster)。
• 基于LVS負載均衡：整體方案采用LVS和Centos操作系統(tǒng)實現(xiàn)一個高性能，高可用的服務器群集。

該模塊是增強Jenkins并發(fā)能力、緩解構建壓力的核心。在介紹Jenkins分布式架構之前，先來看下簡化版的EOS-Server端掃描主流程:

• 用戶（手動或自動）在server端觸發(fā)指定項目開始掃描

• server端調起Jenkins服務

• clone代碼

• 執(zhí)行代碼掃描腳本，腳本端分析代碼（略。。。）

• 掃描結果返回server

可以清楚的看出，Jenkins在整個掃描流程中承擔了任務調度的作用。但

• 隨著接入項目的增加，Jenkins需要維護的Job數(shù)量，掃描分析壓力隨之增加。

• 隨著業(yè)務類型的拓展，各業(yè)務間編譯環(huán)境不統(tǒng)一，不能跨業(yè)務共享。

針對以上問題，我們通過Master-Slave分布式架構，Jenkins-Master創(chuàng)建Job，分配Job到指定Slave進行掃描分析。

該設計方案中以下問題值得思考：

Jenkins Slave 連接方式官網提供兩種方式：

• 通過 SSH 啟動 Slave 代理

  在 Jenkins 上直接配置，相當于從 Master 往 Slave 上連接，從 Master 上主動發(fā)起的請求。

• 通過 JNLP 啟動代理

  基于 Java Web Start 的 JNLP 的連接，從 Slave 往 Master 主動的方式。

結合后面的容器化方案，我們自己實現(xiàn)一套節(jié)點創(chuàng)建及節(jié)點連接自動化腳本，支持特殊節(jié)點及本地節(jié)點創(chuàng)建連接。

創(chuàng)建node

根據(jù)Lable自動創(chuàng)建node節(jié)點。

連接 master

創(chuàng)建node之后，在Jenkins Slave觸發(fā)connect_master腳本，使用JNIP方式主動連接Master。

連接完成效果展示：

2.Slaves如何提高資源利用率？

為解決業(yè)務間，編譯環(huán)境不統(tǒng)一，不能跨業(yè)務共享問題，我們掛載了較多Slave，但這一策略出現(xiàn)了資源利用率低的問題。

為提高資源利用率，我們將同編譯環(huán)境的 Slaves 添加相同 Label，同類型 Jobs 使用 Lable 進行構建，適量增大 Slave 的 executor 數(shù)目。

Kubernetes 作為一個用來對應用進行自動化部署、擴容和管理的容器編排引擎。將其與Jenkins分布式架構相結合，實現(xiàn)集群高可用，可擴展，有效降低維護及節(jié)點擴展成本。

制作 Jenkins Master 鏡像?？梢允褂?Jenkins 官網的上鏡像 Jenkins/Jenkins:lts；

制作Jenkins Slave 鏡像，可以使用官方提供的 Jenkins/ssh-Slave；

我們結合EOS業(yè)務實際情況制作了自己的Master和Slave鏡像。

鏡像制作部署流程：

1. 編寫 BaseDockerfile （基于Centos7安裝基礎依賴運行環(huán)境、安裝Jenkins環(huán)境）

2. FROM basedocker，編寫dockerfile

3. 構建打包 Docker 鏡像

4. 推送 Docker 鏡像到倉庫

5. 編寫 Kubernetes YAML 文件

6. 更改 YAML 文件中 Docker 鏡像 TAG

7. 利用Jdos部署

集群設計如下：

從上圖中可以看到 Jenkins Master 和 Jenkins Slave 以 Pod 形式運行在 K8s 集群的 Node 上。Master 運行在指定節(jié)點， 當Server觸發(fā)構建請求時，會觸發(fā)Jenkins Master API ，Jenkins k8s plugin 會根據(jù) Job 配置的 Label 動態(tài)創(chuàng)建一個運行在 Pod 中的 Jenkins Slave 并注冊到 Master 上，當 Job 結束后，這個 Slave 會被注銷并且這個 Pod 也會自動刪除，恢復到最初狀態(tài),這樣集群資源得到充分的利用。

監(jiān)控整個構建流程，發(fā)現(xiàn)存在構建時間長、部分Job構建不穩(wěn)定的問題，其中很大一部分原因是拉取外部依賴耗時且失敗率較高。

為了讓這個過程更加穩(wěn)定，采用以下方案：

采用LVS（負載均衡+高可用，采用技術：Ipvsadm+Keepalived；工作模式為：DR加權輪詢，即：DR+wrr）；它工作在網絡層，實現(xiàn)高性能，高可用的服務器集群，為客戶提供服務。

• LSV（主）調度機提供數(shù)據(jù)源（即：CFS）供集群中所有Jenkins Server使用；
  （完善不同業(yè)務類型所需數(shù)據(jù)源在不同業(yè)務類型對的基礎鏡像中放入優(yōu)先使用內部源的配置）

• LVS（從）做熱備調度機，同時做主數(shù)據(jù)源的異地備份（采用技術:Rsync+Inotify）

• 所有Jenkins Server需要掛載CFS 主提供的數(shù)據(jù)源工作（采用技術：Linux Mount 掛載CFS）

使用容器化方案以后，收益如下：

• 服務高可用。當 Jenkins Master 出現(xiàn)故障時， 會自動創(chuàng)建一個新的 Jenkins Master 容器。

• 資源共享。同一個 job，通過配置 Lable可以運行在不同的 Docker host。同一個Docker host 上配置多個 Docker image，不同的模板供不同的job使用。

• Slave 資源合理分配。Slave 按需彈性收縮，根據(jù)掃描需求去動態(tài)的生成一個 Docker 容器掛載為 Jenkins Slave 進行構建，構建結束以后，這個容器就會被自動銷毀。整個過程不再是原來那種普通的 Slave 長連接的方式掛載。實現(xiàn)容器Slave生命周期自動化，自動創(chuàng)建、使用、銷毀。

• Slave易擴展。當 K8s 集群的資源嚴重不足而導致 Job 排隊等待時，可以很容易的添加一個 Kubernetes Node 到集群中，從而實現(xiàn)擴展。