iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 21
0
DevOps

用 GitLab CI 玩轉自動化測試與佈署系列 第 21

Day21 - GitLab CI 選擇指定的 runner 來承接工作,談標籤 tags

在流水線的進行中,有些時候工作能否被執行,跟執行工作的環境是絕對相依的,以 GitLab.com 提供的免費 GitLab Runner 來說,通常承接工作的 runner 環境都在 GitLab 提供的 k8s 環境使用 docker+machine 建立而成。而,如果有些工作必須在特定的作業系統如 Windows 上才能執行呢,那應該怎麼指定呢?

使用 tags 指定特定的 runner 承接工作

在 GitLab CI 的工作定義裡,可以透過 tags 來指定「符合這些 tag (標籤) 的 runner」來承接工作,舉例來說:

job:
  tags:
    - docker

上面的這個工作描述,意思是說:指定 GitLab Runner 中 Runner 的 Tag 有標示 docker 的 runner 來承接工作。而以 GitLab Runner 的角度來思考,則是在詢問 Server 上有沒有可以執行的工作時,根據自身定義的 Tag ,依序在工作佇列中依據工作的標籤,來判斷是否可以承接下該工作。

所以 GitLab CI 工作上標註的 tags 就可以想像成是定義該工作「可被執行的環境規格」,而 GitLab Runner 上標註的 tags 就像是能力標籤「Runner 的技能證照」,因此 Runner 上標注的 Tags 可能可以很多個,但可以承接的工作所標註的 tags 必須自己都有,所謂門當戶對。接著再看一個例子:

job:
  tags:
    - windows
    - win10-2004

根據 tags 是在定義可被執行的環境規格,如上面的範例即定義著,這個工作必須要「同時」擁有 windowswin10-2004 兩個 Tag 的 GitLab Runner 才能承接此工作。而當定義的環境規格沒有 Runner 可以承接時,則該工作會持續顯示顯示為pending 及標注這條流水線卡住 stuck (如下圖)。

插入標注卡住的畫面

或在工作流程細節頁面中的畫面

工作流程細節頁面中的畫面

所以當出現 stuck 的時候,就應該檢查一下,是否根本不存在可以執行卡住的工作的 Runner 或可以執行工作的 Runner 太少,導致工作持續的在等待而被 pending

設定 runner 的工作標籤

檢查系統中可用的 GitLab Runner 可以透過 「Settings -> CI/CD -> Runners -> 點選 Expand」後看到目前該專案中可使用的 runner。

顯示介面的位置

在專案中,有兩種 Runner,一種是專案本身自行擁有的 Runner,另外一種則是所謂「shared Runner」由 GitLab 系統或整個組織/群組共用的 GitLab Runner。在專案層級中,僅能設定專案本身擁有的 Runner。

顯示 Runner 的列表

在上面的圖示中即可以看到 GitLab 官方提供的 shared Runner 其實每個 Runner 都有
Runner 工作 Tag的設定有兩個時間點,一是在設定新的 Runner 時,在設定 Runner 的過程即會作一次 tag 的設置。

註冊新的 runner 時設定 tag

另一是連線完成後,可在系統介面上透過編輯,在介面中進行 tags 的設定。如下點選編輯的按鈕:

標注編輯

而後在介面中進行 tags 的編輯來調整 Runner 的 tags 標籤。

調整 Runner 的 tags 標籤

因此在註冊 Runner 時如果標註錯誤或 runner 的屬性有所變更,在介面上就可以做調整了。

總結:

GitLab CI 的 tags 元素,對於工作本身,可以說是「可被執行的環境規格」,而對 GitLab Runner 來說,Tags 標註,則像是「Runner 的技能認證」,Runner 可以有很多的技能,但也僅能承接本身會的技能的工作。

接下來,依然是關於 GitLab CI 設定上的小細節,我是墨嗓(陳佑竹),期待這系列的文章能夠讓人有些幫助。


上一篇
Day20 - GitLab CI 返璞歸真續談 script 之自訂段落 section
下一篇
Day22 - GitLab CI 控制工作終止因素的各種方法,談 retry、timeout
系列文
用 GitLab CI 玩轉自動化測試與佈署31

尚未有邦友留言

立即登入留言