Gitlab-CI持續集成之Runner配置和CI腳本

 

 

 

 

Gitlab-CI持續集成之Runner配置和CI腳本

1、簡介

1. 爲實現持續集成，需爲該項目準備如下兩樣東西：

1）軟件集成腳本.（gitlab-ci.yml）

2）一臺Runner服務器

固然，考慮到集成環境的配置，還須要docker鏡像做爲載體。

2. 基本流程以下：

1）安裝Runner服務器，註冊和項目對應的Runner Service（後續再說Shared Runner），編寫集成腳本；

2） 每當push代碼， 自動觸發腳本，Gitlab將變更告知Gitlab-CI，CI鏈接Runner服務器，找到關聯的Runner Service，Runner負責更新代碼到本地，並執行集成腳本。

2、安裝Runner

1. Centos7使用yum安裝

1）添加yum源

a.官方源

1 curl –L https://package.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

b.國內源

cat << EOF >> /etc/yum.repos.d/gitlab-ci-multirunner.repo

[gitlab-ci-multi-runner]

name=gitlab-ci-multi-runner

baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ci-multi-runner/yum/el7

repo_gpgcheck=0

gpgcheck=0

enabled=1

gpgkey=https://packages.gitlab.com/gpg.key

EOF

sudo yum makecache

2）安裝1.11.2版本

sudo yum install gitlab-ci-multi-runner-1.11.2-1

  因爲公司Gitlab版本目前是8.X,官方Gitlab最新是9.0，Runner最新版不支持9.0如下版本的Gitlab，所以只能安裝該版本。視Gitlab服務器的版本而定。

3）Runner用戶權限

Runner默認會在服務器上建立gitlab-runner用戶， 全部的Runner Service則默認經過該用戶執行集成腳本，所以該用戶須要較高的權限。尤爲是使用Docker鏡像時，必須加入docker組。

 

sudo usermod -aG docker gitlab-runner

2.Ubuntu使用apt-get安裝

1）添加apt源

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash

2）安裝1.11.2版本

 

sudo yum install gitlab-ci-multi-runner-1.11.2-1

3）Runner用戶權限（同上）

3.安裝包安裝

下載二進制文件或相應系統的安裝包安裝便可，gitlab-ci-multi-runner-1.11.2安裝包。

3、註冊Runner

1.進入本身的Project—>設置Runners

 

 

2.查看Specific Runners裏面的url和token

 

 

 

3.在Runner服務器執行註冊命令

gitlab-runner register --non-interactive \

    --url http://gitlab.xxxxx.com/ci \

    --registration-token GWGGXZNxbxabcdMaXZhj9 \

    --name Crowd_Job_CI \

    --tag-list 172.17.3.126 \

    --run-untagged=true \

    --executor shell \

    --builds-dir /home/gitlab-runner \

   --config "/etc/gitlab-runner/config.toml"

上述命令選項含義( * 爲必選項 ) ：

--url                  項目CI地址*

-- registration-token  項目裏剛纔看到的token，互相關聯的標誌*

--name                 該Special Runner服務名，便於後臺管理（查看、刪除、調用）*

--tag-list             該Special Runner標籤，集成腳本中能夠經過指定tag關聯

--run-untagged         是否運行無標籤的集成腳本，必須用等號

--excutor              規定集成腳本執行的環境，還能夠是docker等*

-- builds-dir          默認該文件夾，能夠自定義項目集成初始化的位置

--config               默認配置文件，存儲註冊信息，能夠自定義不一樣的配置文件

刷新頁面看到已經註冊成功，可使用了。

 

4、運行Runner

假設集成腳本已就緒，那麼就須要運行Runner

1.使用Specific Runner

     1）run-single

gitlab-ci-multi-runner run-single \

--url http://gitlab.sensenets.com/ci

--token 37fe0fa59e3475e20e24b6e6afc7c3

--executor shell

固然這裏也能夠指定註冊時的大部分參數，不過不管如何url、token（Runner的token，而非註冊時項目的token）、executor這三個參數是必須的。

run-single命令很簡單的把咱們剛纔註冊的Runner運行起來了，若是這個Runner對應的項目有更新，這個運行的服務就會去執行腳本內容。

即使咱們不運行run-single命令，默認會有一個已經運行狀態的Runner Service，名稱就是gitlab-runner，會自動執行全部註冊過的Runner，但同時只能執行一個任務。

 

2）run 、install、start

 

     上圖說明了Runner的原理：

     安裝gitlab-ci-multi-runner服務器，至關於一個勞務公司的創辦，它管理Runner工人，外包各類項目Project。

註冊的目的是把項目和Runner鏈接起來，由於部分項目的Runner可能須要定製。Runner比如是一個工人，在勞務中心（gitlab-ci-multi-runner）登記合同，供職於咱們的Project（可是當他比較閒的時候，也能夠去其餘公司兼職）。

可是對應的RunnerService至關於Runner工人的管理層，一個管理層能夠管理一個甚至多個工人。勞務公司默認有一個公用的管理層，服務名就是上面所說的gitlab-runner，若是咱們不指定管理層，那麼勞務公司全部工人都被gitlab-runner管理運行。這個管理人員比較弱，一次只能管理一個項目，其餘項目會等待。

run、run-sigle至關於一次性的外包項目，很是具備針對性。

install則是把一個或者幾個runner包裝好，而後start，就是一個有着管理服務的工人體系，隨時待命。

當Project更新，觸發Runner服務器上的Runner Service（某管理隊伍），Runner Service根據本身的配置信息，和項目的需求（tag指定某個工人），派遣Runner工人去執行Project給予的任務（Job）。

配置信息至關於花名冊，不註冊僅僅寫一個花名冊是不行的，working_dir至關於辦公地點。

下面安裝兩個服務並啓動：

gitlab-runner install \

    -n  "jiukun_self_runner" \

    -d "/home/jiukunz" \

    -c "/etc/gitlab-runner/config_jiukun_test.toml" \

    -u gitlab-runner

gitlab-runner install \

    -n  "jiukun_self2_runner" \

    -d "/home/jiukunz" \

    -c "/etc/gitlab-runner/config_jiukun_test.toml" \

    -u gitlab-runner

 

1 gitlab-runner start -n jiukun_self_runner
2 gitlab-runner start -n jiukun_self2_runner

 

 

其中，-n爲安裝的服務名稱，-d爲工做路徑，-c爲配置文件，-u爲執行用戶（服務名稱和執行用戶必須指定，配置文件和工做路徑可使用默認路徑）

 

     其實，當咱們執行上述安裝命令時，gitlab-ci-multi-runner後臺實際是將run命令寫入/etc/systemd/system/jiukun_self_runner.service文件，使之成爲一個單獨的服務：

 

2.使用Shared Runner

     使用share runner須要管理員權限，聯繫公司gitlab管理員，獲取token。而後使用和Special Runner同樣的方法註冊成功。

     進入任意項目的Runner頁面，將看到如下內容：

 

 

 

     這裏我重複註冊了兩次，能夠看到Runner不管是名字仍是tag均可以重複，可是Runner的token卻不相同，實際上區分不一樣的Runner工人只須要兩樣東西就是url和token。固然並不建議進行相同命名，不便於管理。

     公司全部的項目默認均可以使用Shared Runner，而不須要重複配置。

1）好處：對於大多數Runner的配置實際上是徹底相同的（一樣的executor，一樣的配置文件和工做路徑，一樣的依賴環境），若是每一個項目都去一個個註冊不只麻煩，並且不方便遷移，這時可使用shared runner。

2）不足：若是一個項目的編譯所需的exector等其餘配置（配置文件有更多可選配置），而且和其餘項目須要單獨管理，這時最好使用Special Runner，並鎖定該Runner爲項目自己使用，單獨管理。

 

5、管理Runner

1.註冊的runner列表

gitlab-runner list \
    --config "/etc/gitlab-runner/config_jiukun_test.toml"

2.查看runner鏈接狀態

gitlab-runner verify \
    --config "/etc/gitlab-runner/config_jiukun_test.toml"

3.取消註冊（移除）

gitlab-runner unregistry \
    --url http://gitlab.xxxxxx.com/ci \
    --token 9c1bb50065661ba766023016f6ebf2

     不能直接在project的web端進行remove操做，不然這裏會執行失敗

4管理gitlab-runner服務

gitlab-runner status \

    -n jiukun_self_runner.service

    不指定服務名，則默認爲gitlab-runner服務

gitlab-runner stop \

    -n jiukun_self_runner.service

gitlab-runner restart \

    -n jiukun_self_runner.service

gitlab-runner uninstall \

    -n jiukun_self_runner.service

執行uninstall會卸載該服務，與之對應的runner將沒法經過該服務運行，請確保對應的CI任務已中止。

6、集成腳本

     將集成腳本命名爲.gitlab-ci.yml或者.gitlab-ci.yaml，放置在對應項目倉庫分支的根目錄下。

 

1.  yaml語法

大小寫敏感、使用縮進表明層級、不容許使用Tab縮進，只能使用空格，縮進並沒有統一限制，但同級關係內要保持對齊便可。#表明註釋。

語言格式裏存在減號和冒號這些特殊字符，所以要注意千萬別寫成中文的字符格式。

減號對應的是數組，冒號對應的是鍵值對（對象）。

2. 關鍵詞

     1）image

若是使用docker做爲Runner的executor，而且沒有設置默認的鏡像，此處須要設置鏡像；不使用能夠省略

2）sevices

若是使用docker集羣服務，能夠直接調用服務；不使用能夠省略

3）stages

定義各個階段名稱，若是省略，CI默認爲三個階段

每一個job都必須定義其所屬的階段，若是不定義，默認均屬於build階段；同階段任務並行對待，上一階段全部任務執行成功，纔會繼續執行下一階段；語句依次執行，若是某一語句執行失敗，將返回錯誤碼，並宣告CI失敗。

若是定義stages，則job中的stage必須與之相對應。

4）before_script

           定義在全部腳本運行以前執行的語句

5）after_script

           定義在全部腳本運行以後執行的語句

     6）variables

     定義環境變量

     7）cache

     定義下個job會使用到的文件或內容

3. Jobs

     .gitlab-ci.yml腳本內容的主體爲一個個job，沒有數量限制，每一個Job名稱能夠相同也能夠不一樣（最好不要相同），能夠大小寫；每一個Job內部至少有一個關鍵詞。經常使用關鍵詞以下

     1）stage

     和腳本全局stages對應（若是全局未定義，可以使用默認）

     2）image、services、variables

     同全局關鍵詞

     3）only

     規定該腳本響應分支（項目其餘分支不會觸發該腳本；若是不定義，會檢測全部分支；與之相反的關鍵詞是except）

     4）before_script、after_script

     同全局關鍵詞（注意，若是同時存在，會覆蓋全局關鍵詞對應列表內容）

     5）script

     腳本主體，使用方法和在shell內同樣，將在對應executor內運行一個shell環境，執行腳本內容。每一個Job的shell環境不一樣（Job結束，該環境自動關閉）。

     6）tags

     指定Runner的標籤（一般一個項目有不少Runner，依靠tag區分）

     7）artifacts

     指定Job的產出文件路徑，若是該關鍵詞設定，能夠直接在pipeline頁面下載該文件

     8）when

     默認一個job只有在上一階段全部job成功纔會執行，經過when能夠改，一般用來清理環境使用，以避免失敗後沒法清理，有四種可選參數。

      on_success（上一階段全部Job成功才執行）    

      on_failure（上一階段任意Job失敗就執行）

      always（老是執行）                          

      manual（此階段由UI界面交互執行）

 

備註：以上純屬原創，學習來源爲gitlab-runner官方中文文檔、gitlab-runner英文文檔、gitlab-ci英文文檔。如需轉載請註明出處，後續繼續完善。