GitLab CI + Windows Docker 的一些紀錄 Part 2

| | 0 Comments| 10:54
Categories:

想不到有什麼簡短的標題,姑且就順著上次的《GitLab CI + Windows Docker 的一些紀錄》,把這篇當成 part 2 吧。

Heresy 這邊在 2019 年建立了工作環境的 GitLab server 後,也花了好一段時間把 GitLab CI/CD 的架構弄了一個雛型出來。中間有搞錯一些東西、也拿來玩了一些其它自己的東西

而老實說,在 Heresy 這邊碰到最多問題的,基本上應該還是 Windows Docker 上的問題了…

Heresy 這邊的 GitLab CI/CD,其實目前主要還是用來做整個專案的跨平台建置測試,有部分新開發的專案也有透過 Boost Test(官方文件)來同時針對 Visual Studio 和 GitLab 做整合。

在最初寫的《GitLab 簡單的 C++ 專案腳本範例》中,基本上並沒有使用 Docker 來做建置,而是直接使用 shell 來跑。

這樣的方案,好處是單一 Runner 的架設相對簡單、也容易找到錯誤;而由於基本上就是直接在電腦上操作,所以不太容易會有額外的問題。

但是相對地,缺點就是當 Runner 變多後,要管理建置環境就會變得困難,要確保每台 Runner 都是相同版本也有可能很頭大。不過更大的問題,是如果不同的專案需要不同的建置環境的時候,也有可能會碰到因為版本不相容、而無法共用 Runner 的問題了。


為了解決這些問題,Heresy 後來也開始把 GitLab CI/CD 裡的建置方法,都轉移到 Docker 上了。

在 Linux 環境下,要使用 GitLab Ci/CD + Docker 基本上問題很少,可以很輕鬆地完成。

但是在 Windows 環境下,碰到的問題可就多了…姑且不論之前搞了很久的開發軟體安裝問題,光是的版本相容性問題,就可以把人搞到吐血

GitLab-Runner 支援性有限

由於在 GitLab-Runner 中要使用 Docker executor(官方文件)的話,會被綁死在他有支援的特定版本作業系統,而且更新得很慢…以已經出了超過半年的 Windows 10 20H2 來說,GitLab-Runner 卻到 14.1.0 才支援…

所以除非拿來當 Runner 的電腦都為了符合 GitLab-Runner 支援的版本不升級,否則就只好放棄使用比較方便的 Docker executor,而是回到 Shell executor(官方文件)、自己來下 Docker 命令了。

Windows Docker 支援性極差

就算扣掉 GitLab-Runner 支援性的問題,Windows Docker 本身的相容性問題也很大…

如果要使用效能較好的 process 隔離模式(參考),那 Windows 的版本必須要和 Windows Docker Image 的版本完全相同才能跑,也就是說如果 Host 已經升級到 Windows 10 21H1 的話,那就不能以 process 模式來跑任何基於 Windows 20H2 的 Docker image 了…

就算自己願意積極一點去用新版的 Windows 基礎映像來重建,微軟本身釋出新版本 Docker Image 的速度也不快,像以目前 21H1 出了兩個月了,官方卻始終沒有釋出對應的基礎映像檔…

所以如果想用 process 隔離模式來跑的話,勢必也得把 Runner 綁在較舊的作業系統版本、直到微軟釋出新版的映像檔上。

如果切換到 Hyper-V 隔離的話,基本上就比較不會有這樣的相容性問題了。但是相對地,Hyper-V 模式下預設只有兩顆 CPU、2GB 記憶體,效能很糟…

想要調製的話,雖然根據官方說明(連結),在設定的介面中應該是可以透過圖形介面調整 Hyper-V 的可用資源的;但是在 Heresy 這邊切換到 Windows container 後就看不到設定的介面了… orz

而同樣的設定雖然可以透過在執行 docker run 的時候,加上「–cpus」和「–memory」(官方文件)來調整,但是由於每台 runner 的配置又不相同,變得不適合寫死在腳本…


Heresy 這邊目前的解決方法,是決定在執行的時候,透過 PowerShell 來抓系統的 CPU 與記憶體的量,然後再來設定 Docker 要使用多少資源。

取得系統 CPU thread 數量的指令是:

(Get-CimInstance Win32_ComputerSystem).NumberOfLogicalProcessors

以 GB 為單位、取得記憶體量的指令則是:

(Get-CimInstance Win32_PhysicalMemory | Measure-Object -Property capacity
-Sum).sum /1gb

為了跨以後可以重複使用腳本,這邊是把它寫成一個 GitLab CI 的範本,內容大致如下:

.windows_setting:
  variables:
    ErrorActionPreference: STOP # make PowerShell can make job fail     MaxCPU: 16
    MaxMem: 32
   before_script:
   - "[System.Console]::OutputEncoding = [System.Console]::InputEncoding = [System.Text.Encoding]::UTF8" # Set as UTF-8
   - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
   - $ThreadNum = ( $MaxCPU, ((Get-CimInstance Win32_ComputerSystem).NumberOfLogicalProcessors - 4) | Measure -Min).Minimum
   - $MemSize = ( $MaxMem, ([int]((Get-CimInstance Win32_PhysicalMemory | Measure-Object -Property capacity -Sum).sum /1gb) - 4) | Measure -Min).Minimum
   - $DOCK_CONF = ("--isolation hyperv --cpus=$ThreadNum --memory=" + $MemSize + "g --rm -v " + (Get-Location).path + ":c:code").Split(" ")
   - echo "Use $ThreadNum cores and $MemSize GB memory"

可以看到,這裡是透過「before_script」 ,讓 runner 在執行工作前,先跑這些指令。

為了不要讓 runner 占用過多資源,所以這邊事先設定最多使用 16 個 thread、32GB 記憶體。

而為了留一些資源給 host 所實際上,最後使用的 CPU 數量($ThreadNum)是 min( TOTAL_THREAD_NUM – 4, $MaxCPU),算是至少留了 4 個 thread 給 host;記憶體的部分($MemSize),則是 min( MAX_MEMORY – 4, $MaxMem)、至少保留 4GB 給 host。

之後則是把這些數值、包含一般的 Docker 執行參數,都定義成 $DOCKER_CONF 這個變數,方便之後使用。(包括統一把目前的路徑 mount 成 c:code

不過這邊要注意的是,在 PowerShell 裡面如果是直接用一個字串包含多個用空白區隔的參數,那在給其他程式當參數的時候,是會有問題的;所以這邊需要先透過 Split()、根據空白來拆開來才能用。


而本來的 .gitalb-ci.yml 則可以在 include 前面定義的範本檔案後(參考),把 job 寫成:

build-windows:
   extends: .windows_setting
   variables:
     DOCKER_IMAGE: $DOCKER_IMAGE_PATH/windows/builder:$DOCKER_TAG_POSTFIX
   script:
   - docker pull $env:DOCKER_IMAGE
   - docker run $DOCK_CONF $env:DOCKER_IMAGE msbuild /m /p:Configuration=Release c:code

基本上,就是透過 extends(官方文件)繼承前面定義的「.windows_setting」這個範本後,直接拿 $DOCKER_CONF 當作主要的 docker 執行參數來用了~

如此一來,之後如果有更好的 Docker 參數設定方法,也可以統一修改就好了。

目前這樣的方案算是可以正常運作,不過偶爾會出現「The requested resource is in use」的錯誤、導致 Docker 無法啟動,就不知道該怎麼辦了…

Leave a Reply

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *