GitLab Runner 安裝與設定完整

– 9 分鐘閱讀

在現代軟體開發流程中，持續整合與持續佈署（CI/CD）至關重要。GitLab Runner 作為 GitLab CI/CD 的核心執行單元，扮演著自動化建置、測試和佈署的關鍵角色。本文將引導您完成 GitLab Runner 的安裝與設定，並探討不同執行器、安全性及最佳實務。首先，我們會介紹如何在各種作業系統上安裝 GitLab Runner，包含 Linux、macOS 和 Windows，並示範如何將 Runner 註冊到您的 GitLab 專案。接著，將會探討如何撰寫 .gitlab-ci.yml 設定檔，定義 CI/CD 流程的各個階段。同時，我們也會深入比較不同型別的 Runner，例如分享 Runner、特定 Runner 和群組 Runner，以及各種執行器的特性，例如 Shell、Docker 和 Kubernetes，協助您根據專案需求選擇最佳方案。此外，文章也涵蓋了安全性考量，例如何安全地儲存敏感資訊、設定 Runner 許可權，以及如何利用 GitLab 的安全功能保護您的 CI/CD 流程。最後，我們將探討如何監控 GitLab Runner 的效能，並透過日誌分析和效能指標，持續最佳化您的 CI/CD 流程。

安裝 GitLab Runner

在安裝 GitLab Runner 之前，需要根據你的作業系統選擇不同的安裝方式。對於主要的 Linux 發行版，GitLab 的官方檔案會指引你將 GitLab Runner 的儲存函式庫新增到系統中，然後使用本地的套件管理器來安裝 gitlab-runner 套件。對於 Windows、macOS 以及其他 Linux 發行版，你將使用 curl 從 GitLab 直接下載程式，然後將其設為可執行並安裝與啟動 Runner 代理。

以下以 Red Hat Linux Enterprise 伺服器為例，這個伺服器擁有 x86_64 架構並使用根據 RPM 的套件管理系統。根據 GitLab 的檔案，我們需要首先下載並執行一個 Shell 指令碼，這個指令碼會將 GitLab Runner 的儲存函式庫新增到系統的套件管理器中：

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

如果你檢查這個 Shell 指令碼的內容，會發現它只是檢測作業系統平台，然後執行相應的套件管理命令來新增 GitLab Runner 的儲存函式庫。你可以透過檢查可用的儲存函式庫列表（在 RHEL 中使用 sudo dnf repolist）來驗證這一步是否完成。你應該能在列表中看到 gitlab-runner，與主要的作業系統儲存函式庫並列。

雖然我們已經增加了 Runner 的儲存函式庫，但還沒有安裝 GitLab Runner。我們可以透過安裝 gitlab-runner 套件來完成這一步：

sudo dnf install -y gitlab-runner

安裝完成後，GitLab Runner 會自動在背景中啟動（如果你在 Windows 或 macOS 上安裝或手動在 Linux 上安裝，則需要手動啟動）。你可以使用以下命令來驗證 GitLab Runner 代理是否啟動並執行：

sudo gitlab-runner status

你應該會看到代理正在執行的確認資訊，並且目前還沒有註冊任何與 GitLab 通訊的 Runner。下一步我們將進行 Runner 的註冊。

註冊 GitLab Runner

目前我們已經在電腦上安裝了 GitLab Runner 代理，它作為背景服務執行。然而，目前還沒有任何 Runner 與 GitLab 通訊。我們透過註冊一個或多個 Runner 來設定他們與 GitLab 通訊並執行 CI/CD 工作。

回顧之前對分享、特定和群組 Runner 的討論。當你註冊一個 Runner 與 GitLab 時，你將這些 Runner 與整個 GitLab 執行例項（分享 Runner）、一個群組（群組 Runner）或一個專案（特定 Runner）繫結。註冊指示和註冊後的 Runner 設定會顯示在你註冊 runner 的相應部分（例項、群組或專案）中。例如，回顧圖 5.2，我們可以在「Hats for Cats」專案中的「Settings | CI/CD | Runners」找到這些詳細資訊：

此圖示展示了專案級別的 runner 設定。

另外，請注意圖 5.4 中顯示的註冊 token。這個 token 是由 GitLab 生成的，用於 runner 驗證到正確的 GitLab 區域進行註冊：

  1. 如果你正在演示系統上操作，請將註冊 token 複製到剪貼簿中，因為我們在使用安裝了 GitLab Runner 的電腦時需要它來註冊 runner。
  2. 接著傳回安裕了 GitLab Runner 的電腦。從終端機會話中執行根據提示符的 runner 認證指令碼：
sudo gitlab-runner register
  1. 首先，GitLab 會提示輸入你的 GitLab 應用程式例項 URL。對於 SaaS，這將是 https://gitlab.com 。否則，這將是你用來存取自管理例項的 URL。在此範例中，我們將繼續使用 gitlab.com：
Enter the GitLab instance URL (for example, https://gitlab.com):
https://gitlab.com
  1. 接下來，指令碼會要求輸入 runner 註冊 token。這是圖中所示的 token ，並且取決於你要為其註冊 runner 的專案或群組而不同。換句話說，註冊 token 驗證 runner 與 GitLab ，並確保它註冊到正確的專案或群組：
Enter the registration token:
GR1348941Xi_koNdj8AjJMjSzQyYY
  1. 接著可以提供一個可選描述資訊，它將顯示在 runner 的後設資料中在 GitLab UI 中。
Enter a description for the runner:
[localhost] Linux dev server
  1. 接下來要輸入任意 runner 標籤。回顧標籤是分配給 runner 的標籤後設資料。標籤將 runner 識別為能夠接受具有相同標籤的 CI/CD 工作。例如建立任務可能包含 rhel 標籤以表示任務需要由 Red Hat Linux 提供的工具。只有具有該標籤的 runner 才能接受該工作專案。 標籤可以在註冊 runner 時進行分配如下所示 ，也可以透過修改設定中的 runner 在 gitlab ui 中：
Enter tags for the runner (comma-separated):
dev,rhel

可選擇維護注意事項是另一種描述性後設資料區域而不影響組態 runner 行為：

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

在此指令碼階段新建立的Runner過程將聯絡Gitlab以確認可以通訊和認證：

Registering runner...
succeeded runner=GR1348941Xi_koNdj

7.最後runner會詢問CI/CD工作時應該使用哪種執行環境：也記住執行器取決於有必要工具：例如選擇Docker將需要Docker Engine 安裝及可用於伺服器上：在此例子我們選擇shell是最易於開始及不依賴任何工具

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

安裝與設定 GitLab Runners

GitLab Runner 是 GitLab CI/CD 的核心執行單元，負責在特定的環境中執行您的 CI/CD 管線。這篇文章將詳細介紹如何安裝與設定 GitLab Runner，並探討不同型別的 runners 與 executor 的考量。

安裝 GitLab Runner

首先，您需要在您的伺服器或開發環境中安裝 GitLab Runner。以下是安裝步驟：

  1. 下載並安裝 GitLab Runner：

    sudo apt-get update
sudo apt-get install -y curl
curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
sudo chmod +x /usr/local/bin/gitlab-runner

  2. 建立 GitLab Runner 服務：

    sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

  3. 註冊 runner： 使用以下命令註冊 runner，並提供您的 GitLab 例項 URL 與註冊 token：

    sudo gitlab-runner register

設定 GitLab Runner

在成功註冊後，您可以透過 config.toml 檔案來設定 runner。這個檔案通常位於 /etc/gitlab-runner/config.toml。以下是一些基本的設定專案：

[[runners]]
  name = "Linux dev server"
  url = "https://gitlab.com/"
  token = "ZLXwxp4KWrQp2jjZRxjj"
  executor = "shell"
  [runners.custom_build_dir]

檢查 runner 是否成功註冊

您可以使用以下命令來檢查 runner 是否成功註冊：

sudo gitlab-runner list

這將列出所有已組態的 runners，並顯示其詳細資訊，包括 executor、token 和 GitLab 例項 URL。

在 GitLab UI 中檢查 runner

傳回到 GitLab UI，您可以在 Settings | CI/CD | Runners 中看到已註冊的 runner。以下是一些關鍵特徵：

  • Description：runner 的描述。
  • Tags：runner 的標籤。
  • Lock icon：表示 runner 是否鎖定到特定專案。
  • Edit icon：允許您編輯 runner 的設定。
  • Pause button：暫停 runner，但不取消註冊。

runner 的其他設定

您可以透過點選 runner ID 來檢視更多詳細資訊，包括 runner 的架構、網路細節、活動狀態和可分配的屬性。

補充說明

此圖示展示了在 GitLab UI 中註冊並組態的具體 runner 資訊：

  graph TD;
    A[GitLab UI] --> B[Settings];
    B --> C[CI/CD];
    C --> D[Runners];
    D --> E[Specific Runners];
    E --> F[Linux dev server];

此圖示展示瞭如何在 GitLab UI 中檢視及管理已註冊的 runners。

各型別 runners 與 executor 的考量

不同型別的 runners 和 executor 有不同的應用場景和考量。以下是一些關鍵點：

效能考量

  1. Runner 可用性：根據需求選擇分享 runners、群組 runners 或專屬 runners。
  2. 資源管理：專屬 runners 提供專屬資源，但可能導致資源浪費；分享和群組 runners 則可更有效地分配資源。
  3. 作業依賴管理：確保 jobs 和應用程式依賴的正確處理。

安全性考量

  1. 私有與公共環境：根據敏感性選擇適當的執行環境。
  2. 許可權管理：確保只有授權人員可以管理和組態 runners。

監控與維護

  1. 日誌記錄：確保所有 jobs 的執行日誌都被正確記錄和儲存。
  2. 自動化維護：使用自動化指令碼進行 runner 的更新和維護。

使用GitLab Runner的考量

在使用GitLab Runner進行持續整合和持續佈署（CI/CD）時，有許多技術細節需要深入理解和組態。這些細節包括不同型別的Runner、執行器的安全性、依賴快取、機密管理及監控等。以下內容將探討這些重要考量。

GitLab Runner 的高階組態

除了基本組態外，.gitlab-ci.yml檔案還提供了許多高階選項。例如，pre_clone_script關鍵字允許你在Runner克隆倉函式庫之前設定Git組態命令。這對於需要特定環境設定的專案來說非常有用。

pre_clone_script:
  - git config --global core.askpass /usr/bin/your-askpass-script

內容解密：

  • pre_clone_script：這個關鍵字允許你在Runner克隆倉函式庫之前執行一些命令，例如設定Git組態。
  • git config --global core.askpass：這條命令是用來設定Git的askpass工具，這在需要密碼提示時非常有用。

依賴快取與最佳化

在CI/CD流程中，依賴快取和藝術品（artifact）管理是兩個重要的最佳化點。這些組態可以顯著減少重複下載和安裝依賴的時間，從而提高Pipeline的效率。

依賴快取

  • 在.gitlab-ci.yml檔案中，使用cache關鍵字來指定哪些檔案路徑應該在不同作業之間保留。
  • 結合Runner標籤（tags），可以確保特定作業執行在具有預先快取依賴的Runner上。
cache:
  paths:
    - node_modules/

藝術品管理

  • 預設情況下，每個Runner會下載所有已執行作業的藝術品。
  • 使用dependencies關鍵字來選擇哪些作業的藝術品應該被下載。
build_job:
  artifacts:
    paths:
      - build/
test_job:
  dependencies:
    - build_job

內容解密：

  • cache: 用於指定哪些檔案路徑應該在不同作業之間保留。
  • dependencies: 用於選擇哪些作業的藝術品應該被下載，這樣可以避免不必要的資源消耗。
  • paths: 指定需要快取或下載的檔案路徑。

安全性考量

在GitLab Runner中，安全性是至關重要的。選擇合適的Runner執行器和正確管理機密是保障系統安全的兩大要點。

Runner執行器選擇

  • Shell執行器：方便但風險較高，因為它暴露了伺服器的檔案系統。
  • Docker執行器：相對更安全，因為它使用容器隔離層。
  • VirtualBox/Parallels執行器：最安全，因為它使用虛擬機器進行隔離。

機密管理

  • 避免硬編碼機密：不要將密碼、雲端憑證等機密硬編碼在倉函式庫中。
  • GitLab Secret Detection工具：可以掃描倉函式庫中的潛在機密。
  • 環境變數管理：使用掩碼和保護變數來確保機密不會被意外暴露。

內容解密：

  • Shell執行器：雖然方便，但風險較高，因為它暴露了伺服器的檔案系統。
  • Docker執行器：使用容器隔離層，相對更安全。
  • VirtualBox/Parallels執行器：使用虛擬機器進行隔離，是最安全的選擇。
  • Secret Detection工具：可以掃描倉函式庫中的潛在機密。
  • 環境變數管理：使用掩碼和保護變數來確保機密不會被意外暴露。

監控考量

監控GitLab Runner和管道執行狀態是確保系統健康營運的重要手段。以下是幾個關鍵監控點：

GitLab UI分析

在GitLab UI中，你可以檢視詳細的CI/CD分析資料，包括管道執行時間、成功率等。

此圖示

Runner日誌系統

GitLab Runner會生成詳細的日誌記錄，這些日誌可以透過本地作業系統或外部工具進行管理。

sudo gitlab-runner logs --tail

自我託管GitLab的監控

自我託管版本的GitLab提供了深度的日誌和監控功能，大多數監控可以透過內建的Prometheus伺服器進行管理。

內容解密：

  • GitLab UI分析：提供詳細的CI/CD分析資料，幫助你瞭解管道執行狀況。
  • Runner日誌系統：生成詳細的日誌記錄，方便排查問題。
  • 自我託管GitLab：提供深度日誌和監控功能，透過Prometheus伺服器進行管理。
玄貓

玄貓

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