管理維運 GitLab Server，一定會知道 GitLab Runner 的使用，可能也遇過，GitLab 團隊成員同一時段 Commit Source Code 時，同時執行多條 Pipeline 造成Runner 所需資源不足的問題，為了解決這問題，可能又會加開主機，但到了離峰時段又顯得資源的浪費，偏偏團隊成員什麼時間會同時觸發 Pipeline，這不是非常好預測的事情。於是 GitLab Runner 的自動擴展 (Auto Scaling) 的需求就出現了。

該如何配置可以自動擴展的 GitLab Runner 呢？在 GitLab 官方文件 GitLab Runner instance group autoscaler 及 GitLab Runner Autoscaling 中，提到為了替代 GitLab Runner Docker Machine Autoscaler，建立了 Docker Autoscaler executor，所以，本文將紀錄，如何建立一個搭配 Docker Autoscaler executor 的 GitLab Runner。

什麼是 Autoscaler executor

圖片來源：https://docs.gitlab.com/runner/runner_autoscale/gitlab-runner-autoscaler/

在 GitLab CI/CD 的環境中，當 Pipeline 建立之後，GitLab Server 會依配置，將 Pipeline 上的 Job 放到佇列 (Queue) 中，讓 GitLab Runner 依據自身的能力，認領 Job 去執行，認領工作之後，持續回報工作狀況給 GitLab Server，如上圖，也就是圖中的 GitLab 與 HOST INSTANCE 之間的關係。

在 GitLab Runner，取得工作後 Runner 會依據 Runner 自身的環境配置讓 Executor 正式的執行取得的工作。在文章的開頭所提到的 GitLab Runner 會遭遇到的資源不足或資源過剩的問題也就是這個部分，要讓一個 Runner 可以同時有多個 Executor 執行工作，該 Runner 勢必需要多一些實體資源，但沒有工作可以執行時，這些資源就會閒置著，造成資源浪費。

那麼有沒有一種可能，在 Runner 與 Executor 之間，再增加一個管理介面，當需要工作時，才正式在額外的資源建立可以執行工作的 Executor ？ 這邊也就是上面的圖中的 Runner Manager 以及圖右邊的 Autoscaling Runners。組成 GitLab Runner instance group autoscaler，具體來說，這樣的 GitLab Runner 又有哪些細節？

GitLab Runner instance group autoscaler 是基於 Docker Machine 的自動擴展技術，主要有這些元件：

• Taskscaler：主要負責自動擴展的邏輯、紀錄和管理由 Cloud Provider 提供服務用來執行 GitLab Job 的 Instance 群組。
• Fleeting：Fleeting 可以說是提供自動擴展的 Runner 最重要的關鍵。Fleeting 是一個介面，是 Taskscaler 與各家服務提供者 Plugin 間的橋樑，透過這個橋樑，Taskscaler 可以在各家服務上執行工作，在需要的時候開啟主機、不需要的時候關閉。
• Cloud Provider plugin：實作與各家服務提供者的 API 介接，用來正式實作 Runner 在各家服務提供平台上執行工作。

總結來說，以往 Runner 在接下工作後，只能在自身實體主機上執行工作，因此會被本地主機資源限制，搭配 Taskscaler、Fleeting及 Cloud Provider plugin 之後，Runner 在接下工作之後，可以透過 Taskscaler 將工作分配到預期的雲服務提供平台上，透過自動開關雲平臺上的主機來完成這些工作，就可以達到 Runner 本地只要負擔足夠管理 Runner 及 Taskscaler 的資源，其他的運算資源，由 Cloud Provider 來提供的結構。

具體如何使用 fleeting 及 Cloud Provider ？

首先來到 Fleeting的頁面中，目前 GitLab 官方提供三種 Cloud Provider，分別是 Google Cloud 主要使用 Google Cloud instance groups，AWS 使用 AWS Auto Scaling groups，以及 Azure 使用 Virtual Machine Scale Sets(目前僅支援 Uniform orchestration 模式 )，其他社群支援的 Cloud Provider 還有 VMware vSphere，對應內容在 registry.gitlab.com/santhanuv/fleeting-plugin-vmware-vsphere:latest。

接下來，再確認要使用什麼樣的 Cloud Provider 之後，就可以透過 GitLab Runner 的設定檔 config.toml 中的 [runners.autoscaler] 區段進行配置(這邊以 GCP 為例)：

[[runners]]
  name = "my runner"
  url = "https://gitlab.com"
  token = "<token>"
  shell = "sh"

executor = "instance"

[runners.autoscaler]
  plugin = "googlecloud:latest"

而後，透過 GitLab runner 指令正式進行安裝：

gitlab-runner fleeting install

即可完成主要的安裝。

總結

接下來，會在下一篇進入正式實作的內容，主要會提及 GitLab Runner 端的設定、Google Cloud 上的設定及相關 Service Account 的建立等細節資訊。

GitLab Runner 的這個 Autoscaling 的機制是個很值得學習，不過因為現行 GitLab 關於設定的細節文件還很散亂，所以對於這個機制，剛開始不是太容易入門，但真的設定完成後，這樣的機制效益是非常讓人讚賞的。

以我個人目前的實務經驗，Runner 不用太高規格(二核心、1G記憶體)，同時執行數十個工作，而 Cloud 上的機器就可以設定相對高規格的主機，執行完 Job 就直接移除，這徹底的解決沒人使用的時候效能過剩，大量使用的時候效能不足的問題。我是墨嗓（陳佑竹），期待這次的內容能帶給你實用的啟發與幫助。

參考連結

• Docker Autoscaler executor | GitLab Docs
• Fleeting | GitLab Docs
• Docker Machine Executor autoscale configuration | GitLab Docs
• GitLab Runner instance group autoscaler | GitLab Docs