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

黃爸爸好 2019-12-26

展開全文

長話短說

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

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

P1：Gitlab CI/CD原理和Gitlab Runner安裝（這里使用shell執(zhí)行器）

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

宏觀業(yè)務架構圖
.gitlab-ci.yml文件
項目部署文件

Gitlab CI/CD部署準備

Gitlab CI/CD原理

Gitlab CI/CD 存儲[構建],、[構建狀態(tài)]的api應用程序, 提供友好的管理界面, 構建過程由 .gitlab-ci.yml文件定義（該文件一般置于代碼倉庫的根目錄）
Gitlab Runner 執(zhí)行構建任務的應用程序，可獨立部署,，如上圖所示其通過api與Gitlab Server交互

搭建Gitlab CI/CD環(huán)境

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

將要使用何種形式的Runner

配置Runner要用到環(huán)境變量

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

本次手動設置特定Gitlab Runner：

Runner安裝完畢,，注冊Runner(與Gitlab Projects實例建立綁定關系)

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

Tags 與此Runner相關的任務標簽, 用于在共享Runner中區(qū)分不同的Project,.gitlab-ci.yml會用到
Runner Executor 執(zhí)行構建任務的方式，這里使用shell方式

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

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

Gitlab CI/CD實踐

宏觀業(yè)務架構圖

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

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

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

Pipeline對每一次提交或合并都會執(zhí)行build任務,，形成Continous Intergation
Pipeline對git: tag會觸發(fā)build_Image任務，成功之后構建deploy:staging任務,，這樣就能形成基于git：tag的部署版本管理(部署出錯,，也能很快回滾到上次的部署tag)

.gitlab-ci.yml文件

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

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會執(zhí)行該任務,， 支持正則

- 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行：預先定義的環(huán)境變量,，該變量定義gitlab CD的部署目錄

第16行: 對src開發(fā)目錄下兩個程序執(zhí)行dotnet build命令

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

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

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

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

注意變量可被重寫,，重寫優(yōu)先級：http://www./auto/gitlab-cicd-variables-zh-document/

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

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

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

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

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

部署目錄

在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文件,，前者定義常規(guī)容器服務,，后者定義適用于本部署環(huán)境的附加服務
密鑰文件不要進入代碼管理，因此我們定義appsetting.secrets.json 和 receiver.secrets.json密鑰文件,，由dccker-compose.yml掛載進入容器
env文件存儲相對固定且與本次docker-compose命令相關的環(huán)境變量,，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之后,，觸發(fā)Gitlab Runner CI/CD Pipeline:

跳轉到部署目錄->應用本次git:tag->執(zhí)行docker-compose命令拉取指定tag鏡像并啟動容器,。

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

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

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

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