配置GitLab Runner跑CI
2021-05-02 10:56:46 +08 字数:2764 标签: CI GitGitLab CI是GitLab为了提升自动化,按照DevOps理念而设计的Pipeline运行流程。 早于GitHub的[Actions],晚于[Travis CI]等元老级Web CI平台。
Runner简介 ¶
和Jenkins相比,GitLab本身,就相当于Jenkins的Master。 GitLab Runner类似Jenkins的Agent(Slave),可以理解为运行Job的容器或管理者。
GitLab有三种Runner,分别是:
- Shared runners are available to all groups and projects in a GitLab instance.
- Group runners are available to all projects and subgroups in a group.
- Specific runners are associated with specific projects. Typically, specific runners are used for one project at a time.
其中,Shared runners是管理员才能操作的,通常只用在独立或小团队的GitLab中,默认是没有的。 Group runners比较常用,可以支持团队内多个项目共享。 可复用的Runner,可以同时支持一类项目的CI,提高资源复用率。
Specific runners则是特定项目用的,不能共享。 虽然注册上比较麻烦,但是能满足专用需求。 而且,对个人项目来说,没有Group这一层,只能使用另外两种Runner。 由于Shared runners通常不存在,所以只能使用Specific runners。
Runner的本体,是运行在某台机器上的守护进程。 一个守护进程,可以守护多个Runner。 在Runner自己看来,没有类型的区别,它只是根据token和url,注册到指定的GitLab而已。
Runner配置与运行 ¶
- 在预备要做CI的宿主机上,安装GitLab Runner。
- 在GitLab页面中,Group或Project的【CI / CD Settings】(
/settings/ci_cd
)【Runners】中,找到URL和registration token信息。 - 注册一个GitLab Runner。
- 确保GitLab Runner处于运行状态。
- 在Project根目录,添加
.gitlab-ci.yml
文件,填写合适的配置。
其中,步骤2只是查看,步骤5的主要内容是如何写.gitlab-ci.yml
,这里不介绍。
安装GitLab Runner ¶
在预定要跑CI的机器上,安装GitLab Runner。
下载deb包:
wget https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb
这个deb包是针对amd64
架构的,其它支持的架构还有arm
、arm64
。
安装deb包:
sudo dpkg -i gitlab-runner_amd64.deb
安装完成后,不仅增加了可执行文件gitlab-runner
,而且还自动创建了gitlab-runner
用户,以及系统守护进程gitlab-runner.service
。
因此,若无必要,不推荐手动安装可执行文件,也不推荐使用deb/rpm两系以外的Linux发行版。
更多介绍,详见《Install GitLab Runner manually on GNU/Linux | GitLab》。
gitlab-runner用户配置 ¶
虽然gitlab-runner
会被自动创建,但仍然需要一些手工调整。
sudo adduser gitlab-runner docker
sudo rm /home/gitlab-runner/.bash_logout
其中,第一句是添加docker权限,第二句是确保bash能被正常使用。 修改完成后,需要重启服务才能生效。 参考重载或重启。
如果是容器化构建,则对环境没有太多需求,只要安装和配置Docker就够了。 但如果是直接在宿主机构建,则需要按需准备各种构建环境。
注册一个Runner ¶
直接执行sudo gitlab-runner register
,并填写URL、token和描述即可,tags选填(参考设置tags)。
executor如果不知道怎么选,就选shell
吧。
直接执行shell
命令,简单有效。
$ sudo gitlab-runner register
Runtime platform arch=amd64 os=linux pid=1757391 revision=ece86343 version=13.5.0
Running in system-mode.
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://gitlab.example.com/
Please enter the gitlab-ci token for this runner:
8LX6mbaPGYxxxxxxxxxx
Please enter the gitlab-ci description for this runner:
[hostname]: runner2
Please enter the gitlab-ci tags for this runner (comma separated):
Registering runner... succeeded runner=8LX6xxxx
Please enter the executor: parallels, shell, ssh, virtualbox, kubernetes, custom, docker, docker-ssh, docker+machine, docker-ssh+machine:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
执行完成后,gitlab-runner
会自动修改/etc/gitlab-runner/config.toml
文件,并重载daemon程序。
在GitLab上对应的CI/CD配置页面,可以看到新注册的Runner,及其运行状态。
注册token(如上8LX6mbaPGYxxxxxxxxxx
),也是在同一页面获取。
更多介绍,详见《Registering runners | GitLab》。
调整配置 ¶
自动生成的Runner配置固然好,有些调整仍然需要手工修改。 以下为配置示例:
listen_address = "[::]:8090"
concurrent = 16
check_interval = 1
[session_server]
listen_address = "[::]:8093"
advertise_address = "<ip_or_domain>:8093"
session_timeout = 1800
[[runners]]
name = "runner0"
limit = 8
url = "https://gitlab.example.com/"
token = "sKj-SjZAxxxxxxxxxxxx"
executor = "shell"
shell = "bash"
[[runners]]
name = "runner1"
url = "https://gitlab.example.com/"
token = "z9y9YKkYxxxxxxxxxxxx"
executor = "shell"
shell = "bash"
[[runners]]
name = "runner2"
url = "https://gitlab.example.com/"
token = "wPKY9ovsxxxxxxxxxxxx"
executor = "shell"
shell = "bash"
其中,token不能乱改,是和GitLab对接的关键,其它都可以按需调整。
从以上配置也能看出,一台机器资源充裕的情况下,可以同时运行多个GitLab Runner。 甚至,可以注册到不同的GitLab上。
更多介绍,详见《Configuring runners in GitLab | GitLab》。
重载或重启 ¶
修改配置后,需要重载才能生效。 但有些修改必须重启才能生效,所以如果不是业务繁忙,建议重启。
sudo systemctl reload gitlab-runner
# or
sudo systemctl restart gitlab-runner
设置tags ¶
Runner的设置可以在GitLab的网页上,进行二次调整,比如tags。 这是对Runner进行分类,以便不同项目的不同业务选择。
比如,对一个Runner设置了linux
标签后,对应的Job必须要设置这个标签,才能在这个Runner上执行。
以下是一个简单示例,在某机器上编译和测试、在另一机器上部署。
stages:
- test
- deploy
build:
stage: test
tags:
- linux
script:
- make
- make test
only:
- master
- merge_requests
- tags
install:
stage: deploy
tags:
- linux
- production
script:
- make
- make install
only:
- tags
虽然只是个示例,但上面定义的两个Job,展示了GitLab CI的常见用法。
build
属于test
阶段,而install
属于后面的deploy
阶段,build
会先于install
执行。
如果build
执行失败,install
则不会执行。
build
这个Job会在master
分支、MR以及打tag三种情况下触发,
而install
只会在打tag
情况下触发。
build
会在仅有标签linux
的Runner下执行,
而install
只会在包含linux
和production
两个标签的Runner下执行。
更多介绍,详见《GitLab CI/CD pipeline configuration reference | GitLab》。
Runner类型 ¶
以下是所有Runner类型,及其对关键特征的支持情况。
Executor | SSH | Shell | VirtualBox | Parallels | Docker | Kubernetes | Custom |
---|---|---|---|---|---|---|---|
Clean build environment for every build | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | conditional (4) |
Reuse previous clone if it exists | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ | conditional (4) |
Runner file system access protected (5) | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | conditional |
Migrate runner machine | ✗ | ✗ | partial | partial | ✓ | ✓ | ✓ |
Zero-configuration support for concurrent builds | ✗ | ✗ (1) | ✓ | ✓ | ✓ | ✓ | conditional (4) |
Complicated build environments | ✗ | ✗ (2) | ✓ (3) | ✓ (3) | ✓ | ✓ | ✓ |
Debugging build problems | easy | easy | hard | hard | medium | medium | medium |
最常用的是Shell,不知道选什么就选Shell类型。
容器化构建,可以选择Docker类型。
当然,容器化构建也可以选择Shell类型,直接执行docker build
、docker run
等命令。
在容器化构建的基础上,如果有很强的并发构建的需要,可以选择Kubernetes。
更多介绍,详见《Executors | GitLab》。