架設 GitLab CI Runner
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10217957）
專案啟動了、Issue 開立了、工作分配了，我們假想情境中的主角 Dev Leader 接著要為團隊搭建 CI/CD 環境，按先前針對 Workflow 的規劃，這次專案的 Git 分支策略將依循 GitLab Flow，即是以 GitHub Flow 為主，但配合部署至 Production 環境再額外增加一條 Production branch。按這樣的流程，目前規劃短期內團隊的 CI/CD Pipeline 將會是下圖的模樣。
（不同 branch 的 CI/CD Pipeline 不同。）
【新增補充】根據現在的世界潮流，會建議將 master branch 改名為 main branch。
即是 develop branch 會自動部署至 dev 環境，並且執行自動化測試；而 master branch 則自動部署至 stg 環境，也同樣會執行自動化測試；最後真正交付的產品，則是依據 production branch，同時會先部署至 pre-production 環境，再一次的執行自動化測試，如沒有問題，才部署至 production 環境。
GitLab CI Runner
初期的 Pipeline 規劃完畢，接著要來實現它，首先要準備 GitLab CI 所需的 CI Runner。
GitLab CI Runner 即是為你代勞執行 CI Job 的 Worker，如果有架設多個 CI Runner 那麼在同一時間即可處理多項 CI Job，反之如果有大量的 CI Job 需要執行，但 Runner 數量有限，那麼 CI Job 就會出現 Pending 的狀態，必須等待 Runner 完成其他工作之後，才會輪到該 CI Job 被執行。
GitLab Runner 基本的運作模式就如下圖，每個 Runner 會定期向 GitLab 發出 request 詢問有沒有需要執行的 CI Job，如果有 Job 要做且 Job 的 tag 與 Runner 吻合，則 Runner 就會將 Job 認領回去執行。
安裝 GitLab CI Runner
GitLab 官方同樣為 Runner 提供了多種安裝方式，在官網上皆有詳盡的文件可以參考。在評估了各種架設方式之後，Dev Leader 認為雖然以 Container 的方式架設 Runner 目前十分流行且方便，但現階段專案、團隊及各種環境皆剛起步的狀態，且成員們對於 Container 的掌握度仍有待加強。因此決定先採用熟悉的老方法，即是建立一台乾淨的 Server 並透過 deb repository 來安裝 Runner。未來當團隊 Container 相關的技能都逐一跟上之後，會再次全面評估轉換為 Container 的解決方案。
透過下面的 Command 即可在 Ubuntu 以 apt-get 的方式安裝 Runner。
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
sudo apt-get install gitlab-runner
GitLab Runner 安裝之後，還需要向 GitLab Server 完成註冊，才算是真正的架設完畢。註冊的方式即是執行下面的 Command。
sudo gitlab-runner register
Command 執行之後，還需要輸入各項註冊資訊。因為 GitLab Runner 可以註冊為 Project 專用的 Runner （但亦可以手動分享給其他 Project 使用），或註冊成 Group Runner 直接供 Group 之下所有 Project 共用。
只要開啟 Group 的 Settings，在 CI/CD 的頁面中即可取得註冊所需的 registration token，順利完成 Runner 的註冊。
（如上圖，在 Settings 中可以找到 registration token。）
在註冊過程除了需要輸入 registration token，還有其他重要的選項，特別是 executor。配合目前專案初期 dev 與 stg 環境將仍以獨立的 Server 架設，而且 Runner 也同樣架設在單獨的 Server 上，因此這邊先選擇以 shell 作為 executor。
（註冊過程會透過問答幫助你輸入所需的參數。）
不同的 executor 會影響 Runner 與 Server 或環境的互動方式，也會影響你架設 Runner 的 Server 本身需要做好哪些事前準備。例如如果你選擇了 docker 作為 executor，那安裝 Runner 的 Server 就要先安裝好 Docker 才行，這樣 Runner 才能用 Container 為 CI Job 建立執行 Job 時的運行環境。
註冊完畢後，Runner 的 config 會存放在 /etc/gitlab-runner/config.toml。
（GitLab Runner 還有很多可以設定的參數，這裡暫時先不一一詳細說明，想要搶先了解的朋友，可以參考官方文件。）
【新增補充】其實 Runner register 還可以有更自動化的做法，你可以事先準備好 config 或在執行
gitlab-runner register時加上其他的參數。
小結
今天我們搞定了 GitLab Runner 的架設工作，順利在一台 Server 上安裝了 GitLab Runner，而我們的主角 Dev Leader 頓時自己感覺良好的覺得這下子 CI/CD 的事前準備應該就告一個段落，下一步就能實際驗證目前規劃好的 CI Pipeline 了吧？
但殊不知，就在他一邊喝杯咖啡，一邊幻想著順暢又自動的 Pipeline 時，想著想著就發現自己還是太天真了，CI/CD Pipeline 還有很多環節與細節等著他去處理，他越想就越覺得這案情並不單純⋯⋯