GitLab CI 之 CI trigger、API 與 ChatOps

本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw,鐵人賽撰文時 GitLab 仍為 12.x 版本,因此本系列文內容已有部分過期,本次搬移至此後,會視狀況新增一些補註說明。

本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw,鐵人賽撰文時 GitLab 仍為 12.x 版本,因此本系列文內容已有部分過期,本次搬移至此後,會視狀況新增一些補註說明。 鐵人賽原文網址:https://ithelp.ithome.com.tw/articles/10224332

今天我們一樣要繼續改善 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 上手動點擊「按鈕」來驅動它。

但這樣每次都要登入 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


(User 如果權限足夠,可以用自己的 access token 來 trigger CI Pipeline。)

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


(針對 Project 設置 trigger token,務必要自行保管好。)

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


(由上圖可以看到,這個 CI Job 是以 trigger 的方式被啟動執行的。)

Rollbacks

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

stages:
  - rollback

rollback:
  stage: rollback
  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 幫你代勞,類似下圖的流程。


(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 這件事情也變成簡簡單單就能設置完畢。

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

參考資料