Linux GitLab的CI/CD流程如何配置

Linux环境下GitLab CI/CD流程配置指南

1. 安装GitLab Runner（任务执行代理）

GitLab Runner是执行CI/CD任务的守护进程，需先在Linux服务器上安装并注册。

安装Runner（以Ubuntu为例，其他发行版可参考官方文档）：

# 添加GitLab Runner官方仓库
curl -L --output /etc/apt/trusted.gpg.d/gitlab.asc https://packages.gitlab.com/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 gitlab-runner -y

注册Runner：
执行以下命令，按提示输入GitLab实例URL（如https://gitlab.com）和注册Token（从GitLab项目→Settings→CI/CD→Runners获取）：
```
sudo gitlab-runner register
```
可选配置：
- --executor：选择执行器（如shell直接在服务器运行、docker使用Docker容器、kubernetes使用K8s集群）；
- --tag-list：设置Runner标签（如ci,deploy），用于匹配.gitlab-ci.yml中的tags要求；
- --run-untagged：是否运行未打标签的Job（默认false）。

2. 创建.gitlab-ci.yml配置文件

该文件是CI/CD流程的核心，需放在项目根目录，定义阶段（Stages）、**任务（Jobs）**及执行逻辑。

基本结构示例：

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

build_job:
  stage: build
  script:
    - echo "Building the project..."
    - ./build_script.sh  # 自定义构建脚本
  artifacts:             # 定义产物（供后续Job使用）
    paths:
      - target/*.jar     # 例如Java项目的JAR包
    expire_in: 1 hour    # 产物过期时间（可选）

test_job:
  stage: test
  script:
    - echo "Running tests..."
    - ./run_tests.sh     # 自定义测试脚本
  needs: ["build_job"]   # 依赖build_job完成（可选，确保顺序）

deploy_job:
  stage: deploy
  script:
    - echo "Deploying to production..."
    - scp target/*.jar user@server:/deploy/path  # 示例：SCP传输产物
  only:                  # 触发条件（可选）
    - main               # 仅main分支推送时触发

关键配置说明：
- Stages：定义流程阶段（如build→test→deploy），Job按阶段顺序执行；
- Jobs：每个Job对应一个具体任务（如构建、测试），需指定stage、script（执行命令）；
- Artifacts：存储Job生成的文件（如编译产物、测试报告），供后续Job下载使用；
- Needs：定义Job依赖关系（如test_job需等待build_job完成）；
- Only/Except：控制Job触发条件（如only: - main表示仅main分支推送时触发）。

3. 配置CI/CD变量（提升安全性与灵活性）

敏感信息（如服务器密码、API密钥、Docker凭证）不应硬编码在.gitlab-ci.yml中，需通过CI/CD变量管理：

操作步骤：
1. 进入GitLab项目→Settings→CI/CD→Variables；
2. 点击"Add variable"，输入变量名（如SERVER_PASSWORD、DOCKER_REGISTRY_USER）和值；
3. 勾选"Mask variable"（隐藏日志中的变量值，增强安全性）。

在.yml中使用：
通过$变量名引用，例如：

deploy_job:
  script:
    - sshpass -p "$SERVER_PASSWORD" scp target/*.jar user@server:/deploy/path

4. 触发CI/CD流程

自动触发：默认情况下，当代码推送到仓库（如git push origin main）或创建合并请求（MR）时，GitLab会自动检测.gitlab-ci.yml并启动Pipeline；
手动触发：可在项目→CI/CD→Pipelines页面点击"Run pipeline"，选择分支或Tag手动启动；

触发器配置：通过.gitlab-ci.yml的trigger关键字设置更复杂的触发条件（如特定路径变更、标签创建）：

trigger_prod:
  trigger:
    include: .gitlab-ci-prod.yml  # 引用子Pipeline配置
    strategy: depend              # 等待子Pipeline完成后才继续

5. 监控与调试

查看Pipeline状态：进入项目→CI/CD→Pipelines，可查看所有Pipeline的运行状态（成功/失败/挂起）；
查看Job日志：点击具体Pipeline中的Job名称，可查看详细执行日志（包括命令输出、错误信息）；
调试技巧：
- 在Job脚本中添加set -x开启调试模式（显示执行的每一条命令）；
- 使用artifacts保存中间文件（如日志、临时文件），便于下载分析；
- 对于Docker Runner，可通过docker logs查看容器内日志。

6. 进阶配置（可选）

缓存优化：通过cache关键字缓存依赖或中间文件，加速构建（如缓存node_modules、maven仓库）：

cache:
  paths:
    - .cache/            # 缓存目录
    - node_modules/      # Node.js依赖
  key: ${CI_COMMIT_REF_SLUG}  # 缓存键（按分支区分）

Docker集成：使用docker Executor或docker:dind（Docker-in-Docker）构建/推送镜像：

build_image:
  image: docker:24       # 使用Docker镜像
  variables:
    DOCKER_HOST: tcp://docker:2375  # Docker守护进程地址
  services:
    - docker:dind        # 启动Docker-in-Docker服务
  script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

通知机制：通过notify关键字或Webhook配置邮件、Slack、企业微信通知（如Pipeline失败时发送告警）。

通过以上步骤，可在Linux环境下完成GitLab CI/CD流程的基础配置。根据项目需求，可进一步扩展（如多环境部署、蓝绿发布、Canary发布等高级场景）。