1. 课程导入与全景认知

在持续集成与持续交付（CI/CD）体系中，GitLab 负责代码托管、流水线编排与作业调度，而真正把 .gitlab-ci.yml 中的 script 跑起来的，是 GitLab Runner。理解这一点是整门课程的起点：GitLab 是“调度者”，Runner 是“执行者”。当团队规模扩大、流水线并发上升时，单个 Runner 很快会成为瓶颈——作业排队、构建缓慢、资源争抢、缓存失效等问题会集中爆发。本课程要解决的核心问题，就是如何用集群化的方式组织 Runner，并对执行资源进行可度量、可调度、可隔离的治理。

Runner 在 CI/CD 链路中的定位

一次典型的流水线执行可以拆成几个关键环节：开发者推送代码后，GitLab 服务端解析 .gitlab-ci.yml，生成若干作业（Job），放入待执行队列；Runner 通过注册时获得的令牌（token）向 GitLab 轮询或接收作业；拿到作业后，Runner 根据配置的 executor 创建执行环境，拉取代码、注入变量、运行脚本，最后把日志、产物（artifacts）和状态回传给 GitLab。因此 Runner 不是简单的“跑命令的机器”，它同时承担了作业获取、环境准备、脚本执行、结果回传四类职责。

这里有一个容易被忽视的区分：Runner 进程与执行环境是两层概念。Runner 进程本身很轻，真正消耗 CPU、内存、磁盘的是它创建出来的执行环境（例如 Docker 容器、Kubernetes Pod、Shell 会话）。集群治理的对象，往往不是 Runner 进程，而是这些执行环境及其背后的资源池。

执行资源治理要解决什么

“执行资源治理”听起来抽象，落到工程上其实是四组具体矛盾：

• 并发与容量：同时能跑多少作业？由 concurrent、单 Runner 的 limit、以及底层宿主机或集群的容量共同决定。设置过大导致资源耗尽，过小导致排队。
• 隔离与污染：不同项目、不同分支的作业是否互相影响？共享 Shell 执行器容易残留文件与环境污染，容器或 Pod 执行器则天然隔离。
• 标签与路由：哪些作业该跑到哪类 Runner 上？通过 tags 把“需要 GPU 的作业”“需要内网访问的作业”“轻量 lint 作业”分流到不同 Runner 池。
• 成本与效率：缓存（cache）、产物（artifacts）、镜像拉取策略直接影响流水线时长与存储开销，是治理中收益最明显的部分。

下面这张图把 GitLab 服务端、Runner 集群、执行环境与资源池之间的关系，以及作业从入队到回传的完整数据流梳理出来，作为本课程的全景地图：

课程整体学习路径

本课程按“认知—搭建—治理—优化”的递进关系组织。第一阶段建立概念模型，弄清 Runner、executor、并发参数、标签体系之间的关系；第二阶段动手安装与注册 Runner，搭建一个最小可用的集群；第三阶段进入治理核心，围绕并发控制、标签路由、缓存与产物策略展开；第四阶段面向生产，讲监控指标、常见故障排查与成本优化。每一阶段都会给出可执行的配置片段与判断依据，而不是停留在概念描述。

实战环境准备

为了让后续章节的配置可以直接复现，建议准备如下环境。以下参数属于教学示例配置，可根据实际机器规格调整：

在 Runner 主机上，需要预先安装 Docker 与 GitLab Runner 二进制。以 Linux 为例，安装后可用如下命令确认版本，这是后续所有配置的前提：

# 确认 Docker 可用
docker version

# 确认 Runner 已安装
gitlab-runner --version

# 查看 Runner 服务状态
systemctl status gitlab-runner

注册 Runner 时，需要从 GitLab 项目的 Settings → CI/CD → Runners 获取注册令牌。注册命令的关键参数包括 GitLab 地址、令牌、执行器类型和标签，例如：

gitlab-runner register \
  --url "https://gitlab.example.com/" \
  --registration-token "GR1348941xxxxxx" \
  --executor "docker" \
  --docker-image "alpine:latest" \
  --description "docker-runner-a" \
  --tag-list "docker,linux" \
  --run-untagged="false" \
  --locked="false"

注册完成后，在 GitLab 的 Runners 页面应能看到该 Runner 处于在线状态，并显示其标签。此时可以创建一个最小流水线验证链路是否打通：

stages:
  - test

hello-runner:
  stage: test
  tags:
    - docker
  script:
    - echo "Runner 集群已就绪"
    - uname -a

如果作业成功执行并输出系统信息，说明“GitLab 服务端 → Runner → Docker 执行环境 → 结果回传”这条链路已经完整可用。后续章节的并发调优、标签路由、缓存治理，都将在这个基础上展开。判断环境是否真正就绪，不只看作业是否变绿，还要确认：Runner 标签与作业 tags 匹配、执行器类型符合预期、日志中能看到容器创建过程。这三点是排查后续问题的基本依据。