ubuntu gitlab怎样实现持续集成

Ubuntu 上搭建 GitLab CI/CD 的标准流程

在 Ubuntu 上实现 GitLab CI/CD 的核心是安装并注册 GitLab Runner，在仓库根目录提供 .gitlab-ci.yml 定义流水线，由 Runner 在提交或合并请求时自动执行构建、测试与部署。整体流程包括：准备 Runner 执行环境（如 Shell 或 Docker）、注册到 GitLab 实例、编写流水线配置、提交触发与查看日志与产物。

一 安装与注册 GitLab Runner

• 安装 Runner（Ubuntu 20.04/22.04 示例）
  • 添加仓库并安装：
    • curl -L --output /etc/apt/trusted.gpg.d/gitlab.asc https://packages.gitlab.com/install/repositories/gitlab/gitlab-runner/gpgkey
    • echo “deb https://packages.gitlab.com/gitlab/gitlab-runner/ubuntu $(lsb_release -cs) main” | sudo tee /etc/apt/sources.list.d/gitlab-runner.list
    • sudo apt-get update && sudo apt-get install -y gitlab-runner
• 注册 Runner
  • 获取项目或实例的 Runner 注册信息：进入项目 Settings > CI/CD > Runners，复制 URL 与 Registration token。
  • 执行注册：sudo gitlab-runner register，按提示选择 Executor（如 shell 或 docker），可设置 tags（如：build、test、deploy）。
• 启动与验证
  • 作为服务运行：sudo gitlab-runner start（或 systemctl 管理），确保状态为 active (running)。
  • 在项目的 CI/CD > Runners 页面应看到已注册的 Runner 处于在线状态。

二 编写 .gitlab-ci.yml 流水线

• 基本结构与示例
  • stages 定义阶段顺序；每个 job 通过 stage 归属阶段，在 script 中编写脚本；可用 cache 加速依赖、artifacts 传递产物、variables 定义变量、rules 控制触发条件。
  • 示例（Node.js + Docker 构建推送，含产物与缓存）：
    • stages:
      • build
      • test
      • deploy
    • variables:
      • IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    • build:
      • stage: build
      • image: node:18
      • script:
        • npm ci
        • npm run build --if-present
      • cache:
        • paths:
          • node_modules/
      • artifacts:
        • paths:
          • dist/
    • test:
      • stage: test
      • image: node:18
      • script:
        • npm test – --ci
      • dependencies:
        • build
    • deploy:
      • stage: deploy
      • image: docker:24.0
      • services:
        • docker:24.0-dind
      • variables:
        • DOCKER_HOST: tcp://docker:2375
        • DOCKER_TLS_CERTDIR: “”
      • script:
        • docker login -u “$CI_REGISTRY_USER” -p “$CI_REGISTRY_PASSWORD” “$CI_REGISTRY”
        • docker build -t “$IMAGE_TAG” .
        • docker push “$IMAGE_TAG”
      • rules:
        • if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      • environment:
        • name: production
• 语法校验与调试
  • 推送前可在项目的 /ci/lint 页面校验 .gitlab-ci.yml 语法是否正确。

三 触发、监控与问题排查

• 触发与查看
  • 将 .gitlab-ci.yml 提交到仓库后，每次 push 或 Merge Request 都会自动触发流水线；在项目的 CI/CD > Pipelines 查看运行状态、作业日志与耗时，失败的作业可点进日志定位问题。
• 常见卡点与修复
  • 作业一直 pending 并提示 “This job is stuck, because the project doesn’t have any runners online assigned to it.”：检查 Runner 是否在线、是否被 tags 限制、Runner 的 Executor/镜像 是否可用，以及项目的 CI/CD > Runners 配置是否启用。
  • Runner 未后台运行：使用 sudo 注册后通常会以服务方式运行；若以普通用户注册，需手动执行 gitlab-runner run 或安装为服务（gitlab-runner install/start）。

四 安全与最佳实践

• 使用 CI/CD Variables 管理配置与密钥（如 CI_REGISTRY_USER/CI_REGISTRY_PASSWORD），避免明文写在脚本中；必要时设置 Masked 与 Protected。
• 合理使用 cache 与 artifacts：cache 加速依赖复用，artifacts 在阶段间传递构建结果；为生产部署设置 environment 与审批流程，降低风险。
• Runner 隔离与权限：建议以 gitlab-runner 专用用户运行，按项目或环境打 tags，必要时为不同团队/环境提供独立 Runner，避免相互影响。