一、什麼是GitLab-CI
CI,Continuous Integration,持續集成,是軟件開發過程中一個非常重要的環節,在互聯網敏捷開發的過程中,持續集成通常用來進行日常編譯和自動化測試,來保證及時發現提交的問題,避免影響項目進度。
通常持續集成的過程包括:
- 提交(合併)代碼
- 編譯
- 測試
- 發佈
以前軟件集成的工作是由人工完成的,但是現在鼓勵持續集成,所以,應該考慮將軟件集成這個工作自動化,這就出現了所謂的持續集成系統。
GitLab-CI就是一套配合GitLab使用的持續集成系統(當然,還有其它的持續集成系統,同樣可以配合GitLab使用,比如Jenkins)。而且GitLab8.0以後的版本是默認集成了GitLab-CI並且默認啓用的。配置好GitLab-CI後,能夠快速驗證每次提交的可用性。
二、GitLab-Runner 和 GitLab-CI
GitLab-Runner是配合GitLab-CI進行使用的。一般地,GitLab裏面的每一個工程都會定義一個屬於這個工程的軟件集成腳本,用來自動化地完成一些軟件集成工作。當這個工程的倉庫代碼發生變動時,比如有人push了代碼,GitLab就會將這個變動通知GitLab-CI。這時GitLab-CI會找出與這個工程相關聯的Runner,並通知這些Runner把代碼更新到本地並執行預定義好的執行腳本。
所以,GitLab-Runner就是一個用來執行軟件集成腳本的東西。你可以想象一下:Runner就像一個個的工人,而GitLab-CI就是這些工人的一個管理中心,所有工人都要在GitLab-CI裏面登記註冊,並且表明自己是爲哪個工程服務的。當相應的工程發生變化時,GitLab-CI就會通知相應的工人執行軟件集成腳本。如下圖所示:
Runner類型
GitLab-Runner可以分類兩種類型:Shared Runner(共享型)和Specific Runner(指定型)。
Shared Runner: 這種Runner(工人)是所有工程都能夠用的。只有系統管理員能夠創建Shared Runner。
Specific Runner: 這種Runner(工人)只能爲指定的工程服務。擁有該工程訪問權限的人都能夠爲該工程創建Shared Runner。
我們後面的介紹所註冊的runner都是Special Runner
三、.gitlab-ci.yml文件又是什麼
.gitlab-ci.yml 用來配置GitLab-CI用你的項目做哪些操作,這個文件位於倉庫的根目錄,如果沒有可以自己創建。
當有新內容push到倉庫,或者有代碼合併後,GitLab-CI會查找是否有 .gitlab-ci.yml文件,如果文件存在,GitLab-CI會依據文件內容通知某個Runner去執行.gitlab-ci.yml中定義的操作。
.gitlab-ci.yml 使用YAML
語法, 你需要格外注意縮進格式,要用空格來縮進,不能用tabs
來縮進。
.gitlab-ci.yml文件中的幾個重要概念
Stages
Stages
表示構建階段,說白了就是上面提到的流程。默認有3個stages
:build
, test
, deploy
。我們可以在一次 Pipeline
中定義多個 Stages
,這些 Stages
會有以下特點:
- 所有
Stages
會按照順序運行,即當一個Stage
完成後,下一個Stage
纔會開始 - 只有當所有
Stages
完成後,該構建任務 (Pipeline) 纔會成功 - 如果任何一個
Stage
失敗,那麼後面的Stages
不會執行,該構建任務 (Pipeline) 失敗
Jobs
Jobs
表示構建工作,表示某個 Stage
裏面執行的工作。我們可以在 Stages
裏面定義多個 Jobs
,這些 Jobs 會有以下特點:
1、相同 Stage
中的 Jobs
會並行執行
2、相同 Stage
中的 Jobs
都執行成功時,該 Stage
纔會成功
3、如果任何一個 Job
失敗,那麼該 Stage
失敗,即該構建任務 (Pipeline) 失敗
文章後面附註了更多關鍵字的解釋,詳細瞭解關鍵字以及YAML語法可以自己查。
四、安裝並註冊GitLab-Runner
1.安裝GitLab-Runner
之前我們說,runner就是一個工人,它在你的服務器上等待GitLab-CI給它派活,所以我們在服務器上安裝GitLab-Runner。
安裝環境:ubuntu
其他環境參考:https://docs.gitlab.com/runner/install
-
下載
sudo bash curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
-
添加權限
chmod +x /usr/local/bin/gitlab-runner
-
新建gitlab-runner用戶
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
-
安裝
安裝時需要指定我們上面新建的用戶gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
-
啓動
gitlab-runner start
2.獲取註冊信息
進入你的gitlab項目 ——> settings —— > CI/CD ——> Runners
這裏需要記住4(URL)和5(token)
3.註冊
-
運行註冊
gitlab-runner register
-
輸入URL(你之前記住的URL)
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
-
輸入token(你之前記住的token)
Please enter the gitlab-ci token for this runner:
-
輸入description(以後可以修改)
Please enter the gitlab-ci description for this runner:
-
輸入tag(以後可修改)
Please enter the gitlab-ci tags for this runner (comma separated):
-
輸入exector
Please enter the executor: docker, docker-ssh, shell, docker-ssh+machine, kubernetes, custom, parallels, ssh, virtualbox, docker+machine: docker
這裏決定你的運行平臺,我們一般用docker(服務器需要安裝docker,安裝教程在第六節),然後回要求你輸入要使用的docker image,你可以用已有的image,也可以用自己維護的image。
Please enter the default Docker image (e.g. ruby:2.6):
到這裏,Runner就註冊好了,返回你的gitlab頁面,在settings —— > CI/CD ——> Runners就可以看到你註冊的Runner。
4. 設置(可選)
如果註冊過程中設置了tag,那麼需要在這裏設置一下,讓.gitlab-ci.yml的job沒有tag也可以運行。
點擊編輯
勾選沒有tag可運行
五、編寫.gitlab-ci.yml文件
- 在你項目根目錄下創建文件:.gitlab-ci.yml
示例程序:
stages:
- build
- test
- deploy
build_maven:
stage: build
script:
- echo "build maven....."
- echo "mvn clean"
- echo "done"
test_springboot:
stage: test
script:
- echo "run java test....."
- echo "java -test"
- echo "done"
deploy_springboot:
stage: deploy
script:
- echo "deploy springboot...."
- echo "run mvn install"
- echo "done"
script是你要執行的命令
-
當你項目push到gitlab中之後,在CI/CD ——> pipelines 中即可看到效果
-
點擊stage可以查看實際執行結果
六、 docker安裝
-
開始安裝
由於apt官方庫裏的docker版本可能比較舊,所以先卸載可能存在的舊版本:$ sudo apt-get remove docker docker-engine docker-ce docker.io
更新apt包索引:
$ sudo apt-get update
安裝以下包以使apt可以通過HTTPS使用存儲庫(repository):
$ sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
添加Docker官方的GPG密鑰:
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
使用下面的命令來設置stable存儲庫:
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
再更新一下apt包索引:
$ sudo apt-get update
安裝最新版本的Docker CE:
$ sudo apt-get install -y docker-ce驗證docker
-
查看docker服務是否啓動:
$ systemctl status docker
docker 使用參考:https://www.runoob.com/docker/docker-container-usage.html
如果你在執行docker命令時,每次都需要sudo,可以執行下面的幾行命令
sudo groupadd docker #添加docker用戶組
sudo gpasswd -a $USER docker #將登陸用戶加入到docker用戶組中
newgrp docker #更新用戶組
docker ps #測試docker命令是否可以使用sudo正常使用
七、問題
1.不安裝runner可以驗證每次提交的可用性嗎?
可以是可以的,只要你在根目錄添加了.gitlab-ci.yml文件,就可以執行一些簡單的驗證,這種情況使用的平臺是docker+machine,也可以直接在yml文件中指定docker image,看起來這樣完全可以滿足需求,但是不在服務器註冊runner,你的每個階段進行的檢測都會很慢,因爲每次都需要pull image,其次,這種情況下,你只有一個runner可用,並不是很方便。所以還是老老實實註冊runner吧!!!
後續有新的要求,持續更新!
附錄一:.gitlab-ci.yml關鍵字
script 由Runner執行的Shell腳本。
image 使用docker鏡像, image:name
service 使用docker services鏡像, services:name
before_script 執行作業前運行的腳本
after_script 作業完成後運行的腳本
stages 定義管道中的步驟,依次運行
stage 定義管道中步驟的作業段
only 指定作業限制only:refs,only:kubernetes,only:variables,和only:changes
tags 指定執行作業的runner
allow_failure 允許job失敗
when 什麼時候開始工作,
on_success 只有當前一個階段的所有工作都成功時才執行工作 。這是默認值。
on_failure 僅當前一階段的至少一個作業失敗時才執行作業。
always 無論先前階段的工作狀態如何,都可以執行工作。
manual 手動執行作業
delayed 延遲作業。最長可延遲1小時。
environment 作業部署到的環境名稱
cache 啓用緩存
artifacts job成功時附加到作業的文件或目錄
dependencies 此job依賴其他jobz,主要作用於作業優先級
converage 給定作業代碼覆蓋率設置
retry 在發生故障時,可以自動重試作業的次數。
parallel 應該並行運行多少個作業實例
trigger 定義下游管道觸發器
include 允許此作業包含外部YAML
extends 此作業將繼承的配置項
pages 上傳作業結果用於gitlab pages
variables 作業級別定義作業變量
參考文章
https://blog.csdn.net/junmoxi/article/details/82762413
https://www.jianshu.com/p/30e3f2940078
https://www.jianshu.com/p/2b43151fb92e
https://segmentfault.com/a/1190000019540360
https://blog.csdn.net/jinking01/article/details/82490688