一个计算机技术爱好者与学习者

0%

好好学GitLab:GitLab Runner入门篇

1. GitLab Runner简介

GitLab Runner 是一个开源软件,它与 GitLab CI/CD 配合,在管道流中运行作业。
GitLab Runner 是用Go编写,几乎可以直接运行在任何操作系统(个别系统需要自行编译)。
GitLab Runner 也可以在 Docker 容器内运行或部署到 Kubernetes 集群中。

GitLab Runner能不能替换成其他的Runner?可以,但是没有必要,毕竟Gitlab Runner是开源的,有什么个性化需求就自己改一改。而且,也没有找到合适的替代产品。

参考文档:

2. GitLab、Runner和Executor

关于GitLab、Runner和Executor的关系,有一个比喻很恰当:
GitLab是老板,会去查看需求单(.gitlab-ci.yml),建立一张又一张有先后顺序的工单(CI Pipeline)。
GitLab Runner 是执行 CI Job 的工人,定期去询问老板(GitLab)现在有分配给自己的工作(CI Job)吗?如果拿到工作,就开始执行,并在执行过程中将进度即时写在工单上。
Executor 是工人(Runner)执行 CI Job 的工作环境,例如一个 CI Job 是打印出”hello”,那么Runner可以在本地Shell环境中执行,可以在虚拟机环境中执行,还可以在Docker环境中执行;而如果一个CI Job需要在基础镜像上进行构建,那么就需要Docker环境或者K8S环境了。

Runner通常在安装Runner的同一台机器上处理作业。但是,我们也可以让Runner在容器、k8s 集群、或者云上的自动缩放实例中处理作业。

安装Runner后,想要使用它,需要在GitLab平台进行注册,注册做的工作就是建立Gitlab与Runner之间的通信。
注册完成后,Runner就可以运行来自 GitLab 的 CI/CD 作业了。

当我们注册一个Runner时,必须选择一个Executor。Executor决定了每个作业运行的环境。

Gitlab Runner的安装环境包括Linux、MacOS、Windows、Docker和Kubernetes。
而不同安装环境的Runner,支持不同的Executors。
根据Executor的不同,同一个Runner程序,可以注册为不同Executor类型的Runner,例如SSH、Shell、Parallels、VirtualBox、Docker、Docker Machine (auto-scaling)、Kubernetes、Custom。

例如:

  • 如果我们希望 CI/CD 作业运行 PowerShell 命令,那么可以在 Windows 服务器上安装 GitLab Runner,然后注册一个使用 Shell Executor的Runner。
  • 如果我们希望 CI/CD 作业在自定义 Docker 容器中运行命令,那么可以在 Linux 服务器上安装 GitLab Runner 并注册一个使用 Docker Executor 的 Runner。
  • 我们还可以在虚拟机上安装 GitLab Runner,并让它使用另一个虚拟机作为Executor。

最常用的Executor:Shell、Docker、Docker Machine、Kubernetes。

参考文档:

3. Executor简介

3.1. Shell

Shell 是最简单的配置执行器。构建所需的所有依赖项都需要手动安装在安装 GitLab Runner 的同一台机器上。

3.2. Docker executor

一个很好的选择是使用 Docker,因为它允许一个干净的构建环境,并且具有简单的依赖项管理(构建项目的所有依赖项都可以放在 Docker 映像中)。 Docker 执行器允许您轻松创建具有依赖服务的构建环境,例如 MySQL。

当我们在 Docker 容器中安装 GitLab Runner 并选择 Docker executor来运行作业时,它有时被称为 Docker-in-Docker (dind)配置。

注意:有些Docker容器中,默认的shell并不是bash,shell选择逻辑如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
if [ -x /usr/local/bin/bash ]; then
exec /usr/local/bin/bash $@
elif [ -x /usr/bin/bash ]; then
exec /usr/bin/bash $@
elif [ -x /bin/bash ]; then
exec /bin/bash $@
elif [ -x /usr/local/bin/sh ]; then
exec /usr/local/bin/sh $@
elif [ -x /usr/bin/sh ]; then
exec /usr/bin/sh $@
elif [ -x /bin/sh ]; then
exec /bin/sh $@
else
echo shell not found
exit 1
fi

参考文档:

3.3. Docker Machine executor

Docker Machine 是 Docker 执行器的特殊版本,支持自动缩放。它像普通的 Docker 执行器一样工作,但使用 Docker Machine 按需创建的构建主机。

Docker官方已经废弃了Docker Machine,GitLab Runner使用的是自己维护的Docker Machine。

Docker Machine executor原理:

  • 安装Runner并配置gitlab-runner用户具有启动虚拟机的权限
  • Runner调用驱动启动Docker Machine VM,VM系统为Boot2Docker
  • 当VM中开始跑CI Job时,会启动一个Docker容器作为执行容器,在容器中跑CI Job
  • CI Job中可以包含docker build等命令,此时会共享调用VM的Docker,是Docker in Docker模式的一种

参考文档:

3.4. Kubernetes executor

Kubernetes 执行器允许您使用现有的 Kubernetes 集群进行构建。执行器将调用 Kubernetes 集群 API 并为每个 GitLab CI 作业创建一个新的 Pod(带有构建容器和服务容器)。

Kubernetes executor也是支持 Docker-in-Docker 的。

参考文档:

3.5. SSH executor

SSH 执行器是为了完整性而添加的,但它是所有执行器中受支持最少的。它使 GitLab Runner 连接到外部服务器并在那里运行构建。我们有一些来自使用此执行器的组织的成功案例,但通常我们建议使用其他类型之一。

3.6. Virtual Machine executor

这种类型的执行器允许您使用已创建的虚拟机,该虚拟机被克隆并用于运行您的构建。我们提供两个完整的系统虚拟化选项:VirtualBox 和 Parallels。如果您想在不同的操作系统上运行构建,它们可能会很有用,因为它允许在 Windows、Linux、macOS 或 FreeBSD 上创建虚拟机,然后 GitLab Runner 连接到虚拟机并在其上运行构建。它的使用也有助于降低基础设施成本。

3.7. Custom executor

自定义执行器允许您指定自己的执行环境。当 GitLab Runner 不提供执行器(例如,LXC 容器)时,您可以向 GitLab Runner 提供自己的可执行文件,以配置和清理您想要使用的任何环境。