摘要：內(nèi)部長期使用來管理代碼。審核通過并且成功后，觸發(fā)靜態(tài)測試單元測試鏡像構(gòu)建鏡像部署集成測試等測試通過后，創(chuàng)建一個從到的，由負(fù)責(zé)人進(jìn)行審核。從圖中我們可以看到，部分是一個單元測試，預(yù)發(fā)布部署，集成測試，，提交代碼的循環(huán)過程。

UCloud內(nèi)部長期使用 Gitlab 來管理代碼。雖然Gitlab作為一套開源平臺已很優(yōu)秀，但我們對于其能為CI/CD提供的敏捷性并不十分滿意，內(nèi)部實(shí)踐中的代碼發(fā)布周期仍需按天計算。為此，我們打造了一個基于Kubernetes的內(nèi)部容器服務(wù)平臺（名為KUN），用于托管內(nèi)部服務(wù)，并將Gitlab對接到KUN平臺，從而借助Kubernetes的云原生優(yōu)勢，獲得更好的CI/CD效果。這套系統(tǒng)運(yùn)行一年內(nèi)，Gitlab的Pipeline一共觸發(fā)了994次，執(zhí)行了約20000+次Job，在測試環(huán)境和正式環(huán)境一共進(jìn)行了7000+次部署，即每天部署約20次。以下是該項(xiàng)目的一些實(shí)踐經(jīng)驗(yàn)。

我們對CI/CD的目標(biāo)

CI即Continuous Integration（持續(xù)集成），指代碼集成到主干之前必須通過自動化測試，只要有一個測試用例失敗，就不能集成。目的是讓產(chǎn)品快速迭代的同時還能保持高質(zhì)量。

CD有兩種意思：

• Continuous Delivery，持續(xù)交付，指的是任何的修改都經(jīng)過驗(yàn)證，可以隨時實(shí)施部署到生產(chǎn)環(huán)境。
• Continuous Deployment，持續(xù)部署，是持續(xù)交付的更高階段，指的是任何修改后的內(nèi)容都經(jīng)過驗(yàn)證，自動化的部署到生產(chǎn)環(huán)境。

兩者的區(qū)別，在于是否自動部署到生產(chǎn)環(huán)境。對UCloud而言，肯定要以后者，也就是持續(xù)部署為目標(biāo)。

Gitlab分支管理

我們采用的Gitlab分支管理模型在接入KUN平臺前后并未發(fā)生變化，故簡述如下：

• master：主分支，代碼經(jīng)過驗(yàn)證。從 master 創(chuàng)建 tag 進(jìn)行 Release。
• dev：研發(fā)主分支，用于合入特性分支和補(bǔ)丁分支，在此分支。
• 臨時分支：
• 特性分支：用于開發(fā)某個特性；
• 補(bǔ)丁分支：用于修復(fù)線上 bug。

下面以一個實(shí)例來介紹CI/CD開發(fā)流程。StepFlow是UCloud新近推出的一款可視化工作流產(chǎn)品，通過StepFlow用戶可以靈活便捷地定義自己的工作流，快速實(shí)現(xiàn)業(yè)務(wù)功能。整套StepFlow系統(tǒng)由多個模塊組成，并全部部署在Kubernetes集群上。

在實(shí)例中，我們需要開發(fā)其中名為optimize-allocate 的一個feature：

則開發(fā)流程為：

1. 首先，在 Gitlab 上創(chuàng)建了編號為80的Issue，跟進(jìn)這個optimize-allocate的feature；

2. 從dev分支創(chuàng)建一個新分支，名為feature/80-optimize-allocate，在該分支上進(jìn)行開發(fā)；

3. 在feature/80-optimize-allocate上開發(fā)完成，進(jìn)行commit，此時會觸發(fā)靜態(tài)測試、單元測試、Review等Pipeline Job；

4. 測試通過后，創(chuàng)建一個從feature/80-optimize-allocate到dev的merge request，由負(fù)責(zé)人進(jìn)行審核。審核通過并且merge成功后，觸發(fā)靜態(tài)測試、單元測試、鏡像構(gòu)建、鏡像部署、集成測試等Pipeline Job；

5. 測試通過后，創(chuàng)建一個從dev到master的mergerequest，由負(fù)責(zé)人進(jìn)行審核。審核通過并且merge成功后，負(fù)責(zé)人創(chuàng)建tag v1.1.1，然后觸發(fā)靜態(tài)測試、單元測試、鏡像構(gòu)建、鏡像部署、集成測試等Pipeline Job；

注：版本號tag是有命令規(guī)范的，v{x}.{y}.{z}代表著v{主版本}.{次版本}.{小修訂版本}

Gitlab CI/CD Pipeline

Gitlab 8.0版本以后，默認(rèn)集成并開啟了Gitlab-CI，是可以提供一定CI能力的，我們以此搭建持續(xù)集成的流水線，其中有Pipeline、Stage和Job三個層級需要設(shè)計。

Pipeline

Gitlab 會檢測一個項(xiàng)目的根目錄下的 .Gitlab-CI.yml 文件，用戶可在該文件中定義 CI/CD Pipeline，一個 Pipeline 代表了 CI/CD 的整個過程。代碼發(fā)生變化時（比如 push、tag、merge等），將觸發(fā)一個 Pipeline 的運(yùn)行。

Stage

一個 Pipeline 包含多個 Stage，比如“靜態(tài)檢查”、“單元測試”、“構(gòu)建鏡像”等等，這些 Stage 一個接一個順序執(zhí)行。

Job

每一個 Stage 可以包含多個 Job，同一個 Stage 的所有 Job 同時執(zhí)行。每個Job需指定若干個重要屬性如image, stage, tags, service等。

在StepFlow例子中，針對要開發(fā)的feature，其Pipeline設(shè)計如下，包括靜態(tài)檢查、單元測試和最后的兩個手動 Code Review：

當(dāng)其需要發(fā)布到公共測試環(huán)境（類似預(yù)發(fā)布環(huán)境），則設(shè)計另一個Pipeline，包括：執(zhí)行完整的靜態(tài)檢查, 單元測試, 預(yù)發(fā)布鏡像 build, 預(yù)發(fā)布部署, 預(yù)發(fā)布集成測試。

而合并 master 之后觸發(fā) prod 環(huán)境的另一個 Pipeline，包括靜態(tài)檢查、生產(chǎn)環(huán)境鏡像的 build、生產(chǎn)環(huán)節(jié)的部署、最后集成測試：

Gitlab Runner

我們將Gitlab Runner和Gitlab-CI配合使用，負(fù)責(zé)具體 Job 的運(yùn)行。Gitlab Runner Kubernetes Executor 提供了在 Kubernetes 中運(yùn)行 Job 的能力。運(yùn)行原理如下：

• Gitlab Runner 需要事先部署并注冊到 Gitlab 上；
• 當(dāng)代碼發(fā)生更新時，Gitlab 根據(jù)用戶的配置，通知 runner 來運(yùn)行 Job；
• Gitlab Runner 使用某個鏡像來創(chuàng)建一個 Pod，然后在其中運(yùn)行某些命令；
• Gitlab Runner 將整個運(yùn)行過程以及運(yùn)行結(jié)果告訴 Gitlab。

Kaniko集成和改造：在容器中構(gòu)建Docker鏡像

為了使用 CI/CD 將代碼變成最終運(yùn)行在 Kubernetes 中的服務(wù)，必不可少的一步就是容器鏡像的構(gòu)建。由于CI Job本身就是以容器的形式運(yùn)行的，所以需要在容器中構(gòu)建出 Docker 鏡像。

已有的方法，包括把 Host 上的 Docker Socket 掛載到 Pod 里面去（Docker Socket Mounting），或者是在 Pod 再啟動一個 Docker Daemon（Docker-in-Docker），然而，前者有安全風(fēng)險，后者需要 Pod 具備特權(quán)，兩種方法都不適合。

Kaniko（https://github.com/GoogleContainerTools/kaniko）是 Google開源的一個工具，可以實(shí)現(xiàn)在 docker 容器里面制作 docker 鏡像，并且不需要任何特權(quán)。

但是原生的 Kaniko 鏡像由于缺少一些必要的工具，無法和Gitlab CI集成。為此我們修改了Kaniko鏡像，添加了整個busybox工具包進(jìn)去，以支持其作為一個CI Job來運(yùn)行。然后就可以把Gitlab往內(nèi)部容器服務(wù)平臺KUN對接了。代碼示例如下:

# use Docker:$ cd /path/to/project &&  docker build -t uhub.service.ucloud.cn/myimage:0.0.1 -f deploy/Dockerfile &&  docker push uhub.service.ucloud.cn/myimage:0.0.1# use Kaniko:$ /kaniko/executor -c /path/to/project -f deploy/Dockerfile -d uhub.service.ucloud.cn/myimage:0.0.1

KUN+Gitlab：基于Kubernetes的CI/CD流程

KUN中CI/CD的整個流程如上圖所示。從圖中我們可以看到，CI部分是一個單元測試，預(yù)發(fā)布部署，集成測試，Debug，提交代碼的循環(huán)過程。在CI過程中預(yù)發(fā)布的部署是通過CD系統(tǒng)來實(shí)現(xiàn)的，CI其中一個步驟是生成部署文件，然后按照項(xiàng)目、資源集、版本等參數(shù)提交到CD后端系統(tǒng)。CD系統(tǒng)提供了頁面入口，當(dāng)部署文件推送到CD系統(tǒng)后，用戶可以在頁面查找對應(yīng)的部署文件。如果需要部署，在頁面點(diǎn)擊“部署”按鈕即可實(shí)現(xiàn)部署。

YAML編輯器

為方便用戶使用，我們?yōu)镵UN開發(fā)了專門的YAML編輯器，相比用普通的文本編輯器寫YAML，可以提供智能模板補(bǔ)全、搜索替換等能力。

上圖展示了一個使用案例，目前頁面編輯器支持的功能有：

• Snippet：模版補(bǔ)全，用戶編輯文檔時，會提示相關(guān)模版，可選擇直接模版輸入

• Hover：用戶鼠標(biāo)放置關(guān)鍵字，提示關(guān)鍵字含義和官方文檔鏈接

• 搜索替換：使用?+F/Ctrl+F打開頁面搜索支持頁面直接查詢

部署系統(tǒng)

為了在Gitlab CI Job中把服務(wù)部署到Kubernetes上，我們研發(fā)了部署系統(tǒng)。在CI Pipeline的最后一步，用戶生成一個YAML文件，定義需要部署到Kubernetes上的資源，然后使用部署系統(tǒng)提供的一個工具鏡像，該鏡像會調(diào)用部署系統(tǒng)的API，將YAML提交給部署系統(tǒng)。接下來部署系統(tǒng)將使用用戶的權(quán)限，調(diào)用Kubernetes API實(shí)現(xiàn)真正的部署。

目前部署系統(tǒng)主要包含兩部分功能：

1. 資源集管理：

• 資源集是用戶項(xiàng)目下一個或多個資源的集合，資源指 Kubernetes 的 object 的描述文件，一般為 YAML 文件；
• 資源集分為多個版本，不同的版本對應(yīng)資源的不同的描述文件；
• 用戶可以選擇某個版本，然后指定集群執(zhí)行部署。

2. 部署任務(wù)

• 用戶每次部署都會生成一個 job，就是部署任務(wù)
• 執(zhí)行部署后，用戶可在任務(wù)詳情頁直接查看部署任務(wù)日志。

當(dāng)完成上述所有工作，Gitlab能很好嵌入KUN平臺，運(yùn)行在Kubernetes上的各模塊就可像齒輪一樣有序運(yùn)轉(zhuǎn)，從而獲得CI/CD上的良好效果。

前面提到的StepFlow項(xiàng)目，從一開始就實(shí)施了這樣一套 CI/CD，效率獲得了很大提升，每個編譯Job耗時約3分鐘，其他Job耗時在1分鐘以內(nèi)。

總結(jié)

CI/CD是提供高質(zhì)量互聯(lián)網(wǎng)服務(wù)必不可少的一環(huán)。Gitlab和Kubernetes都是非常優(yōu)秀的開源軟件，在此基礎(chǔ)上，我們根據(jù)自己的實(shí)際情況，結(jié)合兩者打造了一套高效的CI/CD平臺，努力提升研發(fā)效率，為用戶提供更優(yōu)質(zhì)的服務(wù)。