本系列将会从宏观角度,讲述CI/CD相关知识。系列文章不求把每一项都讲仔细,而是让大家能对CI/CD整体流程有大致的概念。无论你是前端,后端,或是运维团队,只要是CI/CD链路上的一份子,相信这系列文章对你都会有帮助。 阅读更多专栏文章
前言
在详细讲述 Gitlab CI/CD 之前,我先让大家了解一下 Gitlab Runner。 由于它的内容不少,我决定先为它单独出一篇文章。
我们从官方文档的结构可以看出,Gitlab Runner 本身并不是 Gitlab CI/CD 的一部分,但它却独占着与CI/CD 同级别的一栏菜单。由此可见 Gitlab Runner 的重要性。
总体概念
要掌握 Gitlab Runner ,大家需要先了解它的设计理念。
在 Gitlab CI/CD 中,我们把任务流程叫作流水线(pipeline) ,而 Gitlab Runner 则是负责运行流水线任务的主体,可以参考下图:
本质上,Gitlab Runner 就是一个可以提供执行脚本环境的环境,它会根据你gitlab仓库中的配置文件,来执行一连串的任务。而 Gitlab Runner 可以被安装在服务器,虚拟机,甚至是Docker容器中。
Shared Runners
在某些企业中,运维团队会默认提供一些公用 Runners ,开发者可以直接使用它们。可以在项目仓库中点击 settings—— CI/CD 看到下图所示内容:
如果你跟上图右侧所示一样 Shared Runners 栏下,有显示可用的 Runners ,那么恭喜你,你可以直接使用它们,跳过下方安装说明。当然,如果你想了解更多,也可以跟我一起往下走。
安装
如果需要手动安装 Gitlab Runner 可以参考官方文档:docs.gitlab.com/runner/inst…
如上文所说,你可以在各种平台安装runner,但需要注意的是 Gitlab Runner 本质上是自动化脚本执行工具,流水线任务的执行效率与 runner 所在的环境中的硬件性能相关。因此为了避免硬件资源的抢夺,我们不建议把 Gitlab Runner 与生产环境或者开发环境放在一起。
Runner Executors
接下来我们遇到了第二个概念—— Runner Executors。
Gitlab Runner 本身只提供与 Gitlab CI/CD 通信的能力,而真正执行流水线的是其实是 Executors 。因此我们可以把图例细化:
Executor类型
既然Executor是真正脚本执行的地方,为了应对不同场景,Gitlab为我们提供了多种Executor的类型:
- SSH
- Shell
- Parallels
- VirtualBox
- Docker
- Docker Machine (auto-scaling)
- Kubernetes
- Custom
为了更好的地对比,可以参考下方表格:
类型 | 每次运行时创建一个新环境 | 复用上次clone过的内容 | runner环境下的文件访问保护 | 可以迁移runner机器 | 零配置支持并发构建 | 调试构建问题 |
---|---|---|---|---|---|---|
SSH | ✗ | ✓ | ✓ | ✗ | ✗ | 容易 |
Shell | ✗ | ✓ | ✗ | ✗ | ✗ | 容易 |
VirtualBox | ✓ | ✗ | ✓ | 部分可以 | ✓ | 困难 |
Parallels | ✓ | ✗ | ✓ | 部分可以 | ✓ | 困难 |
Docker | ✓ | ✓ | ✓ | ✓ | ✓ | 中等 |
Kubernetes | ✓ | ✗ | ✓ | ✓ | ✓ | 中等 |
怎么选?
在这么多种类型中, shell 是最简单的一种类型,你可以完全把他当作是一个普通的linux系统,但这种方式会影响runner 本身环境。如果你正在学习尝试 Gitlab Runner ,你可以用一个虚拟机安装Gitalb Runner 并直接使用shell类型executor,这样效率是最高的。 但要注意,在生产环境中一般不会用这种方式。
目前普通推荐使用的是 Docker 类型,这也是目前最普遍的选择,除了避免环境污染以外,我们还可以直接使用各种docker镜像来执行流水线任务。
注册
第一次安装完 Gitlab Runner 之后,并不会产生默认的executor。为了可以让代码仓库使用我们的runner,我们需要先进行注册。
具体操作很简单,只要执行下列命令即可:
# 如果你是用Docker安装的Gitlab Runner
docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register
# 如果你是用Unix/Linux安装的Gitlab Runner
gitlab-runner register
# 如果你是用Window安装的Gitlab Runner
.\gitlab-runner.exe register
执行命令之后,会进入一个交互阶段,用于配置:
1. Enter the GitLab instance URL (for example, gitlab.com/)
输入你的gitlab地址,可以在项目仓库的 settings—— CI/CD 的runner 模块中直接复制
2. Enter the registration token:
同上,输入项目仓库的registration token。
3. Enter a description for the runner:
输入对这个runner的文字描述
4. Enter tags for the runner (comma-separated):
输入runner的tag,会与流水线任务关联。
5. Enter optional maintenance note for the runner:
输入用于维护的说明
6. Enter an executor:
选择executor的类型
Enter the default Docker image (for example, ruby:2.7):
如果第六步选择了docker,会让你输入默认的docker 镜像。在流水线任务没有注明使用其他镜像时,会使用默认镜像。
注册成功之后,就可以在项目仓库 settings—— CI/CD 看到我们的runner了。
到这里我们的Gitlab Runner就可以正常使用了!
配置
当然,我们还可以随时修改Gitlab Runner的配置(包括在注册时输入的配置)。所有配置项都在 config.toml 文件里。
- Unix/Linux系统可以在etc/gitlab-runner/ 或者 ~/.gitlab-runner 中找到。
- 其他操作系统可以在 ./ 找到。
下方是一个简单的 config.toml 例子:
# 全局配置
# 可以并发运行的最大任务数量
concurrent = 1
# 任务直接的间隔时间(单位:秒)
check_interval = 0
# session_server配置
[session_server]
# 任务结束之后runner处于活跃状态的时间(单位:秒)
session_timeout = 1800
# 我们runner的配置,大部分是注册时输入的
[[runners]]
name = "local test"
url = "https://xxxxxxxxx"
token = "xxxxxxxxxxxxxxxxx"
executor = "docker"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.docker]
tls_verify = false
image = "ruby:2.7"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
想要了解更多的配置,可以参考:docs.gitlab.com/runner/conf…
总结
今天我们了解的 Gitlab CI/CD 中负责执行脚本的 Gitlab Runner 的设计结构,描述了Executor 的类型与选择方案,并掌握了它的安装,注册流程。最好我们还提到了进一步配置 runner 的方法。
本文的重点在于对Gitlab Runner 的展开描述,让大家对此有一个具体的概念。而它具体是如何与 Gitlab CI/CD 结合,实现自动化流水线的说明,我会在下一篇文章《CI/CD系列 | 一步上手Gitlab CI/CD》中详细讲述。
进一步阅读
Gitlab Runner 官方文档:docs.gitlab.com/runner/
如果你觉得本文对你有一点帮助,麻烦给我点个赞吧~~ 谢谢