UCloud內部長期使用 Gitlab 來管理程式碼。雖然Gitlab作為一套開源平臺已很優秀，但我們對於其能為CI/CD提供的敏捷性並不十分滿意，內部實踐中的程式碼釋出週期仍需按天計算。為此，我們打造了一個基於Kubernetes的內部容器服務平臺（名為KUN），用於託管內部服務，並將Gitlab對接到KUN平臺，從而藉助Kubernetes的雲原生優勢，獲得更好的CI/CD效果。這套系統執行一年內，Gitlab的Pipeline一共觸發了994次，執行了約20000+次Job，在測試環境和正式環境一共進行了7000+次部署，即每天部署約20次。以下是該專案的一些實踐經驗。

我們對CI/CD的目標

CI即Continuous Integration（持續整合），指程式碼整合到主幹之前必須通過自動化測試，只要有一個測試用例失敗，就不能整合。目的是讓產品快速迭代的同時還能保持高質量。

CD有兩種意思：

Continuous Delivery，持續交付，指的是任何的修改都經過驗證，可以隨時實施部署到生產環境。 Continuous Deployment，持續部署，是持續交付的更高階段，指的是任何修改後的內容都經過驗證，自動化的部署到生產環境。 兩者的區別，在於是否自動部署到生產環境。對UCloud而言，肯定要以後者，也就是持續部署為目標。

Gitlab分支管理

我們採用的Gitlab分支管理模型在接入KUN平臺前後並未發生變化，故簡述如下：

master：主分支，程式碼經過驗證。從 master 建立 tag 進行 Release。 dev：研發主分支，用於合入特性分支和補丁分支，在此分支。

臨時分支： 特性分支：用於開發某個特性； 補丁分支：用於修復線上 bug。 下面以一個例項來介紹CI/CD開發流程。StepFlow是UCloud新近推出的一款視覺化工作流產品，通過StepFlow使用者可以靈活便捷地定義自己的工作流，快速實現業務功能。整套StepFlow系統由多個模組組成，並全部部署在Kubernetes叢集上。

在例項中，我們需要開發其中名為optimize-allocate 的一個feature：

則開發流程為：

1. 首先，在 Gitlab 上建立了編號為80的Issue，跟進這個optimize-allocate的feature；

2. 從dev分支建立一個新分支，名為feature/80-optimize-allocate，在該分支上進行開發；

3. 在feature/80-optimize-allocate上開發完成，進行commit，此時會觸發靜態測試、單元測試、Review等Pipeline Job；

4. 測試通過後，建立一個從feature/80-optimize-allocate到dev的merge request，由負責人進行稽核。稽核通過並且merge成功後，觸發靜態測試、單元測試、映象構建、映象部署、整合測試等Pipeline Job；

5. 測試通過後，建立一個從dev到master的mergerequest，由負責人進行稽核。稽核通過並且merge成功後，負責人建立tag v1.1.1，然後觸發靜態測試、單元測試、映象構建、映象部署、整合測試等Pipeline Job；

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

Gitlab CI/CD Pipeline

Gitlab 8.0版本以後，預設整合並開啟了Gitlab-CI，是可以提供一定CI能力的，我們以此搭建持續整合的流水線，其中有Pipeline、Stage和Job三個層級需要設計。

Pipeline

Gitlab 會檢測一個專案的根目錄下的 .Gitlab-CI.yml 檔案，使用者可在該檔案中定義 CI/CD Pipeline，一個 Pipeline 代表了 CI/CD 的整個過程。程式碼發生變化時（比如 push、tag、merge等），將觸發一個 Pipeline 的執行。

Stage

一個 Pipeline 包含多個 Stage，比如“靜態檢查”、“單元測試”、“構建映象”等等，這些 Stage 一個接一個順序執行。

Job

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

在StepFlow例子中，針對要開發的feature，其Pipeline設計如下，包括靜態檢查、單元測試和最後的兩個手動 Code Review：

當其需要釋出到公共測試環境（類似預釋出環境），則設計另一個Pipeline，包括：執行完整的靜態檢查, 單元測試, 預釋出映象 build, 預釋出部署, 預釋出整合測試。

而合併 master 之後觸發 prod 環境的另一個 Pipeline，包括靜態檢查、生產環境映象的 build、生產環節的部署、最後整合測試：

Gitlab Runner

我們將Gitlab Runner和Gitlab-CI配合使用，負責具體 Job 的執行。Gitlab Runner Kubernetes Executor 提供了在 Kubernetes 中執行 Job 的能力。執行原理如下：

Gitlab Runner 需要事先部署並註冊到 Gitlab 上； 當代碼發生更新時，Gitlab 根據使用者的配置，通知 runner 來執行 Job； Gitlab Runner 使用某個映象來建立一個 Pod，然後在其中執行某些命令； Gitlab Runner 將整個執行過程以及執行結果告訴 Gitlab。

Kaniko整合和改造：在容器中構建Docker映象

為了使用 CI/CD 將程式碼變成最終執行在 Kubernetes 中的服務，必不可少的一步就是容器映象的構建。由於CI Job本身就是以容器的形式執行的，所以需要在容器中構建出 Docker 映象。

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

Kaniko（https://github.com/GoogleContainerTools/kaniko）是 Google開源的一個工具，可以實現在 docker 容器裡面製作 docker 映象，並且不需要任何特權。

但是原生的 Kaniko 映象由於缺少一些必要的工具，無法和Gitlab CI整合。為此我們修改了Kaniko映象，添加了整個busybox工具包進去，以支援其作為一個CI Job來執行。然後就可以把Gitlab往內部容器服務平臺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部分是一個單元測試，預釋出部署，整合測試，Debug，提交程式碼的迴圈過程。在CI過程中預釋出的部署是通過CD系統來實現的，CI其中一個步驟是生成部署檔案，然後按照專案、資源集、版本等引數提交到CD後端系統。CD系統提供了頁面入口，當部署檔案推送到CD系統後，使用者可以在頁面查詢對應的部署檔案。如果需要部署，在頁面點選“部署”按鈕即可實現部署。

YAML編輯器

為方便使用者使用，我們為KUN開發了專門的YAML編輯器，相比用普通的文字編輯器寫YAML，可以提供智慧模板補全、搜尋替換等能力。

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

Snippet：模版補全，使用者編輯文件時，會提示相關模版，可選擇直接模版輸入

Hover：使用者滑鼠放置關鍵字，提示關鍵字含義和官方文件連結

搜尋替換：使用⌘+F/Ctrl+F開啟頁面搜尋支援頁面直接查詢

部署系統

為了在Gitlab CI Job中把服務部署到Kubernetes上，我們研發了部署系統。在CI Pipeline的最後一步，使用者生成一個YAML檔案，定義需要部署到Kubernetes上的資源，然後使用部署系統提供的一個工具映象，該映象會呼叫部署系統的API，將YAML提交給部署系統。接下來部署系統將使用使用者的許可權，呼叫Kubernetes API實現真正的部署。

目前部署系統主要包含兩部分功能：

1. 資源集管理：

資源集是使用者專案下一個或多個資源的集合，資源指 Kubernetes 的 object 的描述檔案，一般為 YAML 檔案； 資源集分為多個版本，不同的版本對應資源的不同的描述檔案； 使用者可以選擇某個版本，然後指定叢集執行部署。

2. 部署任務

使用者每次部署都會生成一個 job，就是部署任務 執行部署後，使用者可在任務詳情頁直接檢視部署任務日誌。

當完成上述所有工作，Gitlab能很好嵌入KUN平臺，執行在Kubernetes上的各模組就可像齒輪一樣有序運轉，從而獲得CI/CD上的良好效果。

前面提到的StepFlow專案，從一開始就實施了這樣一套 CI/CD，效率獲得了很大提升，每個編譯Job耗時約3分鐘，其他Job耗時在1分鐘以內。

總結

CI/CD是提供高質量網際網路服務必不可少的一環。Gitlab和Kubernetes都是非常優秀的開源軟體，在此基礎上，我們根據自己的實際情況，結合兩者打造了一套高效的CI/CD平臺，努力提升研發效率，為使用者提供更優質的服務。

相關推薦