iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 2
0
DevOps

用 GitLab CI 玩轉自動化測試與佈署系列 第 2

Day02 - GitLab CI 是怎麼運作的?談 GitLab 的基本結構

在正式開始談 GitLab CI 前,首先必須要先知道 GitLab 與 GitLab CI 及 GitLab runner 之間的關係。GitLab 提供團隊建立從原始碼更新到 GIT Repo 之後的工作流程 (Workflow)以及在工作流程中建立工作流水線(Pipeline),其中包含一道一道的關卡(Stage)與每個關卡中的工作(Job)。如官方所提供的架構圖

cicd_pipeline_infograph

一般團隊的在完成原始碼的修訂,正式發布 push 到 GitLab 上之後,可能還需要作一些原始碼的測試及原始碼的部署,就如圖中所定義的流水線包含兩大部分,分別是 CI (Continuous Integration, 持續整合) PIPELINE,在這部分,對於 GitLab CI 來說,我們可以想像他就是一個包含 Build、Unit Test、Integration Tests 等工作的「關卡, Stage」;而 CD(Continuous Delivery, 持續部署)PIPELINE 的這個關卡,則有 Review、Staging、Production 三個工作。

而圖片中提到的這些關卡及工作,在 GitLab 這個系統中,都可以透過 .gitlab-ci.yml 來定義,把流水線中需要的關卡、工作等先後順序、要做哪些事情等,都定義在其中。透過原始碼的修訂,正式發布到 Git Repo 之後,在 GitLab 看到有 .gitlab-ci.yml 後,依照 .gitlab-ci.yml 定義的工作流程流水線建立起對應的工作。那麼,這些工作誰作呢?

GitLab Server 與 GitLab CI Runner 的關係

.gitlab-ci.yml 檔案定義了流水線(Pipeline)、關卡(Stage)與工作(Job),並透過 GitLab Server 依據流水線的定義,建立起工作,但這些工作由誰來作呢?在 GitLab CI 的生態系裡,所謂的「GitLab Runner」就是這些負責把工作作掉的夥伴。

GitLab Server 與 Runner Server

如 GitLab 上圖 官方所提供的 Runner Server 與 GitLab Server 的關係圖可以看出,GitLab Server 可以對應到多個不一樣的 Runner Server,Runner Server 上可以執行多個 Runner;而可以執行 Runner Service 的平台則是相當的多元 ,如 Linux、Docker、macOS、Kubernetes(K8S)甚至是 Windows 等等。

只是必須要注意,執行 Runner 的環境,必須可以讓 Runner 透過 GitLab API 網路連線到 GitLab Server 上,因為,當 GitLab Server 建立幾工作等待 Runner 來執行時,是 GitLab Runner 們,在手上沒工作作的時候,去詢問 GitLab Server 有沒有「符合」它可以作的事情,符合之後,才取下來作,並且,工作期間及工作完成無論成功或失敗,都主動的回報工作狀況給 GitLab Server。

接下來在明天,我們將談談 .gitlab-ci.yml 怎麼去定義這些關卡、工作。我是墨嗓(陳佑竹),期待這系列的文章能夠讓人有些幫助。


上一篇
Day01 - GitLab CI 玩轉自動化測試與部署 緣起
下一篇
Day03 - GitLab CI 的設定檔有哪些結構?談最基本的 .gitlab-ci.yml
系列文
用 GitLab CI 玩轉自動化測試與佈署31

尚未有邦友留言

立即登入留言