GitLab Runner 安裝組態與 CI/CD 最佳實踐

在現代軟體開發流程中，CI/CD 已成為不可或缺的一環。GitLab Runner 作為 GitLab CI/CD 的核心元件，負責執行 .gitlab-ci.yml 檔案中定義的任務。正確地安裝和組態 GitLab Runner，並選擇合適的執行器，對於 CI/CD 管道的效率和安全性至關重要。本文將會詳細介紹 GitLab Runner 的安裝、組態步驟，以及不同執行器的特性和安全性考量，並進一步探討 CI/CD 最佳實踐，包括依賴項和藝術品快取、安全性強化、效能監控等方面。同時，文章也會涵蓋如何在 CI/CD 管道中整合各種測試方法，例如程式碼品品檢查、自動化功能測試、模糊測試以及可存取性測試，以確保程式碼的品質和穩定性。最後，我們將會探討如何利用 Prometheus 監控 GitLab Runner 的效能指標，以便及時發現和解決潛在問題，進一步提升 CI/CD 流程的效率和可靠性。

安裝與組態 GitLab Runners

GitLab Runner 是 GitLab CI/CD 的核心元件，負責執行您在 .gitlab-ci.yml 檔案中定義的所有作業。它可以在不同的環境中執行，包括本地機器、虛擬機器和雲端服務。以下是如何安裝與組態 GitLab Runner 的詳細步驟。

安裝 GitLab Runner

首先，您需要在目標機器上安裝 GitLab Runner。以下是安裝步驟：

1. 下載安裝包： 前往 GitLab Runner 的官方下載頁面，根據您的作業系統選擇適合的安裝包。例如，對於根據 Debian 的系統，可以使用以下命令：

   sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
   

2. 授予執行許可權：

   sudo chmod +x /usr/local/bin/gitlab-runner
   

3. 建立 GitLab Runner 服務：

   sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
   

4. 啟動 GitLab Runner 服務：

   sudo gitlab-runner start
   

組態 GitLab Runner

安裝完成後，您需要組態 GitLab Runner 以註冊到您的 GitLab 例項。以下是組態步驟：

1. 取得註冊令牌： 在 GitLab 中，前往您的專案設定頁面，選擇 CI/CD -> Runners，然後複製註冊令牌。

2. 註冊 Runner： 使用以下命令註冊 Runner：

   sudo gitlab-runner register
   

   您會被提示輸入一些資訊，包括 GitLab 例項 URL 和註冊令牌。輸入完畢後，Runner 將會成功註冊並開始執行。

驗證 Runner 組態

成功註冊後，您可以透過以下方式驗證 Runner 是否正常執行：

1. 從終端機檢查： 在安裝 GitLab Runner 的機器上執行以下命令：

   sudo gitlab-runner list
   

   您應該會看到已組態的 Runner 資訊。

2. 從 GitLab UI 檢查： 前往您的專案設定頁面，選擇 CI/CD -> Runners，在 特定 Runner 下應該可以看到已註冊的 Runner。

組態與執行者選項

GitLab Runner 支援多種執行者（Executor），包括 shell、ssh、virtualbox 等。每種執行者都有其特定的用途和優缺點。

• Shell 執行者：適合本地開發和測試。
• SSH 執行者：適合遠端伺服器上的執行。
• VirtualBox 執行者：適合隔離環境測試。

組態範例

以下是一個使用 shell 執行者的組態範例：

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

內容解密：

• name：Runner 的名稱。
• url：GitLab 例項的 URL。
• token：註冊時獲得的令牌。
• executor：執行者型別，這裡設定為 shell。
• custom_build_dir：自訂構建目錄。

效能考量

選擇適當的 Runner 組態對於最佳化 CI/CD Pipeline效能至關重要。以下是一些效能考量：

• Runner 的可用性：根據專案需求選擇分享、群組或特定 Runner。
• 資源管理：確保 Runner 有足夠的資源來處理作業。
• 儲存函式庫大小：大型儲存函式庫可能需要調整 GIT_DEPTH 引數來最佳化克隆速度。

安全性考量

為了保證 CI/CD Pipeline的安全性，建議採取以下措施：

• 保護敏感資訊：避免在程式碼中暴露敏感資訊。
• 限制存取許可權：確保只有授權的人員可以存取和管理 Runner。

自動縮放與監控

如果您使用雲端服務，可以考慮啟用自動縮放功能來動態調整 Runner 數量。此外，定期監控 Runner 的執行狀態和效能指標也是必不可少的。

GitLab Runner 安全與最佳實踐

在進行 CI/CD 管道的設定與執行時，選擇適當的 GitLab Runner 型別及執行器至關重要。除了基本的組態外，還需考量依賴專案及藝術品的快取、安全性及監控等方面。以下將詳細探討這些考量。

依賴專案及藝術品快取

快取依賴專案及藝術品的目的是減少 runner 頻繁下載相同檔案的需求，並確保只下載目前 CI/CD 工作所需的檔案。以下是一些關鍵考量：

• 快取組態：在 .gitlab-ci.yml 檔案中使用 cache 關鍵字來指定需要在 runner 之間保留的檔案路徑。
• 標籤組態：建議將 cache 關鍵字與 runner 標籤結合，這樣可以將具有特定依賴專案的工作分配給已經預先快取這些依賴專案的 runner。
• 藝術品下載：預設情況下，每個 runner 會下載所有先前在該管道中執行過的工作所產生的藝術品。可以使用 dependencies 關鍵字來選擇要下載哪些工作的藝術品。例如，如果有獨立的 Windows 和 Linux 建構工作以及對應的測試工作，測試工作應該只下載其對應建構工作的藝術品。

安全性考量

在安裝和組態 runner 時，安全性是一個不可忽視的因素。以下是兩個主要考量：

Runner 執行器選擇

CI/CD 管道本質上是遠端主機上命令的執行，因此存在潛在風險。以下是不同執行器的安全性考量：

• Shell 執行器：雖然方便，但會暴露伺服器的檔案系統給 runner，並且可能會在不同工作之間持續存留。因此，建議僅在可信任專案中使用。
• Docker 執行器：相對較安全，因為容器提供了一層抽象來隔離主機系統。確保容器以非特權模式執行，以防止作業存取主機系統。
• VirtualBox/Parallels 執行器：是最安全的執行器之一，因為作業在一個暫時性虛擬機器內執行，並且與底層超級管理程式隔離。

密碼管理

管理密碼並避免其意外洩露是一個重要議題。以下是一些建議：

• 禁止硬編碼密碼：永遠不要將密碼（如密碼、雲端憑證、佈署金鑰等）硬編碼到專案存放函式庫中。一旦提交到 Git 中，就無法完全移除。
• 使用 GitLab 的 Secret Detection 工具：可以進行歷史掃描以查詢可能硬編碼的密碼。
• 環境變數：將變數設定為掩碼且受保護的變數，並在受保護分支上使用。

監控考量

監控 GitLab Runner 和管道資料至關重要，以確保安全性和資源利用率。以下是三個主要考量：

• GitLab UI 分析：在專案級別下可以找到一般 CI/CD 分析資料。
• Runner 日誌系統：GitLab Runner 生成日誌條目，可以由本地作業系統或外部工具管理。
• 可匯出計量：GitLab Runner 生成可匯出計量資料，可以用於進一步分析。

Docker 執行器安裝

接下來將介紹如何安裝和組態 Docker 執行器。這是一個完整且詳細的。

安裝 Docker 執行器

首先需要確保 Docker 已經安裝在系統中。接著可以透過以下步驟安裝 Docker 執行器：

sudo gitlab-runner register

安裝完成後，需進行基本組態：

sudo gitlab-runner install
sudo gitlab-runner start

內容解密：

1. 基本安裝命令：sudo gitlab-runner register 用於註冊新的 GitLab Runner，這是安裝過程中的第一步。
2. 安裝和啟動命令：sudo gitlab-runner install 用於安裝 GitLab Runner 服務，而 sudo gitlab-runner start 則用於啟動該服務。

組態 Docker 執行器

接著需要組態 Docker 執行器。編輯 config.toml 檔案以包含 Docker 組態：

[[runners]]
  name = "docker-runner"
  url = "https://gitlab.com/"
  token = "YOUR_RUNNER_TOKEN"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    tls_verify = false
    image = "docker:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0

內容解密：

1. 基本組態專案：包括 name、url 和 token 是必須組態的基本專案。
2. Docker 特定組態：如 tls_verify、image、privileged 和 volumes 是 Docker 執行器特定的組態選項。
3. 進階選項：如 disable_entrypoint_overwrite 和 oom_kill_disable 提供更多細緻控制。

啟動並驗證 Docker 執行器

啟動完成後，可以透過以下命令驗證 Docker 執行器是否正常執行：

sudo gitlab-runner verify

內容解密：

1. 驗證命令：sudo gitlab-runner verify 用於驗證 GitLab Runner 的組態是否正確。
2. 驗證結果：如果組態正確且 runner 已正常執行，應該會看到相關提示訊息。

點選瞭解更多

小段落標題：附錄 - 有關資料來源

請注意本文所有資料均出自GitLab官方技術檔案： https://docs.gitlab.com/runner/

小段落標題：GitLab、Docker 安裝教學影片

本篇文章已有詳細說明GitLab、Docker 安裝教學步驟，視覺化影片請至： https://www.youtube.com/watch?v=xxxxxxxxxx

安裝與組態 GitLab Runners

在 GitLab 的使用者介面中，可以看到的指標僅包括一般的 pipeline 趨勢，例如整體的 pipeline 成功和失敗率。這些資料可以作為一個有用的起點，讓你可以判斷 pipeline 失敗是由程式碼中的邏輯錯誤引起，還是由於基礎設施（也就是你的 runners）出現了問題。如果發現 runners 是問題所在，你可以進一步深入檢查 runners 特定的日誌和指標，這將在下文中進行討論。

Runner 日誌

GitLab Runner 沒有專用的日誌檔案。相反地，訊息會發布到一般系統日誌檔案中。通常在 Debian 飲用的作業系統（如 Ubuntu）中，這會是 /var/log/syslog；而在 Fedora 飲用的作業系統（如 Red Hat Linux）中，則是 /var/log/messages。Runner 服務、組態或與 GitLab 的通訊問題所產生的錯誤會被記錄在這些檔案中。

確認 runner 組態正確且能夠與 GitLab 正常通訊的一個有效方法是執行 gitlab-runner verify 命令，如下所示：

$ sudo gitlab-runner verify

這會輸出類別似以下的資訊：

Runtime platform arch=amd64 os=linux pid=84209
revision=32fc1585 version=15.2.1
Running in system-mode.
Verifying runner... is alive runner=ZLXwxp4K

在上述輸出中，你可以驗證 runner 的架構、版本、程式 ID、註冊 ID 以及與 GitLab 的通訊狀態。

Prometheus 指標

自行管理的 GitLab 提供深入的日誌和監控功能。大多數監控都可以由內建的 Prometheus 伺服器管理。類別似地，GitLab Runner 包含了一個嵌入式 HTTP 伺服器，可以將其指標釋出給可用的 Prometheus 伺服器。

為了暴露 runner 的指標，你首先需要編輯 runner 的主組態檔案 config.toml，這通常可以在 /etc/gitlab-runner 中找到。新增 listen_address 引數以告訴指標伺服器監聽哪個埠號。一個包含 listen_address 引數的範例 config.toml 檔案可能如下所示：

concurrent = 1
check_interval = 0
listen_address = "localhost:9252"

[session_server]
session_timeout = 1800

編輯組態檔案後，使用以下命令重新啟動 GitLab Runner 服務：

$ sudo gitlab-runner restart

這樣，可用的 Prometheus 伺服器就能讀取並儀表化 runner 指標。

驗證您的程式碼

對於大多數專案來說，GitLab CI/CD pipeline 首先應該做的是驗證程式碼。不同專案可能會依賴不同任務來執行這個關鍵步驟，但通常包括一些組合來檢查程式碼品質和執行自動化功能測試。作為某些驗證型別的前提條件，有些專案需要先構建其程式碼。本章節將重點討論如何構建並驗證你的程式碼。

首先我們將討論是否需要構建程式碼以及如何組態 GitLab CI/CD pipeline 來完成此任務。然後我們將介紹如何使用 pipeline 執行 GitLab 的內建程式碼品質掃描器。接著我們將解釋如何在 pipeline 中執行自動化功能測試。然後我們將涵蓋一種有趣但不常見的自動化測試方式——模糊測試（fuzz testing），它可以發現傳統自動化功能測試可能會錯過的一些問題。接著我們會提及 GitLab 的可存取性測試（accessibility testing），這確保你的程式碼能夠被廣泛的人群使用。最後我們會簡要提及一些其他驗證程式碼方法，雖然沒有足夠空間詳細描述。

在 CI/CD Pipeline 中構建程式碼

無論是使用 JavaScript、Python 或其他語言編寫應用程式或函式庫時都是如此：在進行任何測試之前需要先構建程式碼。如果你正在開發 Python 應用程式或函式庫時可能需要安裝依賴關係並執行單元測試之前要先構建它；而開發 JavaScript 應用時可能需要執行編譯器（如 Babel）來轉換程式碼。

在 CI/CD Pipeline 中檢查程式碼品質

GitLab 提供了一個內建工具可幫助開發者檢查其程式碼品質並改善它：GitLab Code Quality 工具（簡稱 Code Quality）。此工具提供了多種功能供開發者選擇。

在 CI/CD Pipeline 中執行自動化功能測試

除了 Code Quality 工具外還有其他工具可以幫助進行功能測試：Selenium 和 Cypress。Selenium 是一款非常流行且經過實戰考驗已久（且仍然廣泛使用）供進行網頁應用功能測試而設計之工具；而 Cypress 則是一款較新但具有強大功能之替代品。

在 CI/CD Pipeline 中進行模糊測試

模糊測試（fuzz testing）是在輸入字串上不斷進行隨機變異以找出潛在錯誤或安全漏洞之方法。

在 CI/CD Pipeline 中檢查可存取性

可存取性（accessibility）指的是所有人都能無障礙地存取網站或應用程式而無需任何特殊裝置或技術知識——無論他們是否有視覺、聽覺或其他身體上的殘障也無所謂。

其他驗證您程式碼方法

除了以上所述之外還有其他方式可驗證您程式碼無誤或高品質：如針對安全漏洞掃描等更多工具皆可選擇安裝並執行於您專案中提供完整保護與穩定性保障。

內容解密：

• CI/CD Pipeline：持續整合/持續佈署管線（Continuous Integration/Continuous Deployment, CI/CD）是一種軟體開發實踐方式，旨在透過自動化測試和佈署流程來提高軟體開發效率和品質。
• Runner：Runner 是 GitLab CI/CD 中負責執行管線中的任務（jobs）的一個元件。
• Prometheus：Prometheus 是一個開源系統監控和警告工具包。
• 模糊測試：模糊測試（fuzz testing）是一種軟體測試技術，透過向應用程式輸入隨機資料來尋找潛在漏洞和錯誤。
• Code Quality：GitLab Code Quality 是一個內建工具，幫助開發者檢查和改善程式碼品質。
• Selenium 和 Cypress：這些都是流行的自動化測試工具，用於進行網頁應用功能測試。
• 可存取性：確保所有人都能無障礙地存取網站或應用程式。

小段落標題