什么是 GitLab CI？一份全面的介绍 – wiki基地

作者： /

GitLab CI：一份全面的 DevOps 自动化引擎介绍

在现代软件开发生命周期 (SDLC) 中，持续集成 (Continuous Integration, CI)、持续交付 (Continuous Delivery, CD) 和持续部署 (Continuous Deployment, CD) 已经成为不可或缺的核心实践。它们旨在通过自动化构建、测试和部署流程，加速软件交付速度、提高代码质量、降低发布风险。GitLab CI 正是 GitLab 内置的一款强大且易用的 CI/CD 工具，它与 GitLab 的代码仓库、问题跟踪、容器注册表等功能深度集成，为开发团队提供了一站式的 DevOps 解决方案。

本文将深入探讨 GitLab CI 的各个方面，包括其核心概念、工作原理、配置方法、优势以及一些高级特性，帮助您全面理解并有效利用这一强大的自动化引擎。

一、什么是 GitLab CI/CD？

GitLab CI/CD 是 GitLab 平台内置的一套用于实现持续集成、持续交付和持续部署的工具集。其核心思想是，当开发者将代码推送到 GitLab 仓库时，可以自动触发一系列预定义的脚本和流程，这些流程包括：

  1. 构建 (Build)：编译源代码、打包应用程序。
  2. 测试 (Test)：运行单元测试、集成测试、端到端测试等，确保代码质量。
  3. 安全扫描 (Security Scan)：进行静态应用安全测试 (SAST)、动态应用安全测试 (DAST)、依赖项扫描等，发现潜在漏洞。
  4. 发布 (Release)：创建版本标签、生成发布说明。
  5. 部署 (Deploy)：将应用程序部署到预生产环境、生产环境或其他指定环境。
  6. 监控 (Monitor)：(虽然不是 CI/CD 直接执行，但 CI/CD 可以触发部署监控工具)

GitLab CI/CD 的所有配置都通过一个名为 .gitlab-ci.yml 的 YAML 文件进行定义，该文件位于项目仓库的根目录下。这种“配置即代码” (Configuration as Code) 的方式使得 CI/CD 流程本身也能够像应用程序代码一样进行版本控制、审查和协作。

二、GitLab CI 的核心概念

理解 GitLab CI 的核心概念是掌握其工作方式的关键。

  1. Pipeline (流水线)：

    • 流水线是 GitLab CI/CD 的最高层级组件，代表了一次完整的构建、测试、部署过程。
    • 当代码被推送到仓库或发生其他预定义事件（如合并请求创建、定时触发）时，流水线会被触发。
    • 一个流水线由多个阶段 (Stages) 组成，阶段按顺序执行。

  2. Stage (阶段)：

    • 阶段是流水线中作业 (Jobs) 的逻辑分组。
    • 同一阶段内的所有作业可以并行执行（如果 Runner 资源允许）。
    • 只有当前一个阶段的所有作业都成功完成后，下一个阶段的作业才会开始执行。如果前一阶段有任何作业失败，默认情况下后续阶段不会执行。
    • 常见的阶段包括：build (构建)、test (测试)、deploy (部署) 等。阶段的名称和顺序可以在 .gitlab-ci.yml 中自定义。

  3. Job (作业)：

    • 作业是 GitLab CI/CD 中最基本的执行单元，定义了需要执行的具体任务，例如编译代码、运行测试脚本、构建 Docker 镜像或部署应用。
    • 每个作业都在一个独立的、隔离的环境中运行，通常是一个 Docker 容器或虚拟机。
    • 作业由一系列脚本命令组成，这些命令在指定的 Runner 上执行。
    • 作业可以配置依赖关系、环境变量、缓存、产物等。

  4. Runner (执行器)：

    • Runner 是实际执行作业的代理程序。它是一个独立的应用程序，可以安装在任何能够访问 GitLab 实例的机器上（物理机、虚拟机或 Docker 容器内）。
    • GitLab 通过 Runner 来执行 .gitlab-ci.yml 文件中定义的作业。
    • Runner 类型：
      • Shared Runners (共享执行器)：由 GitLab.com 或 GitLab 管理员提供，可供实例上的所有项目使用。
      • Group Runners (群组执行器)：可供特定群组内的所有项目使用。
      • Specific Runners (特定执行器)：仅供特定项目使用，通常由项目维护者自行配置和管理，具有更高的灵活性和控制力。
    • Runner 可以配置标签 (tags)，作业可以通过指定标签来选择在特定类型的 Runner 上执行（例如，一个标签为 docker 的 Runner 可能专门用于构建 Docker 镜像）。

  5. .gitlab-ci.yml 文件：

    • 这是 GitLab CI/CD 的核心配置文件，使用 YAML 语法编写。
    • 它位于项目仓库的根目录，定义了流水线、阶段、作业以及它们的行为。
    • GitLab 会自动检测此文件，并根据其内容创建和执行流水线。

  6. Artifacts (产物)：

    • 产物是作业成功执行后生成并保存的文件或目录。例如，编译后的二进制文件、测试报告、构建的 Docker 镜像层信息等。
    • 产物可以在同一流水线的后续作业中使用，也可以从 GitLab UI 下载。
    • 可以为产物设置过期时间，以节省存储空间。

  7. Cache (缓存)：

    • 缓存用于在不同流水线运行之间或同一流水线内的不同作业之间共享文件（如依赖项、编译中间件），以加速构建过程。
    • 与产物不同，缓存主要用于性能优化，不保证在后续作业或流水线中一定可用。
    • 例如，可以将 node_modules 目录或 Maven 的 .m2 目录缓存起来，避免每次都重新下载。

  8. Variables (变量)：

    • 变量用于存储和传递配置信息、密钥或其他动态数据。
    • 变量可以在 GitLab UI（项目、群组或实例级别）、.gitlab-ci.yml 文件中定义，也可以通过 API 或在触发流水线时传入。
    • GitLab 提供了许多预定义变量 (Predefined Variables)，如 CI_COMMIT_REF_NAME (当前分支或标签名)、CI_PROJECT_DIR (项目克隆路径) 等。
    • 敏感信息（如 API 密钥、密码）应标记为“受保护” (Protected) 或“屏蔽” (Masked)。

  9. Environments (环境)：

    • 环境用于定义和跟踪应用程序的部署目标，如 staging (预发布环境)、production (生产环境) 等。
    • GitLab CI 可以将部署与特定的环境关联起来，方便追踪每个环境部署的版本、回滚操作等。

三、GitLab CI 的工作流程

一个典型的 GitLab CI 工作流程如下：

  1. 代码提交：开发者将代码更改推送到 GitLab 仓库的特定分支（如 main、develop 或功能分支）。
  2. 触发流水线：GitLab 检测到代码推送事件（或其他配置的触发器，如合并请求、定时任务、API 调用）。
  3. 解析 .gitlab-ci.yml：GitLab 读取项目根目录下的 .gitlab-ci.yml 文件，解析其中定义的流水线结构（阶段和作业）。
  4. 创建流水线实例：根据 .gitlab-ci.yml 的定义，GitLab 创建一个新的流水线实例，并将其与触发事件（如提交 SHA）关联。
  5. 作业调度与执行：
    • GitLab 将流水线中第一个阶段的作业放入待执行队列。
    • 可用的 Runner（匹配作业标签和项目/群组权限的 Runner）会轮询 GitLab 实例，获取待执行的作业。
    • Runner 接收到作业后，会准备执行环境（例如，拉取指定的 Docker 镜像）。
    • Runner 在隔离环境中执行作业中定义的 script 命令。
    • 作业执行过程中，Runner 会实时将日志输出回传给 GitLab。
  6. 状态反馈：作业完成后，Runner 将执行结果（成功、失败）和任何生成的产物报告给 GitLab。
  7. 阶段流转：
    • 如果当前阶段的所有作业都成功完成，GitLab 会启动下一个阶段的作业。
    • 如果当前阶段有任何作业失败（且未配置为 allow_failure: true），则流水线默认会停止，后续阶段不再执行。
  8. 流水线完成：当所有阶段的作业都成功完成（或根据配置允许失败），流水线标记为成功。如果中途有关键作业失败，流水线标记为失败。
  9. 通知与后续操作：根据配置，GitLab 可以发送邮件通知、触发 Webhook，或执行其他自动化操作（如自动合并请求、自动部署到生产环境）。

四、编写 .gitlab-ci.yml 文件

.gitlab-ci.yml 文件是 GitLab CI 的核心。以下是一些常用的关键字和基本结构示例：

“`yaml

定义流水线中将要执行的阶段及其顺序

stages:
– build
– test
– deploy

全局默认设置，例如所有作业默认使用的 Docker 镜像

default:
image: node:16 # 默认使用 Node.js 16 镜像

作业：构建应用程序

build_app:
stage: build # 此作业属于 build 阶段
script:
– echo “Building the application…”
– npm install
– npm run build
artifacts:
paths:
– build/ # 保存 build 目录作为产物
expire_in: 1 week # 产物一周后过期
cache:
key: ${CI_COMMIT_REF_SLUG}-node-modules # 缓存键，通常基于分支名
paths:
– node_modules/ # 缓存 node_modules 目录
policy: pull-push # 拉取和推送缓存

作业：运行单元测试

unit_tests:
stage: test # 此作业属于 test 阶段
script:
– echo “Running unit tests…”
– npm test
needs: # 定义作业依赖，可以不按阶段顺序执行
– job: build_app # 依赖 build_app 作业成功完成
artifacts: true # 需要 build_app 的产物

作业：部署到预发布环境

deploy_staging:
stage: deploy # 此作业属于 deploy 阶段
script:
– echo “Deploying to staging environment…”
# 实际部署脚本，例如 scp, rsync, kubectl apply 等
– ./deploy_to_staging.sh
environment:
name: staging
url: https://staging.example.com
only: # 仅在 develop 分支上运行此作业
– develop

作业：部署到生产环境 (手动触发)

deploy_production:
stage: deploy
script:
– echo “Deploying to production environment…”
– ./deploy_to_production.sh
environment:
name: production
url: https://example.com
when: manual # 此作业需要手动触发
allow_failure: false # 此作业失败会导致流水线失败
only:
– main # 仅在 main 分支上运行此作业
“`

常用关键字解释：

  • image: 指定作业运行所需的 Docker 镜像。
  • services: 指定与主 Docker 镜像一起运行的服务容器（例如数据库）。
  • before_script: 在每个作业的 script 执行之前运行的命令。
  • script: 作业执行的核心命令。
  • after_script: 在每个作业的 script 执行之后运行的命令（无论成功或失败）。
  • stages: 定义流水线中所有阶段的顺序。
  • stage: 指定作业所属的阶段。
  • variables: 定义作业可用的环境变量。
  • cache: 定义需要缓存的路径，以加速后续作业。
  • artifacts: 定义作业完成后需要保存的产物。
  • only/except: (旧版语法) 控制作业何时运行，基于分支、标签等条件。
  • rules: (推荐的新版语法) 更灵活地控制作业何时运行，可以组合多种条件。
  • needs: 允许创建有向无环图 (DAG) 的流水线，作业可以不严格按照阶段顺序执行，而是基于对其他作业的显式依赖。
  • when: 控制作业的执行时机，如 on_success (默认), on_failure, always, manual (手动触发)。
  • allow_failure: 如果设置为 true，则此作业失败不会导致整个流水线失败。
  • tags: 指定作业应该在哪些标签的 Runner 上运行。
  • retry: 定义作业失败时的自动重试次数和条件。

五、GitLab CI 的优势

  1. 深度集成：与 GitLab 代码仓库、合并请求、问题跟踪、容器注册表、安全扫描等功能无缝集成，提供了一站式的 DevOps 体验。开发者可以在熟悉的 GitLab 界面中完成从编码到部署的整个流程。
  2. 易于上手和配置：基于 YAML 的 .gitlab-ci.yml 配置文件简洁明了，学习曲线相对平缓。官方文档详尽，社区活跃。
  3. 灵活性和可扩展性：支持多种编程语言、框架和部署目标。可以通过自定义 Docker 镜像、脚本和 Runner 配置来满足各种复杂需求。支持 DAG 流水线、父子流水线等高级模式。
  4. 强大的社区和文档支持：GitLab 拥有庞大且活跃的社区，以及非常完善的官方文档，遇到问题时很容易找到解决方案。
  5. 成本效益：GitLab.com 为公共和私有项目提供了免费的共享 Runner 配额。对于自建 GitLab 实例，可以根据需求灵活配置 Runner 资源，有效控制成本。
  6. 安全性：内置多种安全扫描功能 (SAST, DAST, 依赖项扫描, 容器扫描, 密钥检测)，帮助在开发早期发现和修复漏洞。变量可以被保护和屏蔽，确保敏感信息安全。
  7. 版本控制的 CI/CD：.gitlab-ci.yml 文件与代码一同存储在 Git 仓库中，CI/CD 配置也实现了版本控制，便于追溯、审计和协作。
  8. 可视化：GitLab UI 提供了直观的流水线视图，可以清晰地看到每个阶段、每个作业的执行状态、日志和耗时。

六、GitLab CI 的高级特性（简介）

除了基础功能，GitLab CI 还提供了一系列高级特性，进一步增强其能力：

  • Auto DevOps：为项目自动创建和配置 CI/CD 流水线，实现零配置的构建、测试、代码质量分析、安全扫描和部署。
  • Review Apps：在合并请求中为每个功能分支自动部署一个临时的、可访问的应用程序实例，方便进行代码审查和功能验收。
  • Merge Trains：在将多个合并请求合并到目标分支（如 main）之前，按顺序逐个验证它们与最新目标分支的集成情况，确保主分支始终稳定。
  • Parent-Child Pipelines / Trigger Pipelines：允许一个流水线触发其他项目或同一项目中的子流水线，实现更复杂的、模块化的 CI/CD 工作流。
  • CI/CD for External Repositories：即使代码托管在 GitHub 或 Bitbucket 等外部仓库，也可以使用 GitLab CI/CD 进行自动化处理。
  • Package Registry Integration: 可以将构建的软件包（如npm包、Maven包、Conan包等）发布到GitLab内置的包注册表中。
  • Container Registry Integration: 内置Docker容器镜像注册表，方便存储和管理CI/CD构建的镜像。

七、如何开始使用 GitLab CI

  1. 拥有一个 GitLab 项目：确保您在 GitLab.com 或自建的 GitLab 实例上有一个项目。
  2. 确保 Runner 可用：
    • 对于 GitLab.com 上的公共项目，通常可以使用共享 Runner。
    • 对于私有项目或自建实例，您可能需要注册和配置自己的 Specific Runner 或 Group Runner。检查项目的 Settings > CI/CD > Runners 部分。
  3. 创建 .gitlab-ci.yml 文件：在项目仓库的根目录下创建一个名为 .gitlab-ci.yml 的文件。

  4. 定义您的第一个流水线：在 .gitlab-ci.yml 文件中编写您的 CI/CD 配置，至少包含一个简单的作业，例如：

    “`yaml
    stages:
    – build

    simple_build_job:
    stage: build
    script:
    – echo “Hello, GitLab CI!”
    – echo “This is my first build job.”
    ``
    5. **提交并推送代码**：将    .gitlab-ci.yml文件提交到您的仓库并推送到 GitLab。
    6. **观察流水线**：推送到 GitLab 后，流水线会自动触发。您可以在项目的    CI/CD > Pipelines` 页面查看流水线的执行状态和日志。

八、总结

GitLab CI/CD 是一个功能强大、配置灵活且与 GitLab 生态系统深度集成的自动化引擎。它通过 .gitlab-ci.yml 文件将 CI/CD 流程代码化，使得团队能够高效地自动化软件开发、测试和部署的各个环节。无论是小型初创团队还是大型企业，GitLab CI 都能提供有力的支持，帮助团队提升开发效率、保障软件质量、加速价值交付，是实践 DevOps 理念的理想工具。

随着 GitLab 平台的不断发展，GitLab CI 的功能也在持续增强和完善，其在自动化领域的地位和影响力日益凸显。掌握 GitLab CI，无疑将为您的软件开发工作流带来革命性的改变。

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部