ubuntu gitlab持续集成流程
导读：Ubuntu 上搭建 GitLab CI/CD 的标准流程 一 架构与前置条件 组件与职责 GitLab：托管代码与 CI/CD 流水线 的调度入口（项目根目录的 .gitlab-ci.yml 定义流程）。 GitLab Runner...
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/
- paths:
- 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:
- 示例（Node.js + Docker 构建与推送到项目容器注册表，生产部署通过 SSH 执行）：
- 关键要点
- 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 使配置生效。
声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！
若转载请注明出处： ubuntu gitlab持续集成流程
本文地址： https://pptw.com/jishu/753114.html