GitLab CI + Windows Docker 的一些紀錄

| | 0 Comments| 15:58
Categories:

Docker(官網)這種比虛擬機器更輕量化的「容器」虛擬化技術,基本上算是這幾年來一個滿重要的技術。透過 Docker,他可以將需要的環境打包、建構出類似虛擬機器,但是更小、更彈性的可移植環境,在需要自動佈署的環境上,應該算是很實用的一種技術。(參考介紹參考介紹

不過由於工作的領域不同,所以 Heresy 其實之前都沒有去碰這一個技術;真的開始接觸到,是之前試著使用 Docker 來架設 GitLab Server 的時候開始的。

後來,Heresy 也很認真地開始搞整個 GitLab CI/CD 的架構,試著透過 GitLab 的系統來做一些程式開發的自動化建置、測試。最初,考慮到環境的熟系程度,Heresy 都是直接使用作業系統的 shell 來作為 gitlab-runner 的 executor。

<!–more–>

而在整個弄到一定程度後,也發現如果能把 runner 的 executor 改成 Docker 的話,的確是有一定程度的幫助的!

怎麼說呢?如果 Runner 是用 shell 在跑的話,基本上就要先幫 runner 的系統安裝好必要的工具、函式庫等等東西。如果有好幾台 runner、就需要每一台都各自安裝成一樣的環境;而日後如果有要更新版本、或是新增套件的話,就需要每一台各自去做調整。

假設又碰到多個專案要共用同一組 runner,但是需要的套件卻有衝突的話,那就會非常麻煩了…

雖然透過虛擬機器的確可以解決這個問題,但是虛擬機器的映像檔其實也不小,要更新時也較為麻煩,所以管理上還是沒這麼方便。

這時候,Docker 就可以解決這個問題了!

透過 Docker,可以針對不同的專案建立需要的環境、而不會影響到系統、也不容易碰到版本衝突的問題;同時,Docker 的映像檔可以直接透過 Dockerfile 來產生,相對好控制、也可以進行版本控管。而透過 Docker registry 的機制,也可以讓 gitlab-runner 自己把需要的 docker image 下載下來、建立出需要的容器,更解決了更新和佈署的問題。


研究了一下、有了一點概念之後,Heresy 就投下去玩了。針對 Linux 的 Docker 環境的部分,基本上都還算玩得很順利,目前也已經把這邊的主要專案改成用 Docker 來建置了。

但是到了 Windows 環境的時候…恩,開始碰到一堆問題了。而最後,到了寫這篇文章的時候,這些問題也沒辦法完全解決,變成只能暫時放棄的狀態了。這篇文章,基本上就是一個簡單的問題紀錄了。

Windows Docker 映像檔的肥大

剛開始玩 Linux Docker 的時候,所使用的 base-image 是 ubuntu,檔案大小不到 70MB,安裝完必要的開發環境、函式庫後,容量到達了 3.8GB 左右、Heresy 就覺得已經大的有點誇張了。

而 Windows 呢?Windows 最單純的 base-image 基本上就已經是 5GB+ 的大小(官網、例如 servercore:1903 的大小就要 12.9GB…),感覺根本是把整個基礎 OS 都包起來了?而且在這肥大的映像檔的狀況下,Windows 容器還是有版本相容性的問題(參考),真的讓 Heresy 懷疑他包這麼多檔案的目的到底是什麼? = =
(這可能是因為 Windows 有使用所謂的「Hyper-V 容器」這樣的執行模式階段的關係)

這還是沒有安裝開發環境的狀況。如果要安裝 Build Tools for Visual Studio 來建置 Visual C++ 的專案的話,還需要使用包含 .Net Framework SDK 的基底影像,其容量更是往上跳了不少。

對於比較複雜、需要工具比較多的專案,整個映像檔要弄到能用,感覺可能接近 20GB 是跑不掉的了…(到時候還得改設定才行)
某方面來說,感覺也已經快要可以和 VM 的虛擬硬碟相比了。

難以處理的程式安裝

Windows 雖然有提供 batch(cmd)和 PowerShell 等 CLI(Command-Line Interface)環境,但是基本上還是一套以圖形介面為基礎的作業系統。

但是 Docker 本身並沒有辦法支援圖形介面,所有的操作都需要以 command line 的形式來進行。

這也導致了本來在 Windows 環境下、很方便就可以完成的安裝流程,在要安裝在 Docker 上的時候,有可能會碰到各式各樣的詭異狀況。

先不說別的,光是要能成功地建立出一個包含 Build Tools for Visual Studio 的 docker image 出來,就花了 Heresy 快要一個禮拜的時間…

雖然微軟官方有提供對應的 Dockerfile 的範例(參考參考),但是在 Heresy 這邊卻是怎樣都沒辦法建置出一個可以用的 Docker image。

直接使用官方 vs-2017 的 Dockerfile 來建置的話,不管怎麼測試,Docker 內就是看不到 C:BuildTools 這個應該要有開發工具的資料夾…更慘的是,這邊的安裝錯誤,連個錯誤訊息都不給…

後來是找到另一個範例(連結),才終於建置出一個可以用的版本(17.8GB)。
而這時,也才大概確定,Build Tools for Visual Studio 2017 大概只能搭配 mcr.microsoft.com/dotnet/framework/sdk:3.5-windowsservercore-1709 這個 base image 使用、而不能用更新版的 base-image。

雖然官方有說 Visual Studio 2017 version 15.8 以前的版本無法安裝於 1809 以後的版本,但是…現在 Visual Stduio 2017 不是已經更新到 15.9 了嗎?而且 Heresy 有試過用 1803 一樣不行啊…

老實說,這部分其實應該不能算是 Windows Docker 的問題,而是很多 Windows 程式的 installer 針對 CLI-only 的環境其實設計得並不好了…

至於其他程式(Qt、CUDA)的安裝?Heresy 還沒測試就先放棄了。

Windows Docker 的隔離模式

Windows Docker 有兩種隔離模式/運作模式(官網),一種是早期的 Hyper-V 模式,實際上就是透過小型的 Hyper-V 虛擬機器來跑。透過這樣的方式,Windows Docker 也可以在一定的程度上支援 Linux 容器,但是相對地會有一些效能、使用資源上的限制。

而從 Windows 1809 後,Windows Docker 就有支援和 Linux 一樣的 process 隔離了;在個人來看,這種模式應該才算是 Docker 最初設計的目的。

但是如果使用這種模式的話…舊版的 Windows base-image(像是現在被 VS2017 綁死的 1709…)基本上不能用,而同時也不能用 Linux 容器了。

GtLab Runner 支援度不佳

其實前面的問題大多都有解,或是可能有辦法解。但是最後讓 Heresy 放棄繼續研究下去的,是 Gitlab-Runner 本身的問題了…

當 Heresy 成功弄出第一個映像檔後,真的要掛到 GitLab-Runner 上跑的時候,就馬上碰到

ERROR: Preparation failed: could not determine windows version

的錯誤。

而查了一下,這個問題是因為 GitLab Runner 在使用 Docker 來執行的時候,針對 Windows 的支援,是針對不同版本寫死的(參考);而目前又只支援 1803 和 1809 兩個版本,所以在 Heresy 這邊主要的機器都已經升級到 1903 的情況下,就變得完全不能用了…

雖然官方看來是已經知道有這個問題了,不過看來要支援似乎還沒那麼快。而如果官方沒有想要設計一個可以跨版本的方法,那之後應該每次微軟推出大升級,都繪出一次問題了…

檔案存取的問題?

另外,之前在使用建置出來的容器想要用 bind mount(官方文件)的形式把專案拿到容器裡面建置,結果看起來似乎是以 symbolic link(SYMLINKD)的形式存在的,而在平行編譯的時候,會出現檔案存取的錯誤:

 

fatal error C1041: cannot open program database 'xxx.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS

這個問題除了去改專案設定還有沒有其他解法呢?恩,還不知道。


上面就是目前碰到的問題了。

而目前想到可能還可以玩的方法:

  • 不要使用 Build Tools for Visual Studio 2017、而改用 2019 版,然後安裝 2017 的 toolset,看看能不能用新版的 base-image。

  • GitLab 的部分,繼續使用 shell 當作 executor、手動去執行 docker 的指令。
    元件參考

之後…總之就再看看吧。

Leave a Reply

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