Gitlab CI-2.CI流程

參考文檔：

1. GitLab Documentation：https://docs.gitlab.com/ce/
2. Installation and Configuration using omnibus package：https://docs.gitlab.com/omnibus/README.html#installation-and-configuration-using-omnibus-package
3. Configuration of your jobs with .gitlab-ci.yml：https://docs.gitlab.com/ce/ci/yaml/README.html
4. Gitlab Community Edition 鏡像：https://mirrors.tuna.tsinghua.edu.cn/help/gitlab-ce/
5. Gitlab Runner：https://docs.gitlab.com/runner/
6. GitLab Continuous Integration：https://docs.gitlab.com/ce/ci/
7. 基於OpenSSL自建CA和頒發SSL證書：http://seanlook.com/2015/01/18/openssl-self-sign-ca/

三．Gitlab CI流程

1. Gitlab-CI流程

1. 在項目repository根目錄下設置".gitlab-ci.yml"文件，定義pipeline中的stage，job等具體行為（what to do）;
2. 設置runner服務器（開發或生產環境），並將runner注冊到對應的project（where to do）；
3. commit或push時，gitlab觸發CI pipeline（trigger，主動檢測".gitlab-ci.yml"）；
4. runner從gitlab pull代碼，按".gitlab-ci.yml"定義執行腳本；
5. 返回結果。

2. 相關概念

1）pipeline

合並分支或代碼提交即觸發一次pipeline，一次pipeline即一次構建任務。

2）stage

stage即上述構建任務中的各個構建階段，如test，build，deploy等；一個pipeline可以定義多個stage。

stage特點：

1. 所有的stage按順序運行，前一個stage完成后，下一個stage才會開始執行；
2. 只有當所有的stage都完成后，該構建任務(pipeline)才會成功；
3. 如果一個stage失敗，那么下一個stage不會執行，該構建任務(pipeline)失敗。

3）job

job是每個stage構建階段里具體執行的工作，stage與job是一對多的關系（同pipeline與stage），即一個stage里可以定義多個job。

job特點：

1. 同一個stage中的jobs並行執行；
2. 同一個stage中的jobs都執行成功時，該stage才會成功；
3. 如果任何一個job失敗，那么該stage失敗，即該構建任務 (pipeline) 失敗。

4）GitLab runner

GitLab runner是pipeline/job的具體執行者。

四．Gitlab-CI流程驗證

1. 安裝gitlab-ce

1）安裝runner-repo

# gitlab-runner，使用國內鏡像源；
# 另外gitlab-runner 10之前，可執行文件名稱為gitlab-ci-multi-runner
[root@gitlab-runner ~]# vim /etc/yum.repos.d/gitlab-runner.repo
[gitlab-runner]
name=gitlab-runner
baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-runner/yum/el7
repo_gpgcheck=0
gpgcheck=0
enabled=1
gpgkey=https://packages.gitlab.com/gpg.key

2）安裝gitlab-runner

# 安裝gitlab-runner時會創建gitlab-runner賬號，后續不少操作主體即gitlab-runner賬號，需要注意權限問題
[root@gitlab-runner ~]# yum makecache
[root@gitlab-runner ~]# yum install gitlab-runner -y

2. gitlab-runner注冊

1）注冊gitlab-runner

# gitlab-runner分shared runner，specific runner，group runner等，這里注冊為specific runner；
# --tls-ca-file：由於采用了自簽名的ca證書，gitlab-runner注冊時，需要使用ca根證書驗證gitlab服務，注意提前創建/etc/gitlab-runner/certs/目錄，並上傳ca根證書；
# -n：gitlab-runner注冊時，可采用--interactive或--non-interactive方式，-n即--non-interactive方式；
# --url：注冊地址獲取方式，登陸gitlab，進入對應project，Setting-->CI/CD-->Runner(Expand) -->Setup a specific Runner manually，即可查看；
# --registration-token：每個project有唯一的token，獲取方式同上；
# --name：runner名稱，非必須項，建議區分；
# --tag-list：注冊的runner對某分支（branch）有效，多分支時用”,”區分，非必須項，建議區分；
# --executor：在不同場景下構建（build）的執行器，常用的有shell與docker等；
# --locked：鎖定runner只能被當前project所用，默認即true；
# --run-untagged：在--tag-list為空時，默認值為true；在--tag-list不為空時，默認值為false；
# runner注冊成功后即運行
[root@gitlab-runner ~]# gitlab-runner register --tls-ca-file /etc/gitlab-runner/certs/ca.crt -n \
 --url https://gitlab.netonline.com/ \
 --registration-token xJBn7PkKSAYmsPE-pHQK \
 --name gitlabrunner \
 --tag-list master \
 --executor shell \
 --locked true \
 --run-untagged false

2）查看gitlab-runner

# 注冊成功后，在runner服務器上生成config.toml文件，記錄注冊信息；
# 如果gitlab-runner以root身份執行，生成/etc/gitlab-runner/config.toml；
# 如果gitlab-runner以non-root身份執行，生成~/.gitlab-runner/config.toml；
# 通過命令”ps aux | grep gitlab-runner”即可查看執行身份，config文件以及runner用戶
[root@gitlab-runner ~]# ps aux | grep gitlab-runner

# concurrent：全局參數，可運行job的限制，”0”表示不限制；此值是自動生成，如果在1台服務器注冊多個runner，值也會自動更新；
# check_interval：全局參數，在多runner的情況，每runner向gitlab發起請求的間隔時間，默認值3s，如果設置為”0”或更低，使用默認值；
# [[runner]]：runner相關的設置在特定section中
[root@gitlab-runner ~]# cat /etc/gitlab-runner/config.toml

通過gitlab portal查看：登陸gitlab，進入對應project，Setting-->CI/CD-->Runner(Expand) -->Setup a specific Runner manually，即可查看，如下：

3. 配置.gitlab-ci.yml

# 以一個簡單的shell腳本執行為例，在.gitlab-ci.yml中定義執行腳本，需要注意yaml文件的格式；
# .gitlab-ci.yml位於repository的根目錄
[root@gitlab-runner ~]# cd ~/gitlab/
[root@gitlab-runner gitlab]# vim .gitlab-ci.yml
# stage：定義pipeline的執行順序，階段名也可自定義，但不能與默認的”test”，“build”，“deploy”等沖突；
# stage為可選項，如果job無執行順序要求即可取消
stages:
  - test
  - build

# job名可自定義；
# 如果定義了stage，job中可聲明stage的階段；
# tag：聲明觸發的分支，如果不指定，默認無法觸發CI流程；但可開啟已注冊runner的”Run untagged jobs”參數使無tag的job可觸發流程；
# script：定義具體的任務，這里需要注意執行任務的主體的權限；
# 如在某階段多分支執行相同的job，但在其他階段需要根據分支不同執行不同的job時，可采用only字段區分分支；
# 更多關鍵字段可查看：https://docs.gitlab.com/ce/ci/yaml/README.html
job_1:
  stage: test
  tags:
    - master
  script:
    - whoami
    - pwd

job_2:
  stage: build
  tags:
    - master
  script:
    - touch ci.txt

4. 觸發CI流程

# 提交.gitlab-ci.yml到gitlab對應repository；
# 第一次push時，帶上-u參數，如：git push -u orogin master；
[root@gitlab-runner gitlab]# git add .
[root@gitlab-runner gitlab]# git commit -m "commit .gitlab-ci.yml"
[root@gitlab-runner gitlab]# git push -u origin master

5. 查看執行結果

1）pipelins

通過gitlab portal查看：登陸gitlab，進入對應project，CI/CD-->Pipelines，如下：

2）job

點擊pipelie的status，這里即"passed"（也有"failed"，"pending"等狀態），進入具體pipeline詳情頁面（或：登陸gitlab，進入對應project，CI/CD-->Jobs，即可查看），點擊對應的job，即可查看job的執行返回結果，如下：

Job_1

從job的返回結果得到以下信息：

1. 執行器是shell；
2. 執行者從gitlab repository拉取代碼，存放在執行者home目錄下，具體路徑為~/builds/RUNNER-TOEKN/X/GITLAB-USER/PROJECT-NAME/目錄下；
3. 執行者是gitlab-runner賬號（涉及到執行權限問題）

Job_2

6. docker executor

以下為設置docker executor的簡單介紹，CI流程不再演示。

1）以container的形式運行gitlab-runner

采用docker executor的模式不是一定需要在gitlab-runner container中注冊，也可在宿主機中注冊，這里只是演示另一種啟動gitlab-runner服務的可能性。

# 因驗證用的gitlab域名無法被dns解析，將本地/etc/hosts文件映射到容器內；
# 映射自簽名的ca根證書，注冊時需要；
# 將注冊生成的config.toml文件映射到宿主機，便於修改參數；
# 將docker daemon的sock映射到容器中，container可以利用宿主機docker來創建container
[root@gitlab-runner ~]# docker run -d --name gitlabrunner \
 --restart=always \
 -v /etc/hosts:/etc/hosts \
 -v /etc/gitlab-runner/certs/ca.crt:/etc/gitlab-runner/certs/ca.crt \
 -v /srv/gitlab-runner/gitlabrunner/config:/etc/gitlab-runner \
 -v /var/run/docker.sock:/var/run/docker.sock \
 gitlab/gitlab-runner:latest

# 查看
[root@gitlab-runner ~]# docker ps

2）注冊docker executor

# 雖然executor container是由gitlab-runner container創建的，但其與運行gitlab-runner服務的container是同等關系而非從屬關系；
# 使用container做executor，使得每一個pipeline的虛擬構建環境都干凈、輕量，相互隔離，互不影響；
# executor設置為docker時，定義executor的鏡像為：docker:stable，為官方推薦，此鏡像集成了docker客戶端；
# 如果job是構建鏡像，則executor必須使用具備docker客戶端的鏡像；
# docker socket binding模式：通過參數”--docker-volumes /var/run/docker.sock:/var/run/docker.sock”實現，將docker daemon的sock映射到容器中，container可以利用宿主機docker來創建container，
# 如果是在宿主機中注冊，也可以使用”--docker-privileged”（docker-in-docker executor模式，如果需要編譯構建鏡像，需要在.gitlab-ci.yml中使用docker:dind services，並通過變量指定docker daemon的tcp端口）代替docker socket binding模式；
# 兩種模式在config.toml文件中均有體現，個人建議docker socket binding模式
[root@gitlab-runner ~]# docker exec -it gitlabrunner \
 gitlab-runner register --tls-ca-file /etc/gitlab-runner/certs/ca.crt -n \
 --url https://gitlab.netonline.com/ \
 --tag-list "dev" \
 --registration-token xJBn7PkKSAYmsPE-pHQK \
 --name gitlabrunnerdev \
 --executor docker \
 --docker-image docker:stable \
 --docker-volumes /etc/hosts:/etc/hosts \
 --docker-volumes /var/run/docker.sock:/var/run/docker.sock

3）查看config.toml

[root@gitlab-runner ~]# cat /srv/gitlab-runner/gitlabrunner/config/config.toml