GitLab CI/CD課程10
如前篇介紹,GitLab Runner是已安裝所需程式的Server
- 使用於Pipeline中各個Jobs
- 但是GitLab提供的Runner並不一定是我們所需要執行Job的機台
比如說有以下的Pipeline流程,會分別對應底下的工具要先安裝好:
Shell Executor:
而上述這些指令工具的執行是依賴於OS(作業系統,windows,mac,linux等)
並且所有的Server上的Shell都是GitLab Runner上面安裝好的
這些Server會自己匹配(fetches job)
而實際上要安裝的指令工具可能有(npm,ssh,docker,甚至java,maven…)
所以理論上需要手動先將這些工具指令進行安裝才能使用
甚至複雜些,後續還有針對這些Server上的工具設定&升級的工作
然後Runner可能需求不只一台,第二台又要重新安裝這些工具
這些重複工作令人頭痛
甚至還有這種需求狀況:
所以還有安裝版本的管理問題!
到最後Execute多數的Job在同一個Runner的Server慢慢地堆積檔案物件
機台變得越來越複雜,甚至需要手動清理
Executors的選擇,來當作Runner Server:
- 當註冊了一個Runner,將可以自行選擇所需要的executor
1.Docker Executor:
- i.e.Runner工作運行於Docker container之內
- Jobs運行在User提供的Docker images
- i.e.每個Jobs都運行於分別且獨立的Container之內
- 而那些所需要的工具就得要事前打包進Docker image內
- 好處在於可以依據所需要的工具版本選用不同Container,不會有衝突
2.Virtual Machine Executor:
- 考量到若公司內沒有人了解Docker等容器技術,那麼虛擬機會是個選項
- 依樣可以獨立環境
- 但是會花更多的時間在OS開關機等
3.Kubernetes Executor:
- 允許使用既存的K8S Cluster來提供極高的擴展性
- 過程中會起Pod來執行Jobs
4.Docker Machine Executor:
- 特殊版本的Docker executor
- 支援自動擴展(auto-scaling)
- 依據Docker官方文件在機台上或雲端動態建立Docker host
- 一樣是透過建立機台,安裝Docker,設置Docker client來與機台溝通
- 透過這個機制的話,會多一層Docker管理的層級
- Docker Machine Executor運作起來會像是Docker executor
- 並且這抑是GitLab的Shared Runner使用的Executor方案
- 但是這邊要特別注意的是 →Docker Machine已經被Docker棄用!
- 之後GitLab應該會移除這項方案
另外還有兩種型態的executor,但是通常不太會考慮用這樣的方案
5.Shell Executor:
- 允許GitLab連線到外部Server去跑Runner的Jobs
6.Parallels Executor:
- 平行的跑一台甚至多台的虛擬機executor,其他還有像VirtualBox
該選哪一個Executor!?
- 有各種情況可以挑選所需要的來使用
- 相對比較能應付多種狀況的選項 →Docker executor(on Linux Runner)
- 但是當然還有其他特殊CASE例如要跑PowerShell在windows server
- 就要另外考慮!
- 甚至有可能規劃上有要求所有一切建置都要在K8S Cluster上面的狀況
Configuration Executor for Runner
- 當註冊一個Runner,就必須要挑選一種executor來使用
- 只允許"1 executor per runner"
- 但是也有可能有需求是需要在一個host內多種executor的調用
- 可能有不同Job需要Shell executor,另一個需要Docker executor
- 所以會需要多個Runner在同一個host內運作
- 比如說一個機台內有10個Runner可以調用!
- 各個Runner分別對應各種所需要的executor
