五月的尾声,这个月有些许忙碌。这周主要是在调Gitlab的CI/CD,考虑替代Jenkins的可行性。
中途并没有那么顺利,也不是复杂度的问题,就是调试脚本这事情,总觉得不像debug程序那么顺畅,就类似搭建 Harbor 和简单的 K8S 集群,想一次点亮还真不容易,但是一旦你通过了一次,你发现第二次便无比顺利。

这次是想记录用Gitlab CI/CD的过程,也算是把遇到的问题做一个记录,供自己、其他童鞋们查询。

通过文章,你会知道如何使用 Gitlab CI/CD 搭配 K8S 部署进行项目部署(当然,这只是最简单的使用,根据生产环境需要,可以自己做调整)。

关于CI/CD

CI/CD中的CI,指的是持续集成,也就是代码的自动化流程,应用代码的更改会被自动测试、构建,发布到共享库。
CD 指的是持续交付/持续部署,自动化的部署可以减少人力成本,同时提高交付的速度。

现在的Gitlab CI,已经足够方便,在使用 Gitlab 作为代码仓库的同时,又拥有了部署项目的能力,是非常棒的。

要让项目集成Gitlab CI,只需要在项目中增加文件.gitlab-ci.yml就可以了。

达到的效果

通过Gitlab CI,我们想让每一条分支都有一个可以测试的环境。
同时,我们会将打了Tag的分支部署到staging环境,在staging测试完毕后,部署到production环境。

启动 Gitlab Runner

在 Gitlab CI 中,有两个概念:Pipeline、Job。Pipeline 是一条自动化CI,由Job组成。
而这些工作,都需要由Gitlab Runner来完成,所以,首先我们要启动 Runner,并配置到项目中。

Runner 的安装有许多种方式,这里我们选择 Docker 来启动它。(如果你想使用其他方式,参考这里)

Docker 的版本最少为v1.13.0

1
2
3
4
$ docker run -d --name gitlab-runner --restart always \
-v /srv/gitlab-runner/config:/etc/gitlab-runner \
-v /var/run/docker.sock:/var/run/docker.sock \
gitlab/gitlab-runner:latest

配置文件存放于:/srv/gitlab-runner/config

启动成功后,我们要对runner进行注册,注册完成的配置会写入到上面的配置文件中。

编写 .gitlab-ci.yml

基础概念

让项目用起来

尾声

(时已七月底)
本来在5月31日的时候就开了这篇记录,结果一直到现在才补上内容,主要还是因为最近空闲时间太少,回家倒头便睡,这会终于有空填上了。

参考