GitLab CI/CD課程12
首先會感到好奇的部分是,至今課程所使用到的Executor是啥?
如何確認?
預設的Shared Runners:
- GitLab預設會使用其中一個的Shared Runners來執行CICD Job
- 而這些Shared Runners是由GitLab統一管理
- 並且對應使用的是"Docker Machine Executors"
- (但是如前面所述,Docker自己也棄用了,有一天可能也會被GitLab棄用)
若有相關更新,課程將會跟著調整內容來更新資訊!
如上紅框處,有GitLab Runner的id(15.3.0~beta.42.gdb7789ca)
回到前頁Pipeline,實際上:
亦即即便是同一個Pipeline,執行的Runner也會不同
可以分別進去看到不同的Runner ID
並且每個Job都會跑在全新的Container內
至於前面提到的GitLab存在的"Shared Runner",可以到以下位置查找
Settings →CI/CD →Runners:
會看到:
所有在gitLab.com內的Project都可以使用這些Shared Runners
另外可以注意到的是"Specific runners",則是針對該Project使用的Runners:
Specific runners通常用於Self-managed runners(自己建置的Runner機台)
後面將會介紹如何建置Specific runners
Override Docker image:
如前面看到的,預設使用的image起的Container環境是ruby:2.5
假若有需求想要改成其他image來使用!?
不管是供給"docker machine executor"或是"docker executor"來調用
其實可以直接在Editor,也就是Pipeline yml code裡面定義!
這樣也方便了解Pipeline執行的環境!
這邊假設需要有個npm的環境,來跑後面示範的node的code
先到docker-hub查找:
commit執行Pipeline:
隨便點個Job進去看看log:
其他的Job也是:
接著嘗試新增npm的指令後commit:
找到Job run_unit_tests這個Job執行的log:
所以當不小心註解了開頭的image宣告,則以上這段確認npm版本指令會失敗
看到:
在Best Practice情況下,建議使用指定的版本的image
如上帶18-alpine的Tag也OK
也不建議使用latest,因為也會有無法預期的狀況
另外,我們可能會希望不是每個Job都使用到相同的Container來執行
例如在測試的Job可能使用npm工具
但是後面的build image的Job不需要npm工具
則可以做以下調整:
或也可以全域部分宣告一個Default的image如普通的alpine的image
有特殊需求的再分別於Job內另外宣告
如下:
commit後看到:
另外值得一提的是
我們的Pipeline裡面各個Job都是由Runner來執行
假若Runner對應的Executor不是"Docker Executor"
也不是"Docker machine Executor"
可能只是"Shell Executor"則
當前的Pipeline:
