前言
上一篇博文 .NetCore 配合 Gitlab CI&CD 實踐 - 開篇,主要簡單的介紹了一下 GitLab CI
的持續整合以及持續部署,這篇將通過 GitLab CI
釋出一個 .net core 專案,來帶小夥伴們感受一下自動化的魅力,從此告別手動釋出。
準備工作
建立一個空MVC專案來進行演示:
mkdir hello-world
cd hello-world
dotnet new sln -n HelloWorld
mkdir src
cd src
dotnet new mvc -n GitLabCIDemo
cd ../
dotnet sln add .\src\GitLabCIDemo\GitLabCIDemo.csproj
完成以上建立後,用 vscode 開啟應該是下面這個樣子:
專案上傳至 GitLab
在 gitlab 上新建一個 hello-world
的專案,將本地的專案上傳。這個按照如下提示操作即可:
專案上傳成功後,切一個 dev 分支出來,我這裡的策略是,程式碼提交到 dev 分支是自動釋出到開發環境進行驗證的,生產環境是通過 master 分支打 tag 進行釋出的。
- 切換到 dev 分支!
- 切換到 dev 分支!
- 切換到 dev 分支!
新增相關指令碼
在 hello-world
資料夾內建立 .build/docker
資料夾,並新增如下指令碼以及Dockerfile
:
- build-image.sh
docker build -f .build/docker/Dockerfile --build-arg PROJECT=$1 --build-arg ASPNETCORE_ENVIRONMENT=$2 -t $3 .
- build-project.sh
set -e
for arg in "$@"
do
target=$(pwd)/src/$arg
dotnet restore -v n $target
dotnet publish -c Release -o $target/publish $target
done
- push-image.sh
NEW_TAG="registry.cn-hangzhou.aliyuncs.com/xxx/$1"; // 這裡得用你自己名稱空間哦
docker tag $1 $NEW_TAG
docker push $NEW_TAG
docker rmi $NEW_TAG
- Dockerfile
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-alpine
ARG PROJECT
ARG ASPNETCORE_ENVIRONMENT
ENV ASPNETCORE_ENVIRONMENT ${ASPNETCORE_ENVIRONMENT}
WORKDIR /app
COPY src/${PROJECT}/publish .
RUN echo "#!/bin/bash \n dotnet ${PROJECT}.dll" > start.sh && chmod +x ./start.sh
ENTRYPOINT ["./start.sh"]
這裡構建映象所使用 3.1-alpine
構建出來的映象體積只有其他映象版本構建出來體積的一半。推薦使用。到此目錄結構就成了現在這樣:
至此準備工作已經差不多了!我們先簡單過一下 CI 的流程:
提交程式碼 --> 編譯 --> 測試 --> 構建映象 --> 釋出
編譯 -- Build
在 hello-world
目錄下新增 .gitlab-ci.yml
檔案,新增 build
任務:
stages:
- build
helloworld-build:
stage: build
tags:
- docker
image: mcr.microsoft.com/dotnet/core/sdk:3.1
script:
- .build/docker/build-project.sh GitLabCIDemo
artifacts:
paths:
- src/*/bin
- src/*/publish
這裡起一個容器來跑編譯任務,具體細節可以看 build-project.sh
指令碼,用 artifacts
將釋出出來的資源上傳,給後面的 構建任務使用,不需要重複 build,節約時間。這裡執行會出現如下錯誤:
/bin/bash: line 89: .build/docker/build-project.sh: Permission denied
這是因為指令碼沒有執行許可權,通過 chmod
命令可以解決:
chmod +x build-image.sh build-project.sh push-image.sh
重新提交,觸發 build 任務。開啟 GitLab CI 介面,執行成功,是不是很開心呢?
測試 -- Test
現在專案裡面沒有測試程式碼,那就新建一個吧。在 hello-world
根目錄下:
mkdir test
cd test
dotnet new xunit -n GitLabCIDemo.UnitTests
更新 .gitlab-ci.yml
新增 Test 任務:
stages:
- build
- test
helloworld-build:
stage: build
tags:
- docker
image: mcr.microsoft.com/dotnet/core/sdk:3.1
script:
- .build/docker/build-project.sh GitLabCIDemo
artifacts:
paths:
- src/*/bin
- src/*/publish
helloworld-test:
stage: test
tags:
- docker
image: mcr.microsoft.com/dotnet/core/sdk:3.1
script:
- dotnet test -c Release
dependencies:
- helloworld-build
等待一會,檢視 CI 執行。
構建 Docker 映象 -- Pack
我這裡使用的是阿里雲的映象倉庫,需要現在阿里雲上建立對應的名稱空間以及映象名稱。我這裡給映象名取名為 hello-world
,別忘了修改 push-image.sh
中的名稱空間哦!
更新 .gitlab-ci.yml
新增 Pack 任務:
stages:
- build
- test
- pack
helloworld-build:
stage: build
tags:
- docker
image: mcr.microsoft.com/dotnet/core/sdk:3.1
script:
- .build/docker/build-project.sh GitLabCIDemo
artifacts:
paths:
- src/*/bin
- src/*/publish
helloworld-test:
stage: test
tags:
- docker
image: mcr.microsoft.com/dotnet/core/sdk:3.1
script:
- dotnet test -c Release
dependencies:
- helloworld-build
helloworld-pack-staging:
stage: pack
tags:
- shell
script:
- .build/docker/build-image.sh GitLabCIDemo Staging hello-world:beta
- .build/docker/push-image.sh hello-world:beta
dependencies:
- helloworld-build
only:
- dev
-
Staging
: 用來設定環境變數ASPNETCORE_ENVIRONMENT
,讓.net core
讀取對應的配置檔案,可以設定Development
,Staging
,Production
三種,可以在對應的環境設定對應環境變數,使用不同配置。 -
beta: 因為是開發環境,就一直使用同一個 tag 去覆蓋之前的映象,每次 pull 最新的映象就好了,也可以使用
$CI_COMMIT_SHORT_SHA
使用當前 git 提交的 hash 值作為版本號
CI 應該執行的差不多,再去瞧瞧唄! 又是全綠,真是開心!額,全綠,怪怪的...
開啟阿里雲映象容器服務,檢視一下剛剛上傳的容器映象吧!
部署 -- Deploy
這裡我圖方便就使用
docker-compose
來做演示了,通常部署環境都是使用叢集來部署的,當然單機部署也不是不無可能的,我內網用 k3s 搭建的一個叢集,為啥不用 k8s,因為要求資源配置比較高,k3s 剛好夠用。但是部署到 k3s 需要寫挺多的配置的檔案,可以單獨寫一篇博文介紹。
作為自動化最後一步,無論你是用 k8s
,k3s
,docker swarm
......,都是拉取對應的映象,進行部署。思路是一樣的,只是部署方式略有不同。這裡通過 docker-compose 來發布 hello-world
應用咯。
在部署的 Linux 伺服器上建立資料夾 /deploy
,在目錄下新增 docker-compose.yml
檔案,新增如下內容:
version: "3.8"
services:
hello-world:
image: registry.cn-hangzhou.aliyuncs.com/jd-rd/hello-world:beta
container_name: hello-world
restart: always
ports:
- 5013:80
networks:
- basic_service
networks:
basic_service:
更新 .gitlab-ci.yml
,新增部署任務:
stages:
- build
- test
- pack
- deploy
helloworld-build:
stage: build
tags:
- docker
image: mcr.microsoft.com/dotnet/core/sdk:3.1
script:
- .build/docker/build-project.sh GitLabCIDemo
artifacts:
paths:
- src/*/bin
- src/*/publish
helloworld-test:
stage: test
tags:
- docker
image: mcr.microsoft.com/dotnet/core/sdk:3.1
script:
- dotnet test -c Release
dependencies:
- helloworld-build
helloworld-pack-staging:
stage: pack
tags:
- shell
script:
- .build/docker/build-image.sh GitLabCIDemo Staging hello-world:beta
- .build/docker/push-image.sh hello-world:beta
dependencies:
- helloworld-build
only:
- dev
deploy-staging:
stage: deploy
tags:
- staging
script:
- cd /deploy && docker-compose pull && docker-compose up --force-recreate -d && docker ps
only:
- dev
等待整個CI跑完,檢視 CI 執行結果
通過伺服器IP + 5013 訪問應用了,就可以看到服務更新
修改一下 Index.cshtml
將 Welcome
修改為 Hello Devops !
,重新提交一下,稍等片刻,重新訪問即可看到變化了。
至此一個簡單的 CI 流程已經走完了,各位看官可以根據自己的需求,繼續探索。
題外話
如果將指令碼都放在專案裡面的話,將來涉及到指令碼變更,需要每個專案都給改過去,這是十分痛苦的事情。這裡推薦小夥伴可以通過 git submodule
子模組的方式進行引用,將公共的指令碼都給提取出來,專案通過子模組來載入指令碼專案,將來指令碼變更,每個專案只需要更新一下子模組就好。
總結
通過以上一個小案例已經帶小夥伴瞭解了一圈 GitLab-CI
如何來釋出一個 .net core
應用,感受了一下 GitLab-ci
的魅力。但是以上方案還是有瑕疵的,對於單體應用來說,沒有太大問題,但並不適合微服務專案。在微服務專案中,如果多個服務散落在多個倉庫中,需要多個專案程式碼改動其實是很不方便的,所以現在很多的微服務專案都採用 Mono
倉庫風格及將所有的服務都放在一個倉庫裡面,倉庫體積雖然大,但是改動起來更方便。本篇就先到這裡了,有關於 GitLab-CI
對於 Mono
倉庫風格專案 CI&CD
探索實踐,且聽下回分解。