ubuntu gitlab持续集成流程 - 问答

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

一架构与前置条件

组件与职责
- GitLab：托管代码与 CI/CD 流水线 的调度入口（项目根目录的 .gitlab-ci.yml 定义流程）。
- GitLab Runner：实际执行作业的代理，需在与 GitLab 可达的主机上安装并注册，支持 Shell、Docker 等执行器。Runner 与项目通过 注册令牌 和标签绑定。
环境与工具
- 操作系统：Ubuntu 20.04/22.04/24.04。
- 工具：Docker（若使用容器化执行器）、SSH 客户端（用于部署到目标主机）、项目所需的 构建/测试 工具链（如 Node.js/npm、Maven/Gradle、Python/pip 等）。

二安装与注册 GitLab Runner

安装 Runner（Ubuntu 推荐方式）
- 添加仓库并安装：
  - curl -L --output /etc/apt/trusted.gpg.d/gitlab.asc https://packages.gitlab.com/install/repositories/runner/gitlab-runner/gpgkey
  - echo “deb https://packages.gitlab.com/runner/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 或管理员界面）。
- 执行注册：sudo gitlab-runner register，依次填写 GitLab 实例 URL、注册令牌、描述、标签（如：docker、build、deploy）、执行器（建议 Docker 或 Shell）。
- 注册完成后，Runner 配置文件位于 /etc/gitlab-runner/config.toml，可按需调整并发、缓存、镜像等参数。
启动与验证
- 作为服务运行：sudo gitlab-runner start（或 systemctl 管理），确保服务处于 active (running)。
- 在项目的 CI/CD → Runners 页面应能看到已注册的 Runner 及其标签、状态。

三定义流水线 .gitlab-ci.yml

基本结构与示例
- 示例（Node.js + Docker 构建与推送到项目容器注册表，生产部署通过 SSH 执行）：
  - stages:
    - build
    - test
    - deploy
  - variables:
    - IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  - build:
    - stage: build
    - image: node:18
    - script:
      - npm ci
      - npm run build --if-present
    - artifacts:
      - paths:
        
        dist/
  - test:
    - stage: test
    - image: node:18
    - script:
      - npm test – --ci
  - docker-build:
    - stage: build
    - image: docker:24-dind
    - services:
      - docker:24-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 .
      - docker push $IMAGE
    - rules:
      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  - deploy-prod:
    - stage: deploy
    - image: alpine:latest
    - before_script:
      - apk add --no-cache openssh-client
      - mkdir -p ~/.ssh
      - echo “$SSH_PRIVATE_KEY” > ~/.ssh/id_rsa
      - chmod 600 ~/.ssh/id_rsa
      - ssh-keyscan -H $SERVER_IP >> ~/.ssh/known_hosts
    - script:
      - ssh -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP " docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY && docker pull $IMAGE && docker rm -f my-app || true && docker run -d --name my-app -p 80:80 $IMAGE "
    - environment:
      - name: production
      - url: http://$SERVER_IP
    - rules:
      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
关键要点
- stages 顺序决定依赖关系；同一 stage 的作业可并行。
- artifacts 用于在阶段间传递产物（如前端 dist/、Java target/）。
- rules / only 控制作业触发条件（如仅 main 分支部署）。
- environment 记录部署记录，支持回滚与 环境 URL。

四变量安全与部署实践

变量管理
- 路径：Settings → CI/CD → Variables，添加如 SSH_PRIVATE_KEY、SERVER_IP、SERVER_USER、CI_REGISTRY_USER、CI_REGISTRY_PASSWORD 等。
- 建议对敏感变量启用 Masked（掩码显示）与 Protected（仅受保护分支/标签可见），避免泄露。
SSH 部署要点
- Runner 常运行在容器内，直接执行宿主机命令会落在容器内部；通过 SSH 连接到目标服务器执行 docker pull/run 是通用做法。
- 使用 StrictHostKeyChecking=no 避免首次连接交互；私钥以 GitLab CI 变量 注入，并在作业中以文件形式使用（如 ~/.ssh/id_rsa）。
容器化最佳实践
- 构建与运行分离：在 docker-build 阶段构建并推送到 项目容器注册表（$CI_REGISTRY_IMAGE），部署阶段仅负责 pull & run。
- 使用 $CI_COMMIT_SHA 作为镜像标签，保证版本可追溯；必要时增加 latest 标签（谨慎用于生产）。
- 若 Runner 与部署目标为同一台主机，也可选用 Shell 执行器 直接执行部署命令，但可移植性与扩展性较差。

五触发监控与常见问题

触发与监控
- 推送代码到指定分支/标签将自动触发流水线；也可在 CI/CD → Pipelines 页面 Run pipeline 手动触发。
- 在 Jobs 页面查看每个作业的 日志与输出，定位失败原因；在 Pipelines 页面查看 阶段状态 与耗时。
常见问题排查
- 出现 “没有可用 Runner”：检查 Runner 是否已注册、处于 active 状态、标签是否匹配作业的 tags、Runner 与 GitLab 网络是否可达。
- 权限或连接失败：确认 SSH 私钥 正确且已掩码、known_hosts 已配置、目标服务器 Docker 已安装并允许当前用户操作。
- 镜像拉取/推送失败：核对 CI_REGISTRY、CI_REGISTRY_USER/PASSWORD 与镜像名是否正确；必要时登录后再操作。
- Runner 配置调整：修改 /etc/gitlab-runner/config.toml 后执行 sudo gitlab-runner restart 使配置生效。

0 赞

0 踩