2.1 Runner 客户端架构

GitLab Runner会向GitLab实例注册并等待作业(job)执行。 与作为GitLab前端应用服务器一部分的各个组件不同，Runner 具有非常简单的架构。与其GitLab主机之间的通信基本上是单向的。

1. 基本架构

主要的网络通信是从GitLab Runner到GitLab CI，如下图所示：

时序图描述如下:

当 GitLab Runner 启动时，它将尝试通过 GitLab URL 查找其协调器。当使用注册令牌注册自己时，它将获得一个特殊得令牌以连接到 GitLab。重新启动后，它将连接并等待来自 GitLab CI 的作业。它会定期轮询 GitLab,并且在无事可做时，它将减少对 GitLab 的检查，已禁止过多的网络流量。

当作业在 GitLab CI 中排队时，它将尝试查找可用的 Runner 。Runner 收到命令后，它将克隆触发作业的特定于项目的提交，并将执行 .gitlab-ci.yml 中定义的步骤。执行后，结果将返回给 GitLab。

GitLab CI 的 Runner 分为两种类型：

• 特定 Runner：特定于某个项目的 Runner。
• 共享 Runner：GitLab 管理员可用指定要共享的 Runner。它可用于多个项目，但由于共享，同样存在安全性。

GitLab Runner 可运行在以下操作系统：

• Linux
• FreeBSD
• macOS
• Windows

2. Runner 运行在 Dokcer或 kubernetes 上的架构

如果您将 GitLab Runner 与 Docker 结合使用，则架构与上面的会有所不同。Runner 二进制文件将在 Docker 容器内部执行，而不是直接运行在主机上。如下图：

在使用 kubernetes 时，架构会又有所不同，在集群内部，运行在 kubernetes 集群中的 Runner 可以与 kubernetes API 进行通信，以扩展 Runner 实例的数量。