GitLab CI/CD 自動化教學指南 配置 Runner 與 YAML Pipeline 實現容器化部署

什麼是 GitLab CI/CD 與 DevOps 自動化？

GitLab CI/CD 是一套整合於 GitLab 平台中的持續整合 (CI) 與持續交付/部署 (CD) 系統，其核心在於透過 YAML Pipeline (即 .gitlab-ci.yml) 定義自動化的軟體生命週期。其運作邏輯為：1. CI (持續整合) 負責程式碼合併後的自動測試與建置；2. CD (持續交付) 則將成品自動部署至各個環境。搭配 GitLab Runner（負責執行任務的代理程式）與 Docker 容器化技術，開發團隊能落實 IaC (基礎設施即程式碼) 實踐，大幅減少人為手動部署的風險與時間成本，實現高效、可預測且高品質的軟體交付流程。

在現代軟體開發中，DevOps 自動化已成為提升團隊效率與產品品質的關鍵。這套自動化流程的核心，正是透過 GitLab CI/CD 教學所實踐的持續整合與持續部署。

深入理解 GitLab Runner 設定與 YAML Pipeline 的配置，是掌握完整 CI/CD 流程的基石。它不僅加速了從程式碼提交到生產環境的交付週期，更確保了每一次變更都能經過嚴格的測試與驗證，從而降低錯誤率，實現更敏捷、可靠的軟體開發生命週期。這有助於提升軟體交付效率。

什麼是 CI/CD?

CI (Continuous Integration) 與 CD (Continuous Delivery/Deployment) 共同構成了現代軟體開發的自動化核心，其目的在於將從測試、建置到部署的整個CI/CD 流程自動化，取代人工操作。

• CI (Continuous Integration): 專注於持續整合，透過程式碼的自動化測試和建置，將穩定品質的程式碼頻繁合併。
• CD (Continuous Delivery/Deployment): 專注於持續部署與交付，根據所需環境進行自動化建置和部署。

在 GitLab CI/CD 教學中，我們將深入探討如何利用 GitLab Runner 與 YAML Pipeline 進行高效配置。在相關版本控制工具推出 CI/CD 服務前，Jenkins 是常見的選擇，但其 GUI 在多人協作下的版本控制配置較為困難。隨著 YAML 成為 IaC 實踐 (Infrastructure as Code) 的顯學，GitLab CI/CD 和 GitHub Actions 等工具都透過 YAML Pipeline 進行設定與配置，定義必要的「觸發條件」、「環境」和「步驟」，並讀取預設環境變數進行建置與部署。這正是 DevOps 自動化理念在實踐中的體現。

DevOps

DevOps (Development Operations)，是一種新的概念與職缺，透過將系統Docker 容器化搭配 CI/CD 並建立 IaC 實踐 (Infrastructure as Code)，進而達到自動並有效率的維運雲端的資源和系統，節省時間與成本。

CI pipline -> 產生 Docker Image
CD pipline -> Pull Docker Image -> 環境檔 -> 部屬容器

Infrastructure as code (IaC)

將架構透過程式碼表示的好處，這是 IaC 實踐 的核心。

• 可程式化代表可做到驗證與防呆
• 能夠進版控
• 更容易擴充

這段 YouTube 影片深入淺出地解釋了 CI/CD 的核心概念，以及 GitLab 如何實作這些流程，是理解 GitLab CI/CD 自動化部署的絕佳資源。

Docker 預備知識

Docker 是一種Docker 容器化技術，能夠將系統透過 Container 運行。

• Image: 透過映像檔的建立將環境重複使用。
• Container: 是 Image 運行起來的狀態，會搭配環境變數和配置去運行。

常見的 Docker 預備知識：

• YAML: Image 透過 YAML 描述和建置。
• Docker Config:
  • Port binding: 容器內的系統會透過 Port 提供服務，所以需要和本機上的 Port 做連結。
  • Logs: 透過容器的 Log 來查看系統紀錄。
  • --network=host: 容器網路的模式。
  • -d: 背景執行。

管理容器的工具軟體：

• Docker Compose: 組合多個容器依照順序啟動。
• Docker Swarm: 原生容器調度管理平台。
• Kubernetes: 容器調度管理平台（如前文所述）。

Dockerfile 實例示範：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# Set the base image to node:16-alpine
FROM node:16-alpine as build

# Specify where our app will live in the container
WORKDIR /app

# Copy the React App to the container
COPY . /app/

# Prepare the container for building React
RUN npm install
RUN npm install react-scripts -g
# We want the production version
RUN npm run build

# Prepare nginx
FROM nginx:1.16.0-alpine
COPY --from=build /app/build /usr/share/nginx/html
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx/nginx.conf /etc/nginx/conf.d

# Fire up nginx
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

專案的準備與 Gitlab CI 流程

版本控制、程式碼分析、建置、自動化測試以及自動部署，這幾項構成了完整的 pipeline。一個 .gitlab-ci.yml 通常包含：

• 觸發條件: PR、PUSH、分支合併。
• 環境: Node、Python、Java 等等。
• 步驟 (Stages): 常見有 verify (品質檢查)、Package (編譯建置)、Release (發布上線)。

GitLab Runner 設定

負責運行 pipeline 中 job：

• Shared Runner: 跨專案共用。
• Group Runners: 部門共用。
• Specific Runner: 特定專案使用（常用於指定發佈環境）。

常用指令：

• sudo gitlab-runner register: 註冊 Runner（可選 docker 或 shell 模式）。
• gitlab-runner verify --delete: 驗證 Runner 狀態。

.gitlab-ci.yml 實作與常見問題

以一個前端專案來說，常見需要自動化：程式碼 lint、環境部署、單元測試、E2E 測試。

1. 變數設定: config 是公開的，不應放 Token/Key。應進到 Settings > CI / CD > Variables 設定。
2. 試錯成本: CI/CD 設定通常需要實際跑過才知道問題。善用 Gitlab 的 CI Lint。
3. 效能優化: 透過「平行處理」加速大型專案的 Pipeline 效能。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

stages:
  - lint
  - build
  - test
  - deploy

eslint:
  stage: lint
  script:
    - npm install -g eslint
    - eslint --init
    - eslint src/

build:
  stage: build
  script:
    - npm run build
    - docker build -t f2e-example .

test:
  stage: test
  script:
    - npm run e2e

deploy:
  stage: deploy
  script:
    - docker run -d --name f2e-example -p 3000:3000 f2e-example

FAQ：GitLab CI/CD 常見問題

Q1：Runner 的 「Executor」該選 Shell 還是 Docker？

A：這取決於您的用途。Docker Executor 隔離性最好，適合用來執行建置與測試（確保環境乾淨）；而 Shell Executor 則因為能直接操作主機上的資源，常被用來執行最終的部署指令（如操作主機上的 docker run）。

Q2：如何避免 Pipeline 頻繁執行浪費資源？

A：善用 rules 或 only/except 關鍵字。您可以設定只有在 master 分支合併、或是特定資料夾檔案變動時，才觸發昂貴的部署 Pipeline；而在一般開發分支僅執行快速的 Lint 與單元測試。

Q3：Pipeline 失敗了該如何排查？

A：首先查看該 Job 的 Log 紀錄。常見原因包含：1. 映像檔 (Image) 找不到；2. 環境變數未正確載入；3. 網路權限（如無法存取外部 API 或資料庫）。建議在本地端先用 Docker 模擬相同的環境環境測試腳本。

• ← 上一篇
• 下一篇 →