長話短說

經過長時間實操驗證，終于完成基于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- deployvariables: # CI_DEBUG_TRACE: "true" 　　　　　　　　　　　　　　　　　　　　deploy_path: "/home/xxxx/eqidmanager" 　　# CI變量，用于配置部署目錄before_script:- "docker info"build:stage: buildscript: - "for d in $(ls src);do echo $d;prog=$(pwd)/src/$d/$d.csproj; dotnet build $prog; done"tags: 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　- another-tagbuild_image:EqidManager:stage: build_imagescript:- 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-tagonly: 　　　　　　　　　　　#Pipeline Job構建策略，代碼倉庫打tag會執行該任務， 支持正則- tagsbuild_image:EqidReceiver:stage: build_imagescript:- 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_NAMEtags: - my-tagonly:- tagsdeploy:staging:stage: deployscript:- 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-tagdeploy:prod:stage: deployscript:- # 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-tagwhen: 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:tag docker_host=172.16.1.1 COMPOSE_PROJECT_NAME=EqidManager DOCKER_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

往期精選?

實例解讀Docker Swarm

docker stack,docker-compose前世今生

據說點贊的朋友2020都加薪了

總結

以上是生活随笔為你收集整理的基于docker-compose的Gitlab CI/CD实践排坑指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。