基於docker-compose的Gitlab CI/CD實踐&排坑指南

長話短說

經過長時間實操驗證，終於完成基於Gitlab的CI/CD實踐，本次實踐的坑位很多， 實操過程儘量接近最佳實踐（不做hack, 不做騷操作），記錄下來加深理解。

看過博客園《docker-compose真香》一文的園友留意到文中[把部署dll文件拷貝到生產機器]，現場打包成鏡像並啓動容器，並沒有完成CI/CD.

 P1：Gitlab CI/CD原理和Gitlab Runner安裝（這裏使用shell執行器）

 P2：基於Docker-compose的Gitlab CI/CD 實踐：

• 宏觀業務架構圖

• .gitlab-ci.yml文件

• 項目部署文件

Gitlab CI/CD部署準備

Gitlab CI/CD原理

• Gitlab CI/CD   存儲[構建]、[構建狀態]的api應用程序, 提供友好的管理界面,  構建過程由 .gitlab-ci.yml文件定義（該文件一般置於代碼倉庫的根目錄）

• Gitlab Runner 執行構建任務的應用程序，可獨立部署，如上圖所示其通過api與Gitlab Server交互

搭建Gitlab CI/CD環境

Gitlab CI/CD提供配置界面(項目菜單欄-設置-CI/CD),可指定

   將要使用何種形式的Runner

   配置Runner要用到環境變量

界面配置權限取決於你在Gitlab Server的角色 + https://docs.gitlab.com/ee/user/permissions.html

本次手動設置特定Gitlab Runner：

Runner安裝完畢，註冊Runner(與Gitlab Projects實例建立綁定關係)

註冊時要關注的兩個配置：

• Tags    與此Runner相關的任務標籤, 用於在共享Runner中區分不同的Project,.gitlab-ci.yml會用到

• Runner Executor    執行構建任務的方式，這裏使用shell方式

Shell是最簡單的配置執行器，需要將構建所需的所有依賴項手動安裝在安裝了Runner的同一臺計算機上。

 

註冊過程和結果請參考下圖：

Gitlab CI/CD實踐

宏觀業務架構圖

 

原則上不允許自動部署Prod，本次使用Gitlab Runner服務器作爲Gitlab CD的部署機器。

Gitlab-CI Pipeline構建ReceiverAPP、webAPP鏡像(附帶本次git:tag)並推送到hub.docker.com；

Gitlab-CD docker-compose拉取遠端nginx、ReceiveAPP、webapp鏡像，啓動容器。 

• Pipeline對每一次提交或合併都會執行build任務，形成Continous Intergation

• Pipeline對git: tag會觸發build_Image任務，成功之後構建deploy:staging任務，這樣就能形成基於git：tag的部署版本管理(部署出錯，也能很快回滾到上次的部署tag)

.gitlab-ci.yml文件

以上Gitlab Pipeline定義build->build_image->deploy3個任務，某些任務還包括不同分支Job,寫.gitlab-ci.yml 的過程就是將以上執行動作腳本化。

stages:
  - build
  - build_image
  - deploy

variables:         
# CI_DEBUG_TRACE: "true"                     　　　　　　　　　　　　　　　　　　　　
  deploy_path: "/home/xxxx/eqidmanager"   　　# CI變量，用於配置部署目錄

before_script:
  - "docker info"

build:
  stage: build
  script: 
    - "for d in $(ls src);do echo $d;prog=$(pwd)/src/$d/$d.csproj; dotnet build $prog; done"
  tags:                 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
    - another-tag

build_image:EqidManager:
  stage: build_image
  script:
    - dotnet publish src/EqidManager/EqidManager.csproj  -c release -o ../../container/app/publish/    
    - docker build --pull  -t $CI_REGISTRY_USER/eqidmanager:$CI_COMMIT_REF_NAME  container/app
    - docker login -u $CI_REGISTRY_USER  -p $CI_REGISTRY_PASSWORD      
    - docker push $CI_REGISTRY_USER/eqidmanager:$CI_COMMIT_REF_NAME     
  tags:    
    - another-tag
  only:     　　　　　　　　　　　#Pipeline Job構建策略，代碼倉庫打tag會執行該任務， 支持正則
    - tags

build_image:EqidReceiver:
  stage: build_image
  script:
    - dotnet publish src/EqidReceiver/EqidReceiver.csproj  -c release -o ../../container/receiver/publish
    - docker build -t $CI_REGISTRY_USER/eqidreceiver:$CI_COMMIT_REF_NAME container/receiver
    - docker login -u $CI_REGISTRY_USER  -p $CI_REGISTRY_PASSWORD
    - docker push $CI_REGISTRY_USER/eqidreceiver:$CI_COMMIT_REF_NAME
  tags: 
    - my-tag
  only:
    - tags

deploy:staging:
  stage: deploy
  script:
    - cd $deploy_path
    - export TAG=$CI_COMMIT_REF_NAME       　# 引入本次CI的git：tag名稱，覆蓋.env文件默認配置
    - "docker-compose -f docker-compose.yml -f docker-compose.prod.yml build"                　　　　　　　　
    - "docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d" 
  tags: 
    - my-tag

deploy:prod:
  stage: deploy
  script:
    - # TODO 需要寫腳本登陸到Prod機器上
    - export TAG=$CI_COMMIT_REF_NAME        
    - cd $deploy_path
    - "docker-compose -f docker-compose.yml -f docker-compose.prod.yml build"
    - "docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d" 
  tags:
    - my-tag
  when: manual

這裏有些知識點、坑位需要指出：

第8行：預先定義的環境變量，該變量定義gitlab CD的部署目錄

第16行: 對src開發目錄下兩個程序執行dotnet build命令

第17行：tags定義具備該tags的Runner可以執行該任務，注意這裏的tags必須是字符串數組

第23-26行：構建鏡像並推送到鏡像倉庫的過程，用到兩類CI變量

　- 密鑰變量CI_REGISTRY_USER、CI_REGISTRY_PASSWORD，可在Gitlab-CI界面配置

  - 預定義變量CI_COMMIT_REF_NAME，該變量標記構建項目的git:branch或git:tag名稱，用於生成Image:Tag

注意變量可被重寫，重寫優先級：http://www.ttlsa.com/auto/gitlab-cicd-variables-zh-document/

第29行：only定義此Job只在產生git:tag時被觸發，與上面我們使用CI-COMMIT_REF_NAME 變量相呼應

第47行：Gialab-CI pipeline每個Job會重新拉取git源碼執行Job任務(可登錄到Gitlab Runner工作目錄下觀察Runner執行過程)，CD時需要選擇合適目錄，這是deploy_staging上使用deploy_path CI變量的原因

第48行：注入本次Gitlab-CI git:tag名稱，實際上是覆蓋了.env同名環境變量

第49行：若存在docker-compose.yml、docker-compose.override.yml 兩個文件，docker-compose命令會自動merge這2個文件(使用docker-compose config命令查看merge之後的結果)。

第64行：前置任務未出錯，會自動執行後繼任務；而when指令定義該任務需要界面上手動執行 

部署目錄

在Gitlab Runner服務器的{deploy_path}路徑下建立了如下部署文件：

├── appsettings.secrets.json├── docker-compose.prod.yml├── docker-compose.yml├── .env├── EqidManager.db├── nginx│   ├── Dockerfile│   └── nginx.conf└── receiver.secrets.json

• 部署目錄定義docker-compose.yml、docker-compose.prod.yml 兩個yml文件，前者定義常規容器服務，後者定義適用於本部署環境的附加服務

• 密鑰文件不要進入代碼管理，因此我們定義appsetting.secrets.json 和 receiver.secrets.json密鑰文件，由dccker-compose.yml掛載進入容器

• env文件存儲相對固定且與本次docker-compose命令相關的環境變量，docker-compose命令默認尋找同級目錄下.env文件

------.env 文件----TAG=master    # 該TAG變量會在Pipeline：deploy_staging任務中被覆蓋，形成基於git:tag的imageName:tagdocker_host=172.16.1.1COMPOSE_PROJECT_NAME=EqidManagerDOCKER_REGISTRY=***

Project打上git:tag之後，觸發Gitlab Runner CI/CD Pipeline: 

跳轉到部署目錄->應用本次git:tag->執行docker-compose命令拉取指定tag鏡像並啓動容器。

That'all, 本次應用Gitlab Runner(shell執行器)實踐CI/CD, Gitlab菜單界面有所有構建構成的日誌(便於排查構建問題)；另外上文對於關鍵知識均附帶傳送門，可進一步對比研究。

+ https://www.cnblogs.com/JulianHuang/p/10919346.html

+ https://docs.gitlab.com/runner/register/index.html

+ https://docs.gitlab.com/runner/executors/README.html