iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 21
2
DevOps

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

GitLab CI 之 CI trigger、API 與 ChatOps

今天我們一樣要繼續改善 CI/CD Pipeline,不過今天的內容說是改善 Pipeline 並不太正確,應該說我們要來更靈活的利用 CI Service。

GitLab API 與 CI trigger

現在是一個充滿 API 的時代,各家的 Service 多半都有提供 API 讓使用者可以用 GUI 以外的方式來使用 Service,當然 GitLab 也不例外,提供了眾多的 GitLab API 讓 User 可以更便捷的運用 GitLab。

GitLab API 可以做到的事情眾多,從 Create Project 一直到 trigger CI Job 都不成問題,想知道 API 的所有詳細,建議還是直接參閱官方文件會比較快。

這邊就舉兩個與 GitLab CI 有關的範例,介紹一下可以怎麼運用 GitLab API。

Production Deploy

還記得在我們假想情境中 production branch 的 CI/CD Pipeline 嗎?那時我們有一個 when: manualprod-deploy

prod-deploy:
  stage: prod-deploy
  only:
    - production
  script:
    - ansible-playbook prod-deploy.yml
  when: manual
  environment:
    name: production
    url: https://production.website.com

我們可以直接在 GitLab 的 Web UI 上手動點擊「按鈕」來驅動它。
https://ithelp.ithome.com.tw/upload/images/20191004/201209864hhk17h3oT.jpg

但這樣每次都要登入 GitLab,然後開啟該 Project 正確的 CI/CD Pipeline 才能找到它。(謎之音:是有多懶?明明就可以在 CI 跑完時送通知與超連結到 Mattermost,直接打開該網頁。)

不如就將它獨立一條 Pipeline 並且改成能夠以 GitLab API 透過 Command line 來驅動它吧!首先將 .gitlab-ci.yml 改成下面的模樣。

stages:
  - prod-deploy

prod-deploy:
  stage: prod-deploy
  only:
    - triggers
  script:
    - ansible-playbook prod-deploy.yml
  environment:
    name: production
    url: https://production.website.com

如此一來這項 CI Job 就可以透過 API 的方式 trigger 執行它。

接著為你的 User 產生使用 API 所需的 access_token

https://ithelp.ithome.com.tw/upload/images/20191004/20120986csfSwHv1xl.jpg
(User 如果權限足夠,可以用自己的 access token 來 trigger CI Pipeline。)

或者如果你只需要能夠 trigger 特定 pipeline 的權限,那也可以在該 Project 的 Settings > CI/CD > Pipeline triggers 建立一個 Project's triggers,一樣能以 API 的方式 trigger CI Pipeline。

https://ithelp.ithome.com.tw/upload/images/20191004/20120986fpxdzlpGjg.jpg
(針對 Project 設置 trigger token,務必要自行保管好。)

總之有了足夠權限的 token,你就可以搭配 token 使用對應的 API。因此你就能夠用 curl 在 Command line 驅動 CI Pipeline 執行 prod-deploy

https://ithelp.ithome.com.tw/upload/images/20191004/20120986CS5jn2d1W9.jpg
(由上圖可以看到,這個 CI Job 是以 trigger 的方式被啟動執行的。)

Rollbacks

第二個範例也跟 deploy 有點關係,就是當 deploy 失敗或遇到異常狀況而必須倒退回前一個版本時會執行的動作——rollbacks。既然 prod-deploy 都可以用 API 去 trigger,同理要將 production 環境 reollbacks 到前一個版本也可以設置同樣的機制交由專人控管。而這個 CI Job 在 .gitlab-ci.yml 中可能會類似下面這樣:

stages:
  - rollback

rollback:
  stage: deploy
  tags:
    - "ansible"
  only:
    - triggers
  script:
    - ansible-playbook rollback.yml -e version=$project_tag

ChatOps

前面談完了 GitLab API,接著來延伸談一下 ChatOps。這裡就不談什麼 ChatOps 的嚴謹定義,或到底要做到什麼程度、多麼厲害才能稱為 ChatOps。艦長個人認為,只要是透過呼叫即時通訊軟體或團隊溝通協作平台上的 ChatBot,由 ChatBot 代勞執行某些自動化腳本就算是一種 ChatOps。

那 ChatOps 又與 GitLab API 或其他 Service 的 API 有什麼關係呢?

在前面我們不是達成了可以用人工自己透過 Command line + curl 的方式來 trigger CI/CD Pipeline。現在我們只是要將「人工」這個介面換成「ChatBot」而已。也就是說,如果你有辦法善用各種 API 完成各式各樣的任務,現在只要改成讓 ChatBot 幫你代勞,類似下圖的流程。

https://ithelp.ithome.com.tw/upload/images/20191004/20120986g4sGrBPExj.jpg
(User 在 Mattermost 上呼叫 ChatBot 去 trigger CI Pipeline 完成 Prod-deploy。)

舉例來說,我們就可以利用 GitLab API 的 create project + ChatBot,達成在 Mattermost 上呼叫 ChatBot 即可完成開新專案的工作。

小結

今天雖然好像在介紹 GitLab API,但其實主要在談的是一些和自動化有關的概念,就如前面提過的,因為眾多服務都有提供 API,因此這個時代可以被自動化的工作越來越多了,而 CI Service 或 ChatBot 的出現,又讓我們有更多的選擇可以用來幫我們代勞執行任務。所以,各位又懶又有生產力的工程師,還不快點建立一群自己的 Bot 或 Worker,一起過著又懶又有生產力的人生吧!

最後要提一下,在 GitLab 未來功能的 feature 中,也有一項是 GitLab ChatOps。只不過還在發展當中,也許未來 GitLab 又會類似當初綁定 Mattermost 那樣,直接挑選某個開源的 ChatBot 綁定在 GitLab 的生態系中,讓 ChatOps 這件事情也變成簡簡單單就能設置完畢。

今天就分享到這裡,鐵人賽我們明天見~

參考資料


上一篇
CI/CD Pipeline 之 CI Service 掛掉時該怎麼辦?
下一篇
GitLab CI 之 Scheduling Pipelines
系列文
和艦長一起 30 天玩轉 GitLab30

尚未有邦友留言

立即登入留言