Auto DevOps之gitlab CI/CD

CI/CD介绍

CI(Continuous Integration)跟CD(Continuous Delivery/Continuous Deployment)的出现主要是为了帮助我们在开发时能更早的发现代码中的bug，避免我们在这些bug上进行后续的开发(一错再错-.-)，甚至将这些bug合并到qa或者staging环境去(错上加错)。

说人话就是，我们在提交代码到git时，git会自动通过脚本进行build跟test，如果这个过程失败了，我们会得到通知，这样我们就知道我们这次提交的代码是有问题的。同时这个检测过程不用任何人工干预(低成本)。

CI/CD的工作流程

1. 开启一个新的分支
2. 运行自动化脚本来build或者test我们提交的代码
3. code review
4. 运行自动化脚本来deploy我们提交的代码

ci整体原理

1. gitlab-runner定时轮询(由config.toml的check_interval来指定间隔)gitlab指定的repo
2. 提交代码到指定分支
3. gitlab-runner检测到代码变动，执行项目中.gitlab-ci.yml中定义的脚本

安装gitlab runner

1. 创建一个由docker管理的volumes

 	docker volumes create gitlab-runner

• 如果选择直接挂载一个文件目录，则忽略这一步
• 相对于直接挂载一个文件目录，该方式有更好的可移植性，其他更多优势请参考

2. 创建并启动gitlab-runner容器

    docker run -d --name gitlab-runner --restart always \
        -v /var/run/docker.sock:/var/run/docker.sock \
    		-v /bin/docker:/bin/docker \
        -v gitlab-runner-config:/etc/gitlab-runner \
        gitlab/gitlab-runner:latest

• 第一个挂载实现在容器内跟宿主机的docker通信（通过curl）
• 第二个挂载结合第一个挂载实现在容器内docker.sock执行宿主机docker命令

3. 注册gitlab-runner

    docker run --rm -it -v gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner:latest register

1. 填写GitLab instance URL。这个就是我们的gitlab实例的地址，如果是自建的，就填上自建实例的域名，如果用的官方的，则填上https://gitlab.com
2. 填写token。打开对应项目-->settings-->ci/cd-->runners，即可看到token
3. 填写description. 这个根据这个runner的用途填写即可，没有特殊的
4. 填写tags. 这个tag让我们可以在.gitlab-ci.yml通过配置来决定本次提交由哪个runner来执行文件中的脚本
5. 选择executor. 这个我选择的是shell。目的是为了能够在容器内跟宿主机的docker通信。

4. 一些注意点

1. 由于ci脚本默认由gitlab-runner这个用户执行，而这个用户是没有权限访问docker.sock的。所以，需要将docker组添加到gitlab-runner的附属组中。执行usermod -aG docker gitlab-runner
2. 如果依赖管理插件用的gradle,那么通常还需要java环境。
   这个可以考虑把宿主机的java目录挂载进来
   再在容器内配置java环境变量。或者也可以考虑重新安装
3. 如果用到了docker-compose，也需要在容器内安装：apt-get install -y docker-compose

编写.gitlab-ci.yml

先上一个案例：

stages:
	- build
	- test
	- deploy
job1:
	stage: build
	only: xxx
	tags: defined in gitlab-runner
	before_script: do something
	script: 
	after_script: 
job2:
	stage: test
	allow_failure: true
	only: 
		changes:
			- "xxx.yaml"
job3:
	stage: deploy
	only: 
		refs:
			- main
		changes: 
			- "service-one/*"

1. stages

• stages指定了ci job可能有的几个阶段。如果我们不指定，默认为build,test,deply。
• 其定义的顺序决定了job执行的顺序。所以我们在定义有依赖关系的job时，如果其对应的
• stage本身的顺序跟job的依赖顺序是一致的，就可以省略掉dependencies的定义。
• 比如案例中的job2将在job1之后执行，与job的定义顺序无关，取决于stage的定义顺序。

2. job

• 上述job1跟job2定义了两个job，job1是job的名字。
• 只要不把job名设置为像stages这种关键字就没没问题。

3. stage

指定当前job的阶段。注意，所有stage相同的job是可以并行运行的。
这个并行数取决于gitlab-runner的配置文件config.toml中的concurrent来设置

4. only

这个就是指明在什么情况下触发CI。比如，

• only后直接跟一个值(only: xxx)，则表示应用到哪个分支
• only下的子项changes则表明哪里有变化(文件或者目录)则触发CI
• only下的子项refs表明应用到哪个分支或者mr（值为merge_requests时）

5. tags

指定执行脚本的gitlab-runner。这个tag必须是gitlab-runner注册是填的tag

6. allow_failure

job执行失败时是否影响后续的job执行。默认false
true表示当前job执行失败不影响后续的job执行
false表示当前job执行失败则终端整个pipline(所有的job跟stage组成的流程)

7. before_script、script、after_script

执行顺序从前到后。用法通常为
before_script: 初始化工作
script: 主体脚本
after_script: 收尾工作