部門決定從SVN遷移到GIT之初，我們暫定的是使用Jenkins作爲CI/CD的實現，不過秉承實用的思想我們最終決定直接啓用GitLab內置的GitLab-CI作爲我們目前的CI/CD實現。
1. 概述
GitLab-CI 即爲 GitLab Continuous Integration，也就是GitLab自帶的持續集成工具。其思想就是每次用戶push代碼到gitlab上時觸發執行.gitlab-ci.yml 腳本，腳本的內容包括了測試，編譯，部署等一系列自定義的內容。
與 Jenkins Pipeline 相比，GitLab-CI 更輕，更方便。它直接通過簡單 yaml 文件定義 pipeline，相比與 jenkins 複雜的 groovy 語法，GitLab-CI 更簡單。正如官方宣傳的"Don’t let your tools slow you down"。
2. 配置GitLab-Runner
想要使用GitLab-CI，我們需要安裝一些額外的組件GitLab-Runner。GitLab服務本身只負責任務的派發，具體的執行還是得交給Runner，這也符合最基本的設計準則——調度中心和執行分開，避免相互影響，方便迭代更新，也方便擴容。
GitLab Runner可以跑在一個單獨的機子上。只需要這個機器需要能夠訪問GitLab服務本身。不過筆者建議進行單獨安裝，避免攪和在一起相互影響。軟件開發是一個整體，前期偷的那點懶，之後會成倍地還回來。
這裏以CentOS爲例：
######## 準備工作
# 操作系統版本
$ rpm -q centos-release
centos-release-7-7.1908.0.el7.centos.x86_64
# 更改hostname, 讓CI執行日誌更有辨識度
$ sudo hostname 252Server
######## 安裝
# 下載可執行包
wget -O /usr/local/bin/gitlab-runner https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-ci-multi-runner-linux-amd64
# 賦予執行權限
chmod +x /usr/local/bin/gitlab-runner
# 創建runner用戶
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
######## 註冊Runner (目的是實現GitLab-Runner與GitLab-CI之間的信息互註冊。Runner知道了自己需要操作哪個項目，CI也知道了該runner的存在。刷新Runners settings就可以看到新註冊的Runner了。)
# 注意以下輸入項大部分是可以在之後進行界面化修改的, 所以不用過分擔心.
$ gitlab-runner register
Running in system-mode.
# 以下URL, TOKEN的來源參見下方截圖
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://XXX.XXX.XXX.XXX/ # 注意這裏使用默認端口80, 筆者經過嘗試發現這裏即使你特意配置了端口, 之後Runner拉取代碼的時候依然是使用默認的80端口. 即使配置了clone_url也無效; 有知道的同學非常歡迎留言, 不甚感激.
Please enter the gitlab-ci token for this runner:
XXXXXXXXXXXXXXXX
Please enter the gitlab-ci description for this runner:
[localhost.localdomain]: XxxGoodName # 取個好名字, 方便自己, 也方便他人.
Please enter the gitlab-ci tags for this runner (comma separated):
pioneer,maven # 使用逗號分割.
Whether to run untagged builds [true/false]: # 默認值爲false。這句話的意思是：是否在沒有標記tag的job上運行，如果選擇默認值false，那沒有標記tag的代碼提交是不會觸發gitlab runner的，如果做測試，最好填true。
[false]: false
Whether to lock Runner to current project [true/false]:
[false]: false
Registering runner... succeeded runner=ZXxxxx
Please enter the executor: docker, shell, virtualbox, docker+machine, docker-ssh+machine, docker-ssh, parallels, ssh, kubernetes:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
######## 安裝Runner並作爲服務運行
gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
gitlab-runner start
# 查看服務狀態
service gitlab-runner status
2.1 獲取配置項URL和TOKEN
Runner大體分爲兩類：
- Shared Runner（所有項目共用的）
![獲取URL和TOKEN]()
- Specific Runner（針對特定的項目）
![獲取URL和TOKEN]()
2.2 GitLab中的Runner信息
- GitLab知曉的Runner配置信息。
![Runner配置信息]()
- 歸屬於特定Project的Runner
![歸屬於Project的Runner]()
2.3 幾個關鍵路徑
-
配置文件路徑
/etc/gitlab-runner/config.toml on *nix systems when GitLab Runner is executed as root (this is also path for service configuration) ~/.gitlab-runner/config.toml on *nix systems when GitLab Runner is executed as non-root ./config.toml on other systems -
工作目錄
/home/gitlab-runner//home/gitlab-runner/ .bash_history .bash_logout .bash_profile .bashrc builds cache .m2 .oracle_jre_usage .ssh
3. 配置.gitlab-ci.yml
這裏直接給一個測試成功的SpringBoot應用編譯, 打包, 部署的配置模板。
# 緩存服務, 如果有文件需要多個stages共用，例如jar/war包
cache:
paths:
- target/
variables:
USERNAME: "Xxxx"
PASSWORD: "Xxxx"
IP: "xx.xx.xx.xx"
# 本次構建的階段：build package deploy
stages:
- build
- package
- deploy
# 構建 Job
build:
stage: build
tags:
- maven
script:
- echo "=============== 開始編譯構建任務 ==============="
- mvn clean compile
# 打包
package:
stage: package
tags:
- maven # 這裏和上面我們在註冊Runner時候輸入的maven tag對應
script:
- echo "=============== 開始打包任務 ==============="
# 這裏的 ./ 路徑指代項目根目錄, 即: /home/gitlab-runner/builds/a9240569/0/root/projectName/
- mvn package -Dmaven.test.skip=true -P product -Dbuild.assemblySavePath=./target/
# 部署
deploy:
stage: deploy
tags:
- maven
script:
- echo "=============== 開始部署任務 ==============="
# 測試，是否能夠通過 ssh 連通遠程服務器
- sshpass -p $PASSWORD ssh -o StrictHostKeychecking=no $USERNAME@$IP
- echo "=============== 將 war 包部署到遠程服務器上 ==============="
- sshpass -p $PASSWORD scp -o StrictHostKeychecking=no target/projectName-bin.zip $USERNAME@$IP:/root/projectName-bin.zip
- echo "=============== 開始執行 ==============="
# 執行shell腳本的時候必須要用命令：source xx.sh，如果只是單純的執行命令./xx.sh，則切換目錄命令cd不會被執行
- sshpass -p $PASSWORD ssh -o StrictHostKeychecking=no $USERNAME@$IP "cd /root && source ./deploy.sh"
4. 效果
單個Pipeline內部：
5. 關閉CI功能
- 參見 Office Site - enable_or_disable_ci，實現在項目級別管理CI功能：
![關閉CI功能-項目級]()
- 全局範圍內，依然是參見上述官方文檔，這裏就不展開了。
6. 概念解釋
我們有必要對GitLab中的一些組件進行了解。
6.1 GitLab-CI
- GitLab-CI是GitLab Continuous Integration（Gitlab持續集成）的簡稱，是GitLab自帶的一套持續集成工具。
- 從Gitlab的8.0版本開始，gitlab就全面集成了Gitlab-CI,並且對所有項目默認開啓。（jenkins+webhook 也可以實現持續集成）
- 只要在項目倉庫的根目錄添加.gitlab-ci.yml文件，並且配置了Runner（運行器），那麼每一次合併請求（MR）或者push都會觸發CI pipeline。
6.2 .gitlab-ci.yml
這個是在git項目的根目錄下的一個文件，記錄了一系列的階段和執行規則，包含一系列的執行腳本和指定的runner名稱。GitLab-CI在push後會解析它，根據裏面的內容調用runner來運行。
6.3 GitLab-Runner
GitLab-Runner是.gitlab-ci.yml腳本的運行器，Gitlab-Runner是基於Gitlab-CI的API進行構建的相互隔離的機器（或虛擬機）。GitLab Runner 不需要和Gitlab安裝在同一臺機器上，但是考慮到GitLab Runner的資源消耗問題和安全問題，也不建議這兩者安裝在同一臺機器上。
可以分類兩種類型：Shared Runner和Specific Runner。
- Shared Runner：所有工程都能夠用的。只有系統管理員能夠創建Shared Runner。
- Specific Runner：只能爲指定的工程服務。擁有該工程權限的人都能夠爲該工程創建Shared Runner。
6.4 Pipelines
Pipelines是定義於.gitlab-ci.yml中的不同階段的不同任務。
我們把Pipelines理解爲流水線，流水線包含有多個階段（stages），每個階段包含有一個或多個工序（jobs），比如先購料、組裝、測試、包裝再上線銷售，每一次push或者MR都要經過流水線之後纔可以合格出廠。而.gitlab-ci.yml正是定義了這條流水線有哪些階段，每個階段要做什麼事。
任何提交或者merge request的合併都可以觸發pipeline。
stages
stages表示構建階段。一次pipeline可以定義多個stages，他們特點如下：
- 所有stages會按照順序運行。
- 所有stages完成後，該構建任務（pipeline)纔會成功。
- 任何一個stage失敗，後面的stages不會執行。
job
jobs表示構建工作，表示某個stage裏面執行的工作。我們可以在stages裏面定義多個jobs，這些jobs會有以下特點：
- 同一個stage中的的job會並行執行。
- 同一個stage中的全部jobs都成功時候，該stage纔會成功。
- 如果任何一個job失敗，那麼該stage失敗，即該構建任務失敗。
6.5 Badges(徽章)
當Pipelines執行完成，會生成徽章，你可以將這些徽章加入到你的README.md文件或者你的網站。