Linux中GitLab的CI/CD如何设置 - 问答

1. 安装GitLab Runner（CI/CD任务执行器）
GitLab Runner是执行.gitlab-ci.yml中定义任务的守护进程，需先安装并注册到GitLab实例。

安装Runner：
以Ubuntu为例，可通过包管理器快速安装：

sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates tzdata perl
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-runner/script.deb.sh | sudo bash
sudo apt-get install gitlab-runner -y

或使用Docker安装（更轻量）：

docker run -d --name gitlab-runner --restart always \
  -v "/srv/gitlab-runner/config:/etc/gitlab-runner" \
  gitlab/gitlab-runner:latest

注册Runner：
执行注册命令，按提示输入GitLab实例URL（如https://gitlab.com）和注册Token（从项目Settings → CI/CD → Runners获取）：
```
sudo gitlab-runner register
```
选择执行器类型（推荐shell用于本地环境，docker用于隔离环境），设置标签（如ci、deploy）以便后续筛选任务。

2. 创建.gitlab-ci.yml（CI/CD流程定义文件）
在项目根目录下创建.gitlab-ci.yml文件，定义流水线的阶段（Stages）、**任务（Jobs）**及执行逻辑。以下是一个通用示例：

stages:
  - build    # 构建阶段：编译代码、生成产物
  - test     # 测试阶段：运行单元测试、集成测试
  - deploy   # 部署阶段：将产物部署到目标环境

# 构建任务
build_job:
  stage: build
  image: node:latest  # 使用Node.js镜像（根据项目语言调整，如maven:3.6.3-jdk-8）
  script:
    - echo "Installing dependencies..."
    - npm install       # 安装依赖（Node.js示例）
    - echo "Building project..."
    - npm run build     # 执行构建（如Webpack、Gulp）
  artifacts:            # 保存构建产物，供后续Job使用
    paths:
      - dist/           # 构建产物目录（如Java的target/、Node.js的dist/）
    expire_in: 1 hour   # 产物过期时间（可选）

# 测试任务
test_job:
  stage: test
  image: node:latest
  script:
    - echo "Running unit tests..."
    - npm test          # 运行测试（如Jest、Mocha）
  rules:
    - if: $CI_COMMIT_BRANCH == "main"  # 仅main分支触发测试（避免无效触发）

# 部署任务（示例：Shell脚本部署）
deploy_job:
  stage: deploy
  image: alpine:latest  # 轻量级镜像，仅需ssh命令
  script:
    - apk add --no-cache openssh  # 安装ssh客户端（Alpine镜像需手动安装）
    - echo "Deploying to production server..."
    - scp -r dist/* $SSH_USER@$SERVER_IP:/var/www/html  # 复制产物到服务器
  only:
    - main              # 仅main分支触发部署（保障生产环境稳定性）

关键说明：

stages：定义流水线的阶段顺序（从上到下依次执行）。
jobs：每个任务对应一个具体操作（如构建、测试、部署），需指定stage、image（执行环境镜像）、script（执行命令）。
artifacts：用于传递任务产物（如构建后的文件），供后续任务使用。
rules/only：控制任务触发条件（如仅main分支触发），避免不必要的流水线运行。

3. 配置GitLab CI/CD变量（敏感信息管理）
敏感信息（如SSH私钥、服务器IP、数据库密码）不应直接写入.gitlab-ci.yml，需通过CI/CD变量管理：

进入项目Settings → CI/CD → Variables，点击Add variable。
输入变量名（如SSH_PRIVATE_KEY、SERVER_IP）和值，勾选Mask variable（隐藏变量值，避免日志泄露）。
在.gitlab-ci.yml中通过$变量名引用（如ssh -i $SSH_PRIVATE_KEY user@$SERVER_IP）。

4. 触发CI/CD流水线
将.gitlab-ci.yml文件提交到GitLab仓库的目标分支（如main），GitLab Runner会自动检测文件并触发流水线：

git add .gitlab-ci.yml
git commit -m "Add GitLab CI/CD configuration"
git push origin main

流水线状态可在项目CI/CD → Pipelines页面查看，包括每个任务的执行状态、日志及耗时。

5. 监控与调试流水线

查看流水线状态：进入项目CI/CD → Pipelines，可看到所有流水线的执行历史，点击流水线ID可查看详情。
查看任务日志：在流水线详情页，点击任务名称（如build_job）可查看具体执行日志，用于调试失败问题。
手动触发流水线：若需手动触发（如修复问题后重新部署），可进入CI/CD → Pipelines → Run pipeline，选择分支并点击Run pipeline。

6. 高级配置（可选）

使用Docker Runner：通过docker执行器实现环境隔离（如运行不同版本的Node.js、Python），需在注册Runner时选择docker执行器，并配置docker:dind（Docker-in-Docker）服务。

缓存依赖：通过cache关键字缓存依赖文件（如node_modules、maven仓库），加速后续构建：

build_job:
  cache:
    key: $CI_COMMIT_REF_SLUG  # 按分支缓存
    paths:
      - node_modules/         # 缓存目录

回滚机制：在部署任务中添加回滚逻辑（如备份当前版本、拉取旧版本代码），提升部署安全性。

0 赞

0 踩