GitLab CI/CD 基礎建設：Runners 安裝及設定完整

– 12 分鐘閱讀

在現代軟體開發流程中，持續整合與持續交付（CI/CD）扮演著至關重要的角色。GitLab CI/CD 透過 Runners 這個核心元件，將程式碼的建置、測試和佈署自動化。本文將探討 GitLab Runners 的安裝、設定及最佳實務，協助開發者開發穩固且高效的 CI/CD 流程。GitLab Runners 負責執行 .gitlab-ci.yml 檔案中定義的任務，根據執行器（Executor）的不同，可以在各種環境中執行，例如 Docker 容器、虛擬機器或 Kubernetes 叢集。選擇合適的執行器取決於專案的複雜度和需求。Docker 執行器提供輕量級且可移植的環境，適合大多數 Web 應用程式；Shell 執行器則直接在主機上執行指令，適用於簡單的任務或需要存取主機資源的場景；而 Kubernetes 執行器則能充分利用 Kubernetes 的彈性與擴充性，滿足大型專案的需求。除了執行器之外，Runner 的標籤（Tags）機制也相當重要，透過標籤可以將特定 Runner 與特定任務比對，確保任務在正確的環境中執行。例如，可以根據作業系統、架構或佈署環境設定標籤，精準控制任務的執行環境。

安裝及設定 GitLab Runners

GitLab Runners 是 GitLab CI/CD 管道的核心，它們負責執行您在 .gitlab-ci.yml 檔案中定義的各種工作。以下是如何安裝和設定 GitLab Runners 的詳細。

自管理 GitLab 的分享 Runners

在自管理的 GitLab 例項中，管理員可以組態分享 Runners。這些分享 Runners 是專門為多個專案提供服務的，而非特定專案或群組所使用。然而，GitLab.com 的客戶可以選擇使用 GitLab 提供的 SaaS Runners，或者註冊自己的群組或特定 Runners。

每個 GitLab 授權層級都包含一定數量的 SaaS Runners 的管道分鐘數，並且可以購買額外的分鐘數。使用自己註冊的群組或特定 Runners 是不會產生額外費用的。

容器化平台與分享 Runners

容器化平台如 Kubernetes 通常被用作分享 Runners 的執行器，因為它們能夠提供短暫且可快速擴充套件的資源。與群組 Runners 不同，分享 Runners 使用公平使用佇列來挑選工作。這意味著擁有最少 CI/CD 工作的專案會優先獲得分享 Runners 的資源，從而避免單一大型管道佔用整個分享 Runner 基礎設施。

Runner 的組成部分

以下是一些 GitLab CI/CD 中涉及到的關鍵組成部分：

  • GitLab 應用程式：負責排程和協調 CI/CD 管道。
  • GitLab Runner：安裝在電腦上的二進位制檔案。
  • 個別 Runner：由 GitLab Runner 代理管理的執行 CI/CD 工作的過程。

Runner 執行器

每個 Runner 都有一個指定的執行器（Executor），它決定了如何執行收到的 CI/CD 工作。執行器在 Runner 初次註冊時指定。以下是目前支援的 Runner 執行器：

Docker 執行器

Docker 執行器在 Docker 容器中執行 CI/CD 工作，這些容器來自於指定的 Docker 映像。這確保了環境的一致性和可重複性。要使用 Docker 執行器，必須在安裝 GitLab Runner 的同一台電腦上安裝 Docker Engine。

# .gitlab-ci.yml
image: python:3.10
script:
  - python --version

內容解密：

  • Docker 執行器使用 Docker Engine 在 Docker 容器中執行 CI/CD 工作。每次執行工作時都會建立一個新容器，完成後刪除。
  • 映像指定位置：可以在 .gitlab-ci.yml 中全域性或區域性指定 Docker 映像，也可以讓 Runner 指定預設映像。
  • Docker Hub：預設情況下可以從 Docker Hub 提取公共映像，例如 python:3.10。

Docker 執行器易於確保 CI/CD 工作具有所需工具和環境，且每次執行都是獨立、可重現的。

Shell 執行器

Shell 執行器直接在安裝 GitLab Runner 的機器上執行工作。這意味著它使用機器本地的 shell 和檔案系統來執行命令。

# .gitlab-ci.yml
script:
  - echo "Hello, World!"

內容解密：

  • Shell 執行器將工作中的命令作為 shell 命令直接執行。
  • 工具依賴：需要在機器上安裝所需的構建、測試或佈署工具。
  • 缺點：缺乏清潔環境可能導致遺留物或依賴問題。

Shell 執行器適合初學者或簡單工具環境，但不建議用於複雜或多樣化的構建環境。

VirtualBox 執行器

VirtualBox 執行器使用虛擬機器來提供可重現且隔離的環境。當您註冊 VirtualBox 執行器時，需要指定一個虛擬機器範本。Runner 會從該範本啟動新虛擬機器來執行工作，並在完成後復原虛擬機器。

# 作業系統命令示例
gitlab-runner register --executor virtualbox --docker-image "python:3.10"

內容解密：

  • VirtualBox 執行器使用 VirtualBox 虛擬化平台來執行虛擬機器。
  • 範本使用：每次工作執行都會建立一個新虛擬機器例項並最終復原。
  • 適用場景：適用於需要完整作業系統資源但希望保持清潔環境的一致性場合。

Parallels 執行器

Parallels 執行器類別似於 VirtualBox 執行器，但使用 Parallels 虛擬化平台。主要適用於在 macOS 主機上執行 Windows 虛擬機器進行 CI/CD 工作。

# 作業系統命令示例
gitlab-runner register --executor parallels --docker-image "windows:latest"

內容解密：

  • Parallels 執行器與 VirtualBox 一樣提供虛擬化環境。
  • 跨平台支援：適合需要 Windows 虛擬機器而在 macOS 上執行 CI/CD 工作的情況。
  • 範本管理：每次工作執行都會根據範本建立新虛擬機器並復原完成後的資源。

Kubernetes 執行器

Kubernetes 執行器將工作執行在 Kubernetes 叢集中的 Pod（即一組一個或多個容器）。這需要您先設定好 Kubernetes 叢集並且 Runner 能夠透過 Kubernetes API 與叢集連線。

# .gitlab-ci.yml 組態 Kubernetes executor
image: k8s-runner:latest
script:
  - kubectl version --client

內容解密：

  • Kubernetes 執行器利用 Kubernetes 叢集中的 Pods 提供可伸縮且隔離的環境。
  • Helm Chart：官方提供 Helm Chart 用於佈署 Runner Agent。
  • GitLab Agent for Kubernetes：提供更廣泛連線和管理叢集資源。
  • GitLab Operator：進一步自動化 Kubernetes 資源管理和佈署流程。

Kubernetes 執行器適合需要高用性和可擴充套件性的複雜 CI/CD 工作場景。

其他執行器

除了上述常見執行者外，GitLab Runner 還支援以下其他執行者：

  • SSH：透過 SSH 在遠端服務上執行工作。
  • Custom（自訂）：允許開發者根據特定需求自訂執行方式。
# 自訂執行者示例命令
gitlab-runner register --executor custom --description "My Custom Executor"

內容解密：

  • SSH 功能強大且靈活，適合多樣化、分散式環境下對遠端服務進行控制和操作。
  • 自訂執行者：允許開發者針對特殊需求編寫自訂執行邏輯，提升靈活性和功能擴充套件能力。

GitLab Runner架構與支援平台

成功運作容器協調需要高度的網路、儲存及安全知識和經驗。如果你或你的團隊擁有Kubernetes專業知識，Kubernetes執行器可以是實作及擴充套件雲端原生CI/CD工作流程的強大工具。如果沒有，最好還是使用之前提到的執行器，如Docker執行器。

Docker Machine 執行器

Docker執行器為執行CI/CD作業提供單獨的Docker容器，而Docker Machine執行器則提供完整的主機（虛擬機器），這些主機裝有Docker引擎。這些主機支援啟動Docker容器。Docker Machine通常與具有自動擴充套件功能的雲端提供者一起使用，這樣你就可以根據需求快速且靈活地啟動相容容器的主機。

需要注意的是，Docker（公司）已經不再積極開發Docker Machine，轉而支援Docker Desktop。GitLab維護了Docker Machine的分支，以繼續支援Docker Machine執行器。

你可以將Docker Machine執行器視為VirtualBox/Parallels執行器和Docker執行器的結合，並附加自動擴充套件支援。Docker Machine還可以確保每個作業都有隔離資源，因為它確保容器執行在自己的專用虛擬機器上。事實上，GitLab使用Docker Machine來執行其自己的Linux SaaS runners，為使用者提供可擴充套件且在多租戶平台上適當隔離的runners。

SSH 執行器

有些情況下，你可能希望在無法安裝GitLab Runner的基礎設施上執行CI/CD作業。如果該基礎設施支援從安裝了GitLab Runner的電腦進行SSH存取，你可以使用SSH執行器在遠端主機上執行CI/CD作業。

當你使用SSH執行器註冊GitLab runner時，還會指定用於執行CI/CD作業的遠端主機和用於連線該主機的SSH身份檔案。當runner接收到CI/CD作業時，它會透過SSH將命令「管道」傳輸過來，以便在遠端主機上執行。

目前，SSH執行器僅支援Bash命令和指令碼，但如果你不想在每台想要執行CI/CD作業的機器上安裝GitLab Runner程式，這可能對你有用。

至此，我們已經描述了GitLab runners的主要組成部分：GitLab Runner代理程式、個別註冊runner程式以及runner程式可能使用的執行器來執行其工作。還有一個值得討論的runner組態元素，那就是runner標籤。

安裝與組態GitLab Runners

Runner標籤

runner標籤限制哪些runners可以選取哪些工作 runner標籤是放置在GitLab runners上的標籤，使其與包含相同標籤的工作定義相比對。標籤可以代表runner的平台或可用工具，如apache、rhel或ios。標籤也可以代表runner在CI/CD過程中的預期用途，如build、staging或prod。當你在CI/CD工作定義中也指定一個或多個標籤時，可以確保runner擁有正確的工具和環境來執行該工作。

例如，請考慮以下.gitlab-ci.yml檔案中的工作範例：

deploy-to-staging:
  stage: staging
  script: ./deploy-staging.sh
  tags:
    - windows
    - staging

windows和staging標籤包含在CI/CD工作定義中，確保deploy-to-staging工作只會分配給同時具有windows和staging標籤的runners。預設情況下，具有標籤的runners不會執行未標記的工作——也就是說，不與某個具體標籤比對runners 的工作。這種預設設定可以在runner設定中覆寫掉：允許具有標籤的runners執行沒有標籤的工作，因此不再關心這些工作被分配到哪裡。

Runner Tags ≠ Git Tags

GitLab中的「tag」一詞可能顯得有些混亂，因為該術語在幾種不同情況下使用。「tag」只是放置在runners上的標籤，使其與具有相同tag 或tags 的CI/CD 工作相比對。這些不是Git tag ，它們是描述性標籤放置在Git提交上 ，也是存在於GitLab中 。Runner tag 與 Git 版本控制中使用的tag 無關 。

到現在為止 ，我們已經涵蓋了所有關於 GitLab runners 的基本資訊 ，它們如何概念化運作 ，以及不同支援平台和執行器 。現在是時候走過 runner 安裝流程 。

安裝Runner代理程式

此節將對你最有幫助：跟隨並安裝及註冊自己的電腦上的 runner 。你會發現安裝步驟根據你係統型別稍有不同 ： Windows 、 macOS 、 Linux 具備支援包管理員 ，或一個通用 Linux 系統 。無論平台如何 ，相同步驟保持不變 ： 1. 安裝 GitLab Runner代理程式 2. 將 runner 註冊到 GitLab 。

# 在Linux系統上安裝 GitLab Runner
sudo apt-get update
sudo apt-get install gitlab-runner

# 在macOS系統上安裝 GitLab Runner
brew install gitlab-runner

# 在Windows系統上安裝 GitLab Runner
choco install gitlab-runner

安裝後註冊Runner

安裝完成後 ，你需要將 runner註冊到 GitLab 。這通常涉及從 GitLab 取得一個 token ，並使用該 token 和其他必要資訊來註冊 runner 。

gitlab-runner register

執行上述命令後 ，會要求輸入一些資訊 ，包括 GitLab 執行者 URL 、註冊 token 、描述符 、標籤等 。

注意事項：

  • 每個 GitLab runner 都需要唯一註冊 token 。這個 token 可以從 GitLab 的 CI/CD settings 中取得。
  • 根據安全考量 ，務必妥善保管這個 token ，並避免公開曝光。

以下是完整步驟說明：

  1. 前往GitLab專案中的Settings > CI / CD。
  2. 展開Runners部分。
  3. 按下Set up a specific Runner manually。
  4. 輸入命令 gitlab-runner register 來開始註冊流程。
  5. 輸入 GitLab instance URL（例如：https://gitlab.com/）。
  6. 輸入 Registration token。
  7. 描述 runner 的名稱及所屬 tag（例如：my-runner）。
  8. 選擇 executor（例如：docker、shell 或 ssh）。
  9. 按下 Enter 鍵完成註冊。

注意事項：

  • token：每個project都有一個獨特token用來註冊runner。
  • Executor：選擇適合環境和需求的 executor 。
  • Tags：根據需要設定 tag ，以便後續可以靈活排程任務。

組態Runner

完成註冊後 ，需要進一步組態 runner 。這包括設定各種選項以最佳化其表現和管理 。

以下是一些常見組態專案：

  • Concurrent Jobs：設定同時執行任務數量。
  • Environment Variables：設定環境變數以供任務使用。
  • Cache Configuration：設定快取路徑以加速構建過程。
  • Runtime Configuration：設定runtime資源限制（如CPU、Memory）。

組態範例：

[[runners]]
  name = "my-runner"
  url = "https://gitlab.com/"
  token = "YOUR_REGISTRATION_TOKEN"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]

驗證與測試

完成安裝與組態後 ，應進行驗證與測試以確保一切正常運作 。

  1. 提交一個新推播到 GitLab 專案中的分支。
  2. 檢查 CI / CD pipeline 是否正確觸發並執行。
  3. 檢查 runner 日誌以取得詳細錯誤資訊（如果有）。
小段落標題：完整測試步驟
  1. 建立簡單工作流程：在 .gitlab-ci.yml 中建立簡單工作流程。
  2. 觸發構建：推播新變更到分支並觀察構建結果。
  3. 檢查日誌：檢視 runner 日誌檔案以取得更多細節資訊。
stages:
  - build
build-job:
  stage: build
  script:
    - echo "This is a build job"

推播此更改並觀察Gitalab上的pipeline狀態：

  1. Pipeline觸發：應該自動觸發pipeline。
  2. Job狀態：檢查job狀態是否顯示成功。
  3. 日誌檢查：檢視job日誌以確認所有步驟都正常執行。

注意事項：

  • 僅僅測試簡單job是否能成功觸發與完成。
  • 單獨測試每一步驟以排除問題來源。
  • 組態額外環境變數或許可權若需則加以測試。

其他功能與最佳化

除了基本組態外 ，GitLab runners還提供多種高階功能及最佳化選項以滿足不同需求 。

  • Auto Scaling：自動調整 runners數量以應對負載變化。
  • Custom Executors：根據特定需求開發自定義 executors 。
  • Security Features：強化安全設定以防止潛在威脅。
  • Integration with Other Tools：與其他 CI / CD 工具無縫整合。
自動調整範例：
[[runners]]
name = "auto-scaling-runner"
url = "https://gitlab.com/"
token = "YOUR_REGISTRATION_TOKEN"
executor = "docker"
[autoscale]
max_concurrent_builds = 500
自訂executor範例：
[[executors]]
name = "custom-executor"
type = "custom"
command = ["your-custom-command"]

持續監控與維護

即使已經成功佈署並測試了 runner ，持續監控與維護仍然至關重要 。

持續監控：
  • Monitoring Tools：使用監控工具追蹤 runner狀態及效能 。
  • Alerts and Notifications：設定警示及通知以快速回應異常情況 。
  • Regular Updates：定期更新 runner 版本以修復漏洞及提升效能 。
小段落標題：持續維護：
  • Backup Configuration：定期備份runner組態檔案 。
  • Security Audits：定期進行安全稽核以確保系統安全 .
  • Performance Tuning：根據需求調整效能引數以提升效率 .

### 問答解答區域

1.
Q: What is the difference between Docker executor and Docker Machine executor?
A: The Docker executor provisions individual Docker containers for running CI/CD jobs, whereas the Docker Machine executor provisions entire hosts (VMs) that have Docker Engine installed, which then support the launching of Docker containers.

2.
Q: Why might you use the SSH executor?
A: You might use the SSH executor if you need to run CI/CD jobs on infrastructure where, for technical or compliance reasons, you are unable to install GitLab Runner directly on that infrastructure.

3.
Q: What are runner tags used for?
A: Runner tags are labels placed on GitLab runners that match them with job definitions that also include that tag, ensuring that the runner has the proper tooling and environment needed to run that job.

內容解密：

本文詳細介紹了Gitalab Runners架構、不同種型別Executor及其特點、Runer之間互動、以及如何根據實際情況選擇適合自己的Executor方式進行組態安裝及測試,本文還列舉出Gitalab Runners之最佳化方法與持續監控維護等技術細節,希望能對各位技術人員帶來幫助及啟發!

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。