前言
gitlab 提供了一个开箱即食的 ci/cd 工具， gitlab-runner 。虽然 gitlab-runner 是自动化的核心，但是因为有 helm 的帮助， 安装起来还是很简单的。
自定义配置
首先，我们需要从 gitlab 官方的 helm 仓库中获取到 gitlab-runner 的配置文件，来做一些自定义配置。
helm inspect values gitlab/gitlab-runner > runner-value.yml
这个配置文件中已经有了很详细的注释，如果还是有地方不清楚的可以到官方仓库去查找资料。
下面就开始来对这个文件进行修改。
gitlabUrl
在第19行左右，这个 gitlabUrl 将被 gitlab-runner 用来与 gitlab 通信。由于我们是在 k8s 中，所以这里我们使用之前给 gitlab 配的 service 的名称：http://gitlab 。
runnerRegistrationToken
紧接着下面25行左右，这个 token 是从 gitlab 中来的。我们通过管理员登录 gitlab ，进到如图所示的位置，复制 token 。
于是我们的 token 就是： kWnEJs-sKT-tCqrB7AM_
cloneUrl
在251行左右，我们也是让 runner 访问 service 去。这里设置：http://gitlab/。
这里这个 runner 不是 gitlab-runner 的pod，而是 gitlab-runner 在执行 ci 脚本前，主动生成的一个新的叫做 runner 的 pod 。由这个 runner pod 来做实际的执行工作。我们在下面将会看看具体的 pod 变化情况。
安装
配置好以后，我们通过下面命令安装：
helm upgrade -if runner-value.yml --namespace gitlab gitlab-runner gitlab/gitlab-runner
这里用到了这些参数
-
upgrade表示升级， -
-i表示如果没有就直接安装，所以在没有安装指定包时，install和upgrade -i的效果是一样的， -
-f表示使用制定的value文件，也就是我们刚才下载下来并修改过的runner-value.yml， -
--namespace指定要将包安装到gitlab这个命名空间下， - 然后是安装的名称，以后操作这个包就需要使用这个名称，
- 最后是远程包的名称。
然后我们来看看现在 pod 的情况
我们看到已经 running 了。
我们在看看 gitlab 后台是什么样子：
已经出现了一条记录了，说明安装成功。
测试
我们使用之前提交的那个测试项目来实验一下。 gitlab-ci 的语法我就不赘述了。直接上代码：
test:
script:
- echo hello gitlab
然后保存到测试项目的根目录下，保存为 .gitlab-ci.yml 文件。
提交项目。
我们来看看项目的 pipline 现在是什么情况：
我们看到正在跑，稍微等一下，就可以看到已经成功了。
下面那个失败的
Auto DevOps，不用管它，这是gitlab默认自带的一个迷你ci，把它关掉就好。
成功后，我们点击列表里面绿色小勾，点进去就能看到实际的执行情况。
我们来看看在执行脚本的过程中， gitlab 命名空间下面的变化。
可以看到， gitlab-ruuner 启动了一个新的 runner 来执行我们的脚本，执行完毕后再删除这个 pod 。
总结
到这里， gitlab-runner 就安装成功了。这里面还有一些知识点，比如：
-
gitlab-runner的type都是什么意思，我们可以我们刚才安装的gitlab-runner的type是share， -
gitlab-runner现在没有缓存。
这些问题，我们之后再来研究。
