用 Gitlab CI 持续集成 k8s
五月的尾声,这个月有些许忙碌。这周主要是在调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 | docker run -d --name gitlab-runner --restart always \ |
配置文件存放于:/srv/gitlab-runner/config
。
启动成功后,我们要对runner进行注册,注册完成的配置会写入到上面的配置文件中。
编写 .gitlab-ci.yml
基础概念
让项目用起来
尾声
(时已七月底)
本来在5月31日的时候就开了这篇记录,结果一直到现在才补上内容,主要还是因为最近空闲时间太少,回家倒头便睡,这会终于有空填上了。
参考
- 本文链接:https://keepmoving.ren/devops/gitlab-ci-cd/
- 版权声明:本博客所有文章除特别声明外,均采用 CC BY-NC-SA 3.0 CN 许可协议。转载请注明出处!