GitLab在Linux上的持续集成怎么实现

Linux上实现 GitLab CI 的完整步骤

一 架构与前提

• GitLab CI/CD 是 GitLab 内置的流水线能力，无需额外部署服务端；真正执行任务的是 GitLab Runner。Runner 需要安装在 Linux 服务器（物理机/虚拟机/容器），并与你的 GitLab 实例（SaaS 或自托管）配对后才能运行作业。Runner 支持多种 Executor（如 Shell、Docker、Kubernetes 等），选择哪种取决于你的环境与安全要求。

二 安装与注册 GitLab Runner

• 安装 Runner（Ubuntu/Debian 示例）
  • 添加仓库并安装：sudo apt-get update && sudo apt-get install -y gitlab-runner
• 安装 Runner（RHEL/CentOS 示例）
  • 添加仓库并安装：sudo yum install -y 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
• 注册 Runner
  • 获取注册信息：进入项目或实例的 Settings → CI/CD → Runners，复制 URL 与 Registration token
  • 执行注册：sudo gitlab-runner register，依次填写
    • GitLab 实例 URL
    • Registration token
    • Runner 描述与 tags（如：build、deploy、shell）
    • Executor（如：shell、docker）
• 验证与常见状态
  • 查看状态：sudo gitlab-runner status；若 UI 显示 New runner. Has not connected yet，在 Runner 主机执行：sudo gitlab-runner verify，随后刷新页面
  • Runner 配置文件默认位于：/etc/gitlab-runner/config.toml

三 编写 .gitlab-ci.yml 与触发流水线

• 基本结构与最小示例

  • 在项目根目录创建 .gitlab-ci.yml，定义 stages 与 jobs，提交后自动触发流水线

  • 示例（Shell 执行器）： stages:

    • build
    • test
    • deploy

    build-job: stage: build script: - echo “Building the project…”

    test-job: stage: test script: - echo “Running tests…”

    deploy-prod: stage: deploy script: - echo “Deploying the project…” only: - main

• 使用 Docker 执行器与镜像

  • 示例（Node.js）： image: node:18 stages:

    • build
    • test

    build_job: stage: build script: - npm ci - npm run build --if-present

    test_job: stage: test script: - npm test – --ci

• 触发与查看
  • 将 .gitlab-ci.yml 推送到仓库（如 main/develop 分支），GitLab 会自动创建 Pipelines
  • 在项目的 CI/CD → Pipelines 查看作业状态、日志与产物

四 变量 密钥 与多机部署

• 变量与密钥管理
  • 在 Settings → CI/CD → Variables 定义变量（如 SSH_PRIVATE_KEY、DEPLOY_HOST），勾选 Masked 或 Protected 提升安全性
  • 在作业中使用：script: ssh $DEPLOY_USER@$DEPLOY_HOST “systemctl restart app”
• 多机部署策略
  • 按 tags 将作业调度到不同 Runner（如 runner-prod、runner-staging），实现环境隔离
  • 更稳妥的做法：只在一台 Runner 上执行部署，通过 SSH 分批滚动重启目标机器，降低全量同时重启风险

五 常见问题与优化建议

• Runner 未连接
  • 确认服务已启动（sudo gitlab-runner status），执行 gitlab-runner verify，检查 config.toml 与网络连通性
• 作业未调度到预期 Runner
  • 核对作业的 tags 与 Runner 的 tags 一致；必要时在 Runner 设置中调整 Run untagged jobs 与并发数
• 提升构建效率
  • 合理使用 cache（如 node_modules、Maven 本地仓库）、artifacts 在不同阶段传递产物，减少重复工作
• 选择 Executor
  • Shell：简单直接，适合已有环境；Docker：环境隔离、可移植；Kubernetes：弹性伸缩、适合大规模场景