GitLab Runner 安裝設定與執行器詳解

– 10 分鐘閱讀

在現代軟體開發流程中，持續整合與持續交付（CI/CD）至關重要。GitLab Runner 作為 GitLab CI/CD 的核心元件，負責執行管線中的各項任務。本文將詳細介紹 GitLab Runner 的安裝、設定步驟，並探討不同執行器的特性與應用場景。首先，分享 Runner 適用於自行管理的 GitLab 例項，透過公平使用的佇列機制，讓資源分配更加均衡。GitLab CI/CD 系統主要由 GitLab 應用程式、GitLab Runner 和個別 Runner 組成，其中執行器扮演著接收工作負載並傳回結果的關鍵角色。Docker 執行器是常見的選擇，它利用 Docker 容器提供可重複的執行環境，確保 CI/CD 工作所需的工具一致性。Shell 執行器則直接在 Runner 所在機器上執行 Shell 命令，適用於簡單的任務或需要直接存取系統資源的場景。VirtualBox 和 Parallels 執行器則分別利用 VirtualBox 和 Parallels 虛擬化平台，提供完整的作業系統環境，適用於需要特定作業系統資源的任務。Kubernetes 執行器則將 CI/CD 工作佈署到 Kubernetes 叢集中，適合需要高度擴充套件性和彈性的場景。選擇合適的執行器取決於專案的具體需求，例如環境隔離程度、資源需求、擴充套件性等因素。

安裝及設定 GitLab Runners

GitLab Runner 是 GitLab CI/CD 基礎設施的核心組成部分，負責執行與管理 CI/CD 管線中的各項工作。本文將探討 GitLab Runner 的安裝、設定及其各型別執行器的使用方法。

分享 Runner 限制

首先，需要注意的是，分享 Runner 只適用於自行管理的 GitLab 例項。如果您是 GitLab.com 的客戶，則可以選擇使用 GitLab 提供的 SaaS Runner，或註冊自己的群組或特定 Runner。每個 GitLab 授權層級都包含一定數量的 SaaS Runner 管線分鐘，並且可以購買更多分鐘。使用自己的群組或特定 Runner 是不收費的。

容器化平台如 Kubernetes 通常被用作分享 Runner 的執行器，這些平台能夠提供短暫且可快速擴充套件的資源。與群組 Runner 不同，分享 Runner 操作的是一個公平使用的佇列。擁有最少 CI/CD 工作的專案將優先獲得分享 Runner 資源，從而確保單一大型管線不會佔用整個分享 Runner 基礎設施。

執行器簡介

GitLab 的 CI/CD 系統由幾個主要元件組成：

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

在這些元件中，執行器（Executor）是關鍵的一環。執行器接收工作負載並傳回工作輸出和狀態。它指的是 Runner 在接收到 CI/CD 工作時所使用的環境。以下是 GitLab 支援的執行器：

Docker 執行器

Docker 執行器將 CI/CD 工作執行在 Docker 容器中，這些容器是從指定的 Docker 映像啟動的。這提供了一個可重複的環境，內含執行 CI/CD 工作所需的工具。

安裝需求

使用 Docker 執行器需要在相同電腦上安裝 Docker Engine。

優點

Docker 是 GitLab 使用者中最常見的執行器之一，也是 GitLab.com 上分享 SaaS Runner 的預設環境。Docker 執行器確保 CI/CD 工作具有成功執行所需的工具，這些工具是在容器映像中提供的。

映像組態

映像可以在 .gitlab-ci.yml 中指定：

  1. 在單個工作定義中
  2. 全域組態，適用於所有工作
  3. 作為預設映像，如果 .gitlab-ci.yml 沒有指定映像時使用

映像可以來自本地或外部容器登入檔，如 Docker Hub。例如，如果您的 CI/CD 工作需要 Python 工具鏈，您可以指示 Runner 從 Docker Hub 拿取 python:3.10 映像，並從該映像啟動一個容器來執行工作。完成後，Runner 會刪除容器，直到接收到新工作為止。

Shell 執行器

Shell 執行器直接在安裝 GitLab Runner 的機器上執行 Shell 會話中的工作。這與使用者在終端機中輸入命令相似。

優點與挑戰

Shell 執行器簡單易上手，因為它使用本地 Shell 和檔案系統。然而，它也存在一些挑戰：

  1. 需要在伺服器上預先安裝必要的建置、測試或佈署工具。
  2. 沒有清理環境來進行工作執行，可能會留下建置和測試藝品。

因此，雖然 Shell 執行器適合初學者快速上手第一次管線設定，但在複雜建置環境下建議使用其他執行器。

VirtualBox 執行器

VirtualBox 執行器為需要完整作業系統資源的 CI/CD 工作提供可重複環境。此執行器僅能在安裝了 VirtualBox 虛擬化平台的電腦上使用。

工作流程

當 Register 一個使用 VirtualBox 執行器的 Runner 時，您需要指定一個 VM 範本用於執行 CI/CD 工作。當執行工作時，Runner 會從基礎範本啟動一個新 VM ，並在該 VM 上執行 Shell 會話來執行工作，並將結果報告回 GitLab ，然後銷燬該 VM。

建議

除非工作需要存取在 Type-2 虛擬機器上執行的作業系統資源，否則考慮使用 Docker 或 Kubernetes 執行器來實作標準化而無需虛擬機器開銷。

Parallels 執行器

Parallels 執行器與 VirtualBox 執行器組態和運作方式相同，但使用 Parallels 虛擬化平台而不是 VirtualBox。這使得可以在 macOS 主機機上執行 Windows VM 中的 CI/CD 工作。

Kubernetes 執行器

Kubernetes 執行器將 CI/CD 工作執行在 Kubernetes 叢集中的 Pod（一個或多個容器群組）中。這自然需要有一個已設定好的 Kubernetes 叢集供 Runner 透過 Kubernetes API 與之連線。

組態方式

目前有幾種方式可以連線到 Kubernetes 叢集：

  1. Helm Chart：GitLab 提供了官方 Helm Chart 用於將 Runner agent 佈署到叢集中。
  2. GitLab Agent for Kubernetes：更廣泛地將 Kubernetes 叢集連線到 GitLab例項。
  3. GitLab Operator：正在開發中的工具用於自動化 Kubernetes 叢集中 GitLab 資源佈署。
建議

雖然 Operator 暫未推薦生產環境使用，但可以用來管理開發和測試環境中的資源。

其他資源及深入瞭解

深入瞭解各型別執行器後，您可以根據實際需求選擇合適的執行方法進行 CI/CD 組態。以下圖示展示了各型別執行環境如何進行組態：

  graph TD
    A[GitLab Application] --> B[Runner Registration]
    B --> C[Docker Executor]
    B --> D[Shell Executor]
    B --> E[VirtualBox Executor]
    B --> F[Parallels Executor]
    B --> G[Kubernetes Executor]

    C --> H[Docker Engine]
    D --> I[Local Shell]
    E --> J[VirtualBox Hypervisor]
    F --> K[Parallels Platform]
    G --> L[Kubernetes Cluster]

    H --> M[Containerized Jobs]
    I --> N[Direct Shell Jobs]
    J --> O[VM-Based Jobs]
    K --> P[Cross-Platform VM Jobs]
    L --> Q[Containerized Pod Jobs]

內容解密：

此圖示展示了不同執行環境如何與 GitLab 應用程式進行互動：

  1. GitLab Application：負責排程與協調所有 CI/CD管線。
  2. Runner Registration：不同型別的Runner (Docker, Shell, VirtualBox, Parallels, Kubernetes)被註冊到Gitlab。
  3. Docker Executor：依賴Docker Engine來培養容器化任務。
  4. Shell Executor：直接利用本地Shell來培養任務。
  5. VirtualBox Executor：利用VirtualBox虛擬機器來培養任務。
  6. Parallels Executor：利用Parallels虛擬機器來培養跨平台任務。
  7. Kubernetes Executor：利用Kubernetes叢集來培養容易Pod任務。

GitLab Runner：架構、平台與安裝

GitLab Runner 是一個開源的工具，用於在 GitLab 中執行持續整合（CI）和持續交付（CD）管道。它支援多種架構和平台，能夠靈活地適應不同的需求。以下是關於 GitLab Runner 的詳細內容，包括其架構、支援的平台以及安裝和組態。

主要組成部分

GitLab Runner 的架構主要包括以下幾個部分：

  • GitLab Runner 代理（Agent）：這是一個守護程式，負責從 GitLab 伺服器接收 CI/CD 工作並執行。
  • 註冊的 Runner 程式：每個 Runner 程式可以使用不同的 Executor 來執行工作。
  • Executor：每個 Runner 程式可以選擇不同的 Executor 來執行工作，例如 Docker Executor、Shell Executor、Kubernetes Executor 等。

支援的平台與 Executor

Docker Executor

Docker Executor 是最常用的一種 Executor，它會為每個 CI/CD 工作啟動一個獨立的 Docker 容器。這種方式可以確保每個工作都在隔離的環境中執行，避免相互影響。

Kubernetes Executor

Kubernetes Executor 需要對 Kubernetes 有深入的瞭解，它能夠在 Kubernetes 叢集中啟動 Pod 來執行 CI/CD 工作。這種方式適合需要高度擴充套件性和靈活性的場景。

Docker Machine Executor

Docker Machine Executor 不僅會為每個工作啟動 Docker 容器，還會為每個工作啟動一個獨立的主機（VM）。這種方式適合需要高度隔離和自動擴充套件的場景。需要注意的是，Docker Machine 已經不再積極開發，GitLab 維護了一個分支來繼續支援。

SSH Executor

SSH Executor 適用於無法直接安裝 GitLab Runner 的環境，但支援 SSH 存取的情況。當 GitLab Runner 接收到 CI/CD 工作時，會透過 SSH 構建管道命令至遠端主機執行。

安裝與組態 GitLab Runner

安裝 Runner Agent

根據你的作業系統（Windows、macOS、Linux 或通用 Linux），安裝步驟會有所不同。以下是通用步驟：

  1. 下載並安裝：從 GitLab 的官方網站下載對應作業系統的 GitLab Runner 安裝包並進行安裝。
  2. 註冊 Runner：使用 gitlab-runner register 命令將新安裝的 Runner 與 GitLab 伺服器進行註冊。
sudo gitlab-runner register

組態與標籤

Runner 標籤

Runner 標籤用於比對特定的 CI/CD 工作。例如，你可以為某些 Runner 新增 windows 和 staging 標籤，以確保特定工作只在具備這些標籤的 Runner 上執行。

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

這樣組態後，deploy-to-staging 工作只會在同時具有 windows 和 staging 標籤的 Runner 上執行。

安裝及設定 GitLab Runner

在 GitLab 中，GitLab Runner 是一個必須的元件，用於執行持續整合（CI）和持續佈署（CD）工作。安裝方式會因作業系統而異，以下將詳細說明在不同作業系統上的安裝和設定流程。

安裝 GitLab Runner

在主要的 Linux 發行版中，GitLab 提供了詳細的安裝。你可以透過新增 GitLab Runner 儲存函式庫並使用原生的軟體包管理器來完成安裝。以下以 Red Hat Enterprise Linux（RHEL）為例進行說明。

在 RHEL 上安裝 GitLab Runner

首先，下載並執行一個 shell 指令碼，該指令碼會將 GitLab Runner 儲存函式庫新增到系統的軟體包管理器中：

sudo curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash

這個指令碼會檢測作業系統平台，然後執行相應的軟體包管理命令來新增 GitLab Runner 儲存函式庫。你可以透過檢查可用的儲存函式庫列表來驗證這一步驟是否完成：

sudo dnf repolist

在列表中應該能看到 gitlab-runner 儲存函式庫。

接下來，安裝 GitLab Runner 包：

sudo dnf install -y gitlab-runner

安裝完成後，GitLab Runner 會自動在後台啟動。你可以透過以下命令來驗證 GitLab Runner 是否正在執行：

sudo gitlab-runner status

你應該會看到 GitLab Runner 已啟動且尚未註冊任何 runner 的確認資訊。

在 Windows 和 macOS 上安裝 GitLab Runner

在 Windows 和 macOS 上，你可以使用 curl 從 GitLab 下載程式，使其可執行，然後進行安裝和啟動。以下是一般步驟：

  1. 使用 curl 下載 GitLab Runner 二進位制檔案。
  2. 使二進位制檔案可執行。
  3. 安裝並啟動 GitLab Runner。

註冊 Runner 到 GitLab

安裝完 GitLab Runner 後，接下來需要將其註冊到 GitLab 中。註冊流程如下：

取得註冊 Token

首先，從你希望註冊 runner 的專案或群組中取得註冊 Token。例如，在 Hats for Cats 專案中，你可以在「Settings | CI/CD | Runners」下找到這些詳細資訊和註冊 Token。

執行註冊指令

傳回到安裝了 GitLab Runner 的電腦上，開啟終端並執行以下命令來開始註冊流程：

sudo gitlab-runner register

GitLab 會提示你輸入一些資訊來完成註冊：

  1. GitLab 應使用案例項 URL：對於 SaaS 使用者，這通常是 https://gitlab.com。如果是自管理例項，則是你用來存取例項的 URL。

    Enter the GitLab instance URL (for example, https://gitlab.com):
https://gitlab.com

  2. 註冊 Token：這是你從專案或群組中的「Settings | CI/CD | Runners」頁面取得的 Token。

    Enter the registration token:
GR1348941Xi_koNdj8AjJMjSzQyYY

  3. Runner 描述：這是可選的描述資訊，會顯示在 runner 的後設資料中。

    Enter a description for the runner:
[localhost] Linux dev server

  4. Runner 標籤：這些標籤用於標記 runner 的能力。例如，dev 和 rhel 標籤表示這個 runner 能夠處理開發環境中的 Red Hat Linux 工作。

    Enter tags for the runner (comma-separated):
dev,rhel

  5. 維護備註：這是可選的描述資訊，不會影響 runner 的行為。

    Enter optional maintenance note for the runner:
<leave blank in this example>

  6. 確認註冊：最後一步是確認 runner 是否能夠與 GitLab 通訊並進行身份驗證。

    Registering runner...
succeeded runner=GR1348941Xi_koNdj

  7. 選擇 Executor：最後一步是選擇用於執行 CI/CD 工作的執行環境。例如，Shell 是最簡單且無依賴的選擇。

    Enter an executor: parallels, docker-ssh+machine, kubernetes, custom, docker, docker-ssh, docker+machine,
shell (default)

內容解密：

sudo curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash
  • 語法分析：這條指令使用 curl 下載一個 shell 指令碼並直接執行它。該指令碼會自動檢測作業系統平台並新增相應的軟體包管理倉函式庫。
  • 設計考量：這樣做的好處是在不同Linux版本上都能自動適配並簡化安裝流程。
  • 技術原理：curl 是一個命令列工具，用於傳輸資料。-L 引數表示如果遇到重定向則跟隨重定向。
  • 潛在改進點：如果遇到網路問題或需要更多安全檢查時，可以考慮手動下載並檢查指令碼內容後再執行。
sudo dnf install -y gitlab-runner
  • 語法分析：這條指令使用 dnf 包管理器來安裝 gitlab-runner 包。
  • 設計考量：使用 -y 引數表示自動同意所有提示問題。
  • 技術原理：dnf 是 Red Hat Enterprise Linux 中用於軟體包管理的工具。
  • 潛在改進點：在生產環境中可以考慮手動確認每個包的來源和版本以避免潛在風險。
Enter the registration token:
GR1348941Xi_koNdj8AjJMjSzQyYY
  • 語法分析：這段文字是使用者輸入的一部分，需要提供正確的註冊 Token 才能完成 runner 的註冊。
  • 設計考量：Token 是唯一且不可預測的字串，確保每個 runner 的唯一性。
  • 技術原理：Token 用於身份驗證和許可權控制。
  • 潛在改進點：可以考慮使用環境變數來儲存 Token 以提高安全性和便利性。
Enter tags for the runner (comma-separated):
dev,rhel
  • 語法分析：這段文字是使用者輸入的一部分，需要提供與該 runner 能力相關的標籤。
  • 設計考量：標籤用於標記 runner 的能力和特性。
  • 技術原理：標籤機制使得 CI/CD 工作能夠根據標籤選擇合適的 runner 執行。
  • 潛在改進點：可以考慮自動化標籤管理以減少人為錯誤。
Enter an executor: shell (default)
  • 語法分析：這段文字是使用者輸入的一部分，需要選擇一個執行環境來執行 CI/CD 工作。
  • 設計考量：不同的 Executor 有不同的依賴和組態需求。
  • 技術原理：Executor 是執行 CI/CD 工作的環境。
  • 潛在改進點：可以考慮提供預設值或智慧推薦以減少使用者輸入錯誤。
玄貓

玄貓

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