GitLab私有化部署 - CI/CD - 持續內建/傳遞/部署 - 源碼托管 & 自動部署

Java微服務 GitLab私有化部署 - CI/CD - 持續內建/傳遞/部署 - 源碼托管 & 自動部署

幾年前，第一次接觸了靈活開發模式。由合作夥伴安排講師教育訓練了兩周，每天五節課，據吹牛說，對外一節課每人一千多塊大洋。由于時間關系項目馬上要開始，半個月僅教育訓練了部分重點内容，挺厚的材料也就挑了幾個必須的重點章節。第一次接觸，比較全面，比較新意，比較系統，認識到有很多新的不同的理念，個人感覺有好多很有用的部分，把團隊也管理了，把技術也培養了，把規則也統一了，把流程也優化了。。。自己學到了很多東西，緻使我以後在新的工作環境中有很明顯的變化和效果。當然更确切的說，它更契合或接近我原本對團隊開發的輪廓或展望。有新的東西可以嘗試和體會也挺不錯的，從中吸收到的東西可以去運用，這就是每個人的經驗。會用它，用好它，才能發揮出乎意料的效果。當然也許會說靈活開發過時了，這都沒什麼，這段旅程讓我收獲不少。

說了這麼多，還不是本章要闡述的内容啦，嘿嘿。在靈活開發的過程中，由于是用的收費平台輔助管理，挺貴的，是以我一直在關注免費的CI/CD這塊的相關産品，市面上會有很多不同品牌的免費産品組合着運用，以完成開發的整個流程。是以本章要闡述的是(GitLab)同一個平台下完成源代碼托管并且CI/CD自動化部署的過程。

不好的地方多提建議，接下來，讓我闡述給你聽 ...

一、預期目标

1.1 源代碼管理

借助 GitLab 實作源代碼托管，私有化部署版本，建立項目，建立使用者組，配置設定權限，項目的維護變更，團隊間的協作等。

1.2 自動化部署

項目指定分支(源代碼)産生變更時(如簽入)，自動化編譯并釋出到指定伺服器中部署，借助GitLab-runner實作持續及時部署，供使用者通路項目更新的站點，這裡用在開發環境。

1.3 目标總體運作圖

二、環境說明

硬體基本要求：4核4GRHEL8 Linux operating system：這裡用GitLab官網提到的 AlamLinux8GitLab v15：用于源代碼托管Git：用于遠端自動拉取源代碼dotnet 6.0：測試站點的運作環境GitLab-runner：實作自動化部署的應用

最主要的兩個安裝 GitLab、GitLab-runner 通常會分開部署，這裡計劃所有的安裝均在同一台伺服器中。

三、環境安裝

3.1 AlmaLinux8.6 operating system 安裝

AlmaLinux官網：https://almalinux.org

Linux系統的安裝過程中，這裡隻提一點，需要注意的是，後續在系統中安裝GitLab時，GitLab的安裝包有800+MB，遇到系統boot分區空間不足的現象，這裡計劃将系統的 /boot 分區調整為1GB以上的空間。

下圖為安裝AlmaLinux8.6時的boot分區設定：

以上現象有沒有其它方式解決，咱不知曉，這裡選擇調整分區大小的方式解決。

3.2 GitLab 安裝

參考官方提供的安裝要求 https://gitlab.cn/install/

3.2.1 安裝前提

關于防火牆，需要打開 HTTP、HTTPS 和 SSH 通路。通常Linux都會預設安裝了SSH等常用工具。

(可選) 如果您打算僅從本地網絡通路極狐GitLab，則可以跳過它。

# OpenSSH 的安裝
dnf install -y curl policycoreutils openssh-server openssh-clients
# 開啟開機自啟動
systemctl enable sshd
# 啟動 OpenSSH 服務
systemctl start sshd
#
# 配置永久開啟防火牆 http、https
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
# 配置生效
systemctl reload firewalld           

(可選) GitLab 通過 Postfix 發送電子郵件通知，或者跳過此步驟使用其他解決方案發送電子郵件。

# Postfix 的安裝
dnf install postfix
# 開啟開機自啟動
systemctl enable postfix
# 啟動 Postfix 服務
systemctl start postfix           

3.2.2 下載下傳 GitLab 軟體源鏡像

先下載下傳官方 GitLab 鏡像倉庫，為了便于後續從此鏡像庫中安裝 GitLab 應用。

# 指令下載下傳安裝包
curl -fsSL https://packages.gitlab.cn/repository/raw/scripts/setup.sh | /bin/bash           

GitLab 鏡像庫下載下傳完成後的說明：

1、鏡像庫檔案 gitlab-jh.repo 儲存于 /etc/yum.repos.d/ 目錄中

2、生成 gitlab-jh 鏡像的緩存

3、再安裝 gitlab-jh

如下圖所示：

3.2.3 安裝 GitLab 應用到系統

# 按照上一步的說明：
# 先重新整理鏡像緩存（這步不是必須，為了後續的快速安裝）
dnf clean all && dnf makecache
# 再安裝名為 gitlab-jh 的應用到系統，并綁定通路位址
sudo EXTERNAL_URL="http://{所在伺服器IP或域名}" dnf install -y gitlab-jh
# 以上僅用 http 的方式，這裡不用 https 方式。           

3.2.4 登入到 GitLab 管理頁面

安裝成功後，首次登陸自動生成的密碼存放于：/etc/gitlab/initial_root_password 中（隻有24H的保留期限）

# 檢視初始密碼
cat /etc/gitlab/initial_root_password           

在浏覽器中打開通路位址；安裝時設定的 http://{所在伺服器IP或域名}

啟動慢，出現502，需要耐心等待幾分鐘。

然後使用預設管理者賬号 root 和查找到的初始密碼 進行登入，記得修改初始密碼。

3.3 在 GitLab 中建立項目

為後續的測試效果，這裡建立名為 my-project-test 的測試項目，登入頁注冊使用者，管理者背景稽核通過，為測試項目添加成員，設定項目成員的相應權限。這裡将成員授予 Maintainer 角色。

或建立使用者組，把使用者組賦予項目，并賦予相應權限。

本地編寫源代碼，實作檔案屬性時間的讀取功能，并簽入到 GitLab 建立的 my-project-test 測試項目中。如下圖所示：

到此，通過 GitLab 中提供的功能，實作了源代碼的托管。接下來，為自動部署做準備工作。

3.4 Git 安裝

安裝 Git 是為了，在自動化部署時，這裡計劃用 Git 工具來遠端拉取源代碼，以便于後續的編譯釋出動作。

dnf install git -y           

3.5 dotnet 環境

在自動化部署時，需要有編譯釋出過程，是以這裡需要安裝 dotnet-sdk（SDK包括：build、publish、runtime等）

首先安裝微軟官方提供的鏡像庫，以便于從微軟鏡像庫中安裝所需的 dotnet-sdk 等。

微軟官方提供的鏡像站：https://packages.microsoft.com/config/

# 這裡選用與環境适配的軟體庫 RHEL8版 下載下傳到 /etc/yum.repos.d/ 中
curl -o /etc/yum.repos.d/prod.repo https://packages.microsoft.com/config/rhel/8/prod.repo
# 重建鏡像庫緩存
dnf clean packages && dnf clean all && dnf makecache
#
# 先安裝運作 dotnet 時必要的 libicu 工具
dnf install libicu -y
# 安裝适合于開發環境的 dotnet-sdk-6.0
dnf install dotnet-sdk-6.0 -y           

後續站點部署完成後，計劃的站點通路端口定為5000，這裡預先開啟防火牆5000的端口：

# 開放測試站點通路的5000端口
firewall-cmd --zone=public --add-port=5000/tcp --permanent
firewall-cmd --reload
# 檢視已開放的端口
firewall-cmd --list-ports           

3.6 GitLab-runner 安裝

這裡 GitLab-runner 主要是通過 GitLab 的項目中 CI/CD 自定義的流水線步驟，來完成自動化部署的任務。

依據GitLab官網安裝說明：https://docs.gitlab.com/runner/install/linux-manually.html

# 按GitLab官網的方式，做以下步驟：
#
# 下載下傳安裝包到bin目錄
curl -Lo /usr/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
# 授予安裝包可運作的權限
chmod +x /usr/bin/gitlab-runner
# 建立 GitLab-runner 的運作賬号
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
# 用指定賬号安裝 gitlab-runner
gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
# 安裝後的 gitlab-runner 服務管理
gitlab-runner start		# 啟動
gitlab-runner stop		# 停止           

3.7 注冊 GitLab-runner

首先檢視在GitLab項目頁面的 菜單 > 設定 > CI/CD > Runner 中提到的内容，将在接下來的注冊過程中用到。如下圖所示：

接下來開始注冊 GitLab-runner：

# 按照官網的描述，注冊完成後，才可以使用GitLab-runner的執行個體
# 啟動後的注冊指令（注冊過程中，需要按提示填寫幾項内容）
gitlab-runner register           

注冊過程中，填寫的内容如下圖所示：

注冊完成後，頁面 Runner 區域會多出一個 <可用的指定runner執行個體>。

四、自動化部署配置

4.1 指定作業目錄及權限

首先指定一個存放部署檔案的目錄，假設建立 /opt/gitlab-devops-app 作為部署的目錄。

計劃在此目錄下，用gitlab-runner來執行流水線中的指令，完成遠端克隆源代碼、編譯釋出、啟動站點等動作。

是以gitlab-runner需要擁有對此目錄的可操作權限：

# 安裝 gitlab-runner 時，已經建立了名為 gitlab-runner 的使用者名
# 這裡授予 gitlab-runner 的所屬使用者對部署檔案夾的操作權限
# 賦予所屬使用者為 gitlab-runner
chown -R gitlab-runner:gitlab-runner /opt/gitlab-devops-app
# 并授予可執行權限
chmod -R +x /opt/gitlab-devops-app           

在後續流水線的配置中，計劃所有的操作以此為根目錄。

4.2 CI/CD 中的流水線配置

在項目菜單 CI/CD -> 編輯器 中，先選擇對應的項目分支，再配置流水線按鈕；自動生成名為 .gitlab-ci.yml 的檔案于此項目的根目錄；

在此流水線編輯器中，GitLab會給出一個配置模闆，按指定格式，編寫 Shell script 作業指令，達到自動化部署的目标。

是以，分支流水線配置檔案 .gitlab-ci.yml 中編寫的作業指令，決定了自動化部署的步驟過程。

這裡将自定義配置好的内容如下：

# 總流程 - 按序運作
# 這裡自定義了六個步驟，可按實際情況自定義名稱和順序，通過指令完成部署
stages:           # List of stages for jobs, and their order of execution
  - erase         # Job1：停止/清除原有應用
  - clone         # Job2：遠端克隆源代碼
  - test          # Job3：單元測試
  - build         # Job4：編譯源代碼
  - publish       # Job5：釋出項目
  - deploy        # Job6：重新啟動站點運作
#
#
#
# 以下每個作業(步驟節點)對應上述總流程的步驟名稱，如下示例每個作業格式：
# {自定義作業名稱}:
# 	stage: {對應上述總流程定義的作業節點名稱}
# 	script:
# 	- {按序執行的指令行}
# 	- {按序執行的指令行}
# 	- {按序執行的指令行}
#
#
#
# Job1：停止/清除原有應用
erase-job:
  stage: erase
  script:
    - ps -ef | grep Web.dll | grep -v grep | awk '{print $2}' | xargs -r kill -9 && true=0 || false=1
    - cd /opt/gitlab-devops-app/
    - rm -rf my-project-test
#
# Job2：遠端克隆源代碼
clone-job:
  stage: clone
  script:
    - cd /opt/gitlab-devops-app/
    - git clone -b {分支名稱} http://{使用者名}:{密碼}@{ServerIP}/{project-url}/my-project-test.git
#
# Job3：單元測試；對克隆下來的源代碼進行操作
unit-test-job:
 stage: test
 script:
   - cd /opt/gitlab-devops-app/my-project-test/Web/
   - dotnet test Web.csproj
#
# Job4：編譯源代碼
build-job:
  stage: build
  script:
    - cd /opt/gitlab-devops-app/my-project-test/Web/
    - dotnet build --configuration Release
#
# Job5：釋出項目
publish-job:
  stage: publish
  script:
    - mkdir /opt/gitlab-devops-app/my-project-test/publish/
    - cd /opt/gitlab-devops-app/my-project-test/Web/
    - dotnet publish --configuration Release --no-build --output ../publish/
#
# Job6：重新啟動站點運作
deploy-job:
  stage: deploy
  environment: production
  script:
    - cd /opt/gitlab-devops-app/my-project-test/publish/
    - nohup dotnet Web.dll --urls http://*:5000 > /dev/null 2>&1 &           

以上配置送出儲存後，在 CI/CD 的流水線菜單中會顯示一條等待執行的任務，如下圖所示：

那麼，分支流水線已經配置完成，在什麼情況下運作流水線呢？

4.3 觸發方式運作

假設的運用場景：在項目的DEV階段，新的需求功能點開發完成簽入後，能及時的呈現出效果。便于個人或團隊的使用或測試等。

配置：對頁面 runner 區域<可用的指定runner>做一個簡單的配置，這裡是設定自動部署的觸發條件，以便于自動執行指定分支流水線。

如下圖所示：

以上設定完成後，當項目變更(或簽入)後觸發分支流水線運作，以完成自動化部署。

效果如下圖所示：

4.4 定時方式運作

假設的運用場景：在項目的UAT階段，假定Spring的周期為三周，每三周向UAT使用者更新版本，展示階段性成果。

可通過項目菜單 CI/CD -> 計劃 的方式，會在特定分支或标簽上自動定期定時運作流水線，以完成周期部署的計劃。

圖例持續更新中...

五、最終呈現效果

5.1 CI/CD 自動化部署 運作效果

5.2 自動化部署後的測試站點通路效果

   鄙人拙見，有不妥望指出，萬分感謝。