Gitlab-CI使用及.gitlab-ci.yml配置入門一篇就夠了

轉載：Gitlab-CI使用及.gitlab-ci.yml配置入門一篇就夠了 - 簡書 (jianshu.com)

一、 Gitlab-CI/CD使用場景

首先，公司使用Gitlab作為工作倉庫進行代碼發布及版本控制，Gitlab內置了CI/CD的工具，這些工具可以用於代碼提交的同時完成鏡像構建、自動化測試、自動化部署等連續的工作：

• CI: Continuous Integration（持續集成）
• CD: Continuous Delivery（連續交付）
• CD: Continuous Deployment（持續部署）
  這里暫時只討論CI持續集成部分的工作，我們常用CI來做一些自動化工作，這種自動化工作會運行在一台集中的機器上，比如程序鏡像的打包，單元測試，部署等，它可以節省項目開發迭代過程中維護正確的代碼所耗費的時間。

例比如CI中自動測試，在多人協同開發的過程中，可能會有頻繁的不同分支的代碼推送更新，使用CI管道，可在代碼發布的同時觸發CI中定義的單元測試操作，以便於在開發早期發現錯誤，從而確保所有新代碼的提交都不影響項目功能。

二、 了解Gitlab-CI/CD工作流

參考下圖先了解CI/CD的具體工作流和概念，黃色部分為主要涉及的概念，將在后文重點說明：

 

 

 

CI/CD工作流

1. 你當前的代碼庫托管在Gitlab上， 且已經為代碼倉庫配置了gitlab-runner服務, 它是用來實際執行CI任務的服務器；
2. 提交代碼，且根目錄中包含一個名為.gitlab-ci.yml文件，該文件是用來指定構建、測試和部署流程、以及CI觸發條件的腳本，其概念類似於docker-compose.yml文件；
3. Gitlab檢測到.gitlab-ci.yml文件，若當前提交符合文件中指定的觸發條件，則會使用配置的gitlab-runner服務運行該腳本進行測試等工作；
4. 若.gitlab-ci.yml中定義的某個自動化腳本運行失敗，將判定為此次CI不通過，則需要提交者修復問題代碼后重復提交，直至自動化CI通過。
5. 沒有問題的提交才能被項目負責人merge到主分支，進行后續的部署工作（此文暫不涉及CD自動化部署）

三、 如何編寫.gitlab-ci.yml文件

.gitlab-ci.yml文件中指定了CI的觸發條件、工作內容、工作流程，編寫和理解此文件是CI實戰中最重要的一步，該文件指定的任務內容總體構成了1個pipeline、1個pipeline包含不同的stage執行階段、每個stage包含不同的具體job腳本任務。

.gitlab-ci.yml示例文件及常用說明

 

 

 

.gitlab-ci.yml編寫示例

Pipeline說明

一個.gitlab-ci.yml文件觸發后會形成一個pipeline任務流由gitlab-runner來運行處理，pipeline中stage、job概念如下，需要按照項目實際情況定義不同stage和job， 自己繪制了一個流程示意圖幫助理解:

 

 

 

 

pipeline示意圖

示例 .gitlab-ci.yml文件運行順序及邏輯說明

按1.所示在項目根目錄中編寫好yml文件，

1. 首先綠色方框中定義了stage的階段順序，總共定義了3個階段，按順序依次命名為build、test、deploy；

2. 第一個藍色方框定義了build階段的一個job，該job僅在tags階段的分支提交時觸發，執行script中的腳本，按照DockerfileCI文件將項目打包為成名為img的鏡像，並推送到倉庫中，然后移除本地鏡像；

3. 第二個藍色方框定義了test階段的一個job，該job沒有限制觸發條件，將在每次提交時執行。

   • Image指定了該階段使用的基礎鏡像，該鏡像為本地手動提前創建並推送;
   • services指定了該階段依賴使用的服務，mongo和redis，該job運行時會初始化指定服務版本的容器，並分別暴露域名為mongo:27017、redis:6379，需要在配置文件中提前配置好CI專用的配置文件;
   • befor_script指定了在執行正式腳本之前預先執行的命令，打印python版本信息、將CI專用測試配置文件置為項目讀取的配置文件、運行測試數據初始化腳本、npm構建前端部分;
   • script指定了正式腳本執行命令，開始執行django的單元測試。

4. 其他gitlab-ci.yml文件參考

   • CI/CD Example: https://docs.gitlab.com/ee/ci/examples/
   • Job Keyword: https://docs.gitlab.com/ee/ci/yaml/#job-keywords

四、 Gitlab-Runner介紹和使用

上面講了.gitlab.yml文件如何編寫以及其中的job執行順序邏輯，那各個job實際的執行者是誰呢，答案就是gitlab-runner，一般來說gitlab-runner會和gitlab所在的服務器進行隔離，因為一個任務的構建、往往會執行編譯、測試、發布的過程，這個過程會消耗大量的系統資源。gitlab-runner幾乎可以安裝在任何的機器上，只要能和gitlab所在服務器及docker倉庫服務器進行通信即可。

一般來說，gitlab上已由負責人配置好了gitlab-runner，我們只需要編寫好.gitlab.yml文件提交代碼即可觸發runner進行工作。但對於初學者來說，你可能想能不能在提交代碼前在本地先執行.gitlab.yml文件的job，本地調試成功檢查沒有問題后再進行最終代碼的提交，觸發服務端的CI流程。答案當然也是可以的。之前已經說了，.gitlab.yml文件中定義的job其實是某個服務器中的gitlab-runner在運行，那我們也可以在本地安裝好gitlab-runner手動的來執行本地.gitlab.yml中的job。

Gitlab-runner的安裝

你幾乎可以在任何機器上安裝gitlab-runner，這里講一下mac上的安裝方式:

• mac安裝： brew install gitlab-runner

• 其他安裝參考：https://docs.gitlab.com/runner/install/

• gitlab-runner-helper安裝：docker pull gitlab-runner-helper

注：gitlab-runner需要依賴gitlab-runner-helper本地鏡像，最好提前pull到本地倉庫或者私有倉庫中。

使用gitlab-runner運行本地.gitlab.yml中定義的job

目前本地的gitlab-runner貌似只能一次執行一個指定的job，而不能自動完成yml文件包含的pipeline的總流程，但作為本地測試也是足夠了。當然，本地必須啟動有docker服務，並且提前准備好了需要的基礎鏡像, job會基於基礎鏡像，將本地代碼置於一個新目錄中執行，本地runner時一般為生成容器中的/builds/projects0目錄。

1. 進入本地項目根目錄，即包含了.gitlab.yml的目錄
2. 執行gitlab-runner命令：
   gitlab-runner exec docker test_job --docker-pull-policy=never

 

 

 gitlab-runner本地運行示例

3. 參數釋義
   • gitlab-runner exec docker 為固定命令寫法;
   • test_job為.gitlab.yml中定義的一個job;
   • --docker-pull-policy=never表示使用本地的docker鏡像而非網絡倉庫

這樣很簡單的安裝和命令便能在本地運行一個gitlab-runner的測試了。

推送代碼到gitlab分支

本地測試沒問題后便可放心的將代碼推送至遠程分支了，如果當前是fork倉庫，則需要同時將代碼推送至upstream觸發主倉庫的CI流程，CI通過后，后續才可將分支代碼合並至master。

附錄（涉及的其他相關操作）

配置docker私有倉庫

由於CI流程會使用到我們自己打包的一些docker鏡像，鏡像的上傳和下載會依賴組內的私有倉庫，下面介紹如何配置docker的倉庫連接：

• 編輯deamon.json配置文件
  Mac電腦可以直接通過docker應用， Preferences—>Docker Engine 直接編輯配置即可：
  
   

  

   

   deamon.json配置

增加insecure-registries和dns配置如下：

"insecure-registries": [
    "你的私有倉庫host解析地址"
],
  "dns": [
    "你的私有倉庫dns地址"
    ]

 

其中，only和except的使用參考：Choose when to run jobs | GitLab

only定義job什么時候run；except定義job什么時候不run