iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 28
0
DevOps

和艦長一起 30 天玩轉 GitLab系列 第 28

GitLab: Auto DevOps 之牛刀小試 6 - Customizing

前面幾天我們介紹了 Auto DevOps 的 CI/CD Pipeline 其中的每個 Stage,但就如其名這些 Stage 都是 Auto 自動產生的,萬一它自動產生的 CI/CD Pipeline 不是我們想要的模樣時,該怎麼辦才好?

對此,GitLab 也有提出客製化的空間,我們是可以根據 Auto DevOps 的 CI/CD Pipeline 進行自己想要的客製微調。

用 .gitlab-ci.yml 客製自己的 Pipeline

其實 Auto DevOps 的 CI/CD Pipeline 也是根據一個特定的 .gitlab-ci.yml 而產生的,官方有將這個 Auto-DevOps.gitlab-ci.yml 公開,檔案存放在 GitLab 官方的 Project 內。

https://ithelp.ithome.com.tw/upload/images/20191011/20120986kT6innh4Gh.jpg

如上圖,可以看見這個 .gitlab-ci.yml 使用了 include:,因此如果要查看詳細每一個 CI Job 做了哪些事情,還要更進一步開啟上圖 template: 後方的每個網址。

https://ithelp.ithome.com.tw/upload/images/20191011/20120986IHLTiLFk8z.jpg

有了這些詳細資料,我們就能夠客製化自己 CI/CD Pipeline 了。說是客製化,其實也就是回歸 GitLab CI 原本的做法,我們要在 Project 根目錄下新增 .gitlab-ci.yml,而檔案內容則是以上面的 Auto-DevOps.gitlab-ci.yml 為基礎,再做出我們想要的修改。

當 project 的根目錄有 .gitlab-ci.yml 檔案時,GitLab CI 會優先根據檔案內容來產生 CI/CD Pipeline。因此我們先來做一個簡單的實驗,複製 Auto-DevOps.gitlab-ci.yml 的內容,並建立一個 .gitlab-ci.yml 但只留下 Stage: build,看看我們的 CI/CD Pipeline 會變成什麼模樣。

image: alpine:latest

variables:
  POSTGRES_USER: user
  POSTGRES_PASSWORD: testing-password
  POSTGRES_ENABLED: "true"
  POSTGRES_DB: $CI_ENVIRONMENT_SLUG
  POSTGRES_VERSION: 9.6.2

  DOCKER_DRIVER: overlay2

  ROLLOUT_RESOURCE_TYPE: deployment

  DOCKER_TLS_CERTDIR: ""

stages:
  - build

include:
  - template: Jobs/Build.gitlab-ci.yml

結果如我們預期的,真的只剩下 Stage: Build。
https://ithelp.ithome.com.tw/upload/images/20191011/20120986th9HP7udOP.jpg

接著第二個實驗,我們要取代 build 這個 CI Job 的內容。這裡我們一樣可以利用 include:,先將我們想要的 build 執行的動作建立成一個範本,再透過 include: 引用。

include: 接受的檔案來源有很多種,包含 localremotetemplatefile,這邊我們就用 local 的方式來存放我們的範本。

首先在 Project 內新增一個 Build.gitlab-ci.yml,裡面放上一段裝傻的內容。
https://ithelp.ithome.com.tw/upload/images/20191011/20120986wP1iOrMXKR.jpg

接著要修改 .gitlab-ci.yml

image: alpine:latest

variables:
  POSTGRES_USER: user
  POSTGRES_PASSWORD: testing-password
  POSTGRES_ENABLED: "true"
  POSTGRES_DB: $CI_ENVIRONMENT_SLUG
  POSTGRES_VERSION: 9.6.2

  DOCKER_DRIVER: overlay2

  ROLLOUT_RESOURCE_TYPE: deployment

  DOCKER_TLS_CERTDIR: ""

stages:
  - build

include:
  - local: 'Build.gitlab-ci.yml'

結果,還真的成功了,build 被替換成我們改寫後的動作。

https://ithelp.ithome.com.tw/upload/images/20191011/201209861J9ijTtGg9.jpg

有了上面的基礎,基本上 CI/CD Pipeline 已經是隨便你改了,能客製到何種程度,就看個人的功力了。

小結

從今天的分享我們得知 Auto DevOps 其實一點也不神奇,說穿了它依舊是原本的 GitLab CI,仰賴於某個 .gitlab-ci.yml,只不過是 GitLab 官方作出了一個可以自動因應各種常見狀況的 template。

但我們也可以反過來思考,官方維護的這一份 Auto-DevOps.gitlab-ci.ymltemplates 其實是非常有參考價值的,如果你決定要大力擁抱 GitLab CI 作為你團隊的 CI Service,那麼它正是一份有著一定複雜度的 CI/CD Pipeline 範本,值得詳閱學習。

Auto DevOps 的內容到今天為止就算是告一個段落,鐵人賽還剩下兩天,最後我們會分享 GitLab Workflow 的最後一關 Feedback。鐵人賽,我們明天見~

參考資料


上一篇
GitLab: Auto DevOps 之牛刀小試 5 - Auto Monitoring
下一篇
GitLab Cycle Analytics & Charts
系列文
和艦長一起 30 天玩轉 GitLab30

尚未有邦友留言

立即登入留言