📚 课程目录第2章 GitLab CI基础回顾

GitLab CI 基础回顾：.gitlab-ci.yml 结构、Runner 类型、Job 与 Stage 概念

在深入安全权限配置之前，必须牢固掌握 GitLab CI 的核心基础。本章将系统回顾 .gitlab-ci.yml 的声明式结构、Runner 的分布式执行模型，以及 Job 与 Stage 的编排逻辑。这些概念是后续所有自动化 Runbook 和安全策略的基石。

1. .gitlab-ci.yml 结构：声明式流水线的骨架

.gitlab-ci.yml 是 GitLab CI 的单一配置文件，采用 YAML 格式，定义流水线的全部行为。一个典型的文件包含以下顶层关键字：

关键字	作用	是否必填
stages	定义流水线的阶段列表，决定 Job 的执行顺序	推荐
variables	设置全局或 Job 级别的环境变量	否
before_script	在每个 Job 执行前运行的命令序列	否
after_script	在每个 Job 执行后运行的命令序列	否
image	指定 Job 运行的 Docker 镜像	否
cache	定义依赖缓存策略，加速后续流水线	否
Job 名称	用户自定义的 Job 块，包含 script、stage、tags 等子关键字	是（至少一个）

  关键原则：YAML 对缩进敏感，使用空格（推荐 2 个）而非 Tab。Job 名称是顶级键，其下的 script 是唯一必须包含的子键。

以下是一个最小化但完整的 .gitlab-ci.yml 示例：

stages:
  - build
  - test
  - deploy

variables:
  APP_ENV: "production"

before_script:
  - echo "Starting job for $CI_JOB_NAME"

build_app:
  stage: build
  script:
    - echo "Compiling application..."
    - mkdir -p build/
    - touch build/app.jar
  artifacts:
    paths:
      - build/

test_app:
  stage: test
  script:
    - echo "Running unit tests..."
    - echo "Tests passed."

deploy_prod:
  stage: deploy
  script:
    - echo "Deploying to production server..."
  only:
    - main

2. Runner 类型：分布式执行引擎

GitLab Runner 是执行 Job 的代理程序。根据注册方式和运行环境，Runner 分为三种主要类型：

类型	注册范围	典型用途	安全隔离级别
Shared Runner	GitLab 实例全局	开源项目、通用构建任务	低（多项目共享环境）
Group Runner	指定用户组	团队内部项目、共享缓存	中（组内隔离）
Specific Runner	单个项目	敏感项目、定制化环境、安全合规场景	高（项目独占）

安全建议：在涉及敏感凭证或合规要求的流水线中，优先使用 Specific Runner 并配置 tags 锁定执行环境，避免 Job 被调度到不可控的 Shared Runner 上。

Runner 的执行模式也影响安全策略：

Shell 执行器：直接在宿主机运行，隔离性最差，适合本地测试。
Docker 执行器：每个 Job 启动独立容器，环境隔离性好，是生产环境首选。
Kubernetes 执行器：在 Pod 中运行，适合大规模集群调度，支持动态扩缩。

3. Job 与 Stage 概念：流水线的编排逻辑

Job 是流水线的最小执行单元，包含具体的命令和配置。Stage 是 Job 的逻辑分组，控制并行与串行执行顺序。两者共同构成流水线的执行拓扑。

核心规则：

同一 Stage 内的 Job 默认并行执行。
不同 Stage 按 stages 列表顺序串行执行。
前一个 Stage 中所有 Job 成功，后一个 Stage 才会启动。
任一 Job 失败，默认整个流水线终止（可通过 allow_failure 调整）。

4. 常用关键字速查表

以下关键字在安全权限配置中频繁出现，需要熟练掌握：

关键字	用途	安全相关场景
tags	指定 Runner 标签，控制 Job 调度目标	锁定 Specific Runner，防止敏感 Job 逃逸
only / except	基于分支、标签、变量等条件控制 Job 触发	限制生产部署仅允许 main 分支
rules	更灵活的触发条件（推荐替代 only/except）	基于变量或 CI 环境动态启用/禁用 Job
needs	打破 Stage 顺序，定义 Job 间依赖	优化流水线速度，但需注意安全依赖链
environment	关联部署环境，支持手动审批和回滚	生产环境部署需配置审批门禁
secrets	从外部密钥管理服务注入敏感信息	避免明文密码，强制使用 CI/CD 变量

常见陷阱：在 only/except 中使用正则表达式时，注意 GitLab 的匹配行为与标准正则略有差异。建议新项目统一使用 rules 关键字以获得更精确的控制。

5. 流水线执行状态与生命周期

每个 Job 和整个流水线都有明确的状态机。理解这些状态有助于调试安全策略：

pending：Job 已创建，等待 Runner 调度。
running：Job 正在执行。
success：Job 完成且退出码为 0。
failed：Job 完成但退出码非 0，或脚本异常终止。
canceled：用户手动取消或超时终止。
skipped：因 only/except/rules 条件不满足而未执行。
manual：Job 配置为手动触发，等待用户操作。

6. 安全视角下的基础配置要点

在后续章节构建安全 Runbook 之前，先建立以下基础安全认知：

变量保护：敏感变量（密码、）必须标记为 protected 和 masked，仅在受保护分支或标签上可见。
Job 令牌：每个 Job 自动获得 CI_JOB_，可用于 API 调用，但需限制其权限范围。
镜像来源：指定 image 时使用完整路径和摘要（digest），避免恶意镜像篡改。
缓存隔离：不同分支或 Job 的缓存应使用 key 隔离，防止缓存投毒。

实战建议：在项目根目录创建 .gitlab-ci.yml 后，立即在 GitLab UI 中验证流水线语法（CI/CD → Pipelines → Run pipeline），确保基础结构正确后再添加安全逻辑。