@[toc]
CI/CD介绍
CI(Continuous Integration)跟CD(Continuous Delivery/Continuous Deployment)的出现主要是为了帮助我们在开发时能更早的发现代码中的bug，避免我们在这些bug上进行后续的开发(一错再错-.-)，甚至将这些bug合并到qa或者staging环境去(错上加错)。
说人话就是，我们在提交代码到git时，git会自动通过脚本进行build跟test，如果这个过程失败了，我们会得到通知，这样我们就知道我们这次提交的代码是有问题的。同时这个检测过程不用任何人工干预(低成本)。
CI/CD的工作流程
- 开启一个新的分支
- 运行自动化脚本来build或者test我们提交的代码
- code review
- 运行自动化脚本来deploy我们提交的代码
https://docs.gitlab.com/ee/ci/introduction/img/gitlab_workflow_example_11_9.png
ci整体原理
- gitlab-runner定时轮询(由config.toml的check_interval来指定间隔)gitlab
- 提交代码到指定分支
- gitlab-runner检测到指定分支的代码变动，执行项目中.gitlab-ci.yml中定义的脚本
安装gitlab runner
-
创建一个由docker管理的volumes
docker volumes create gitlab-runner #如果选择直接挂载一个文件目录，则忽略这一步 #相对于直接挂载一个文件目录，该方式有更好的可移植性，其他更多优势[请参考](https://docs.docker.com/storage/volumes/) -
创建并启动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命令的方式跟宿主机通信 -
注册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通信。 -
杂项
1. 由于ci脚本默认由gitlab-runner这个用户执行，而这个用户是没有权限访问docker.sock的。 所以接下来得先把gitlab-runner的uid改为0. 1. apt-get update 2. apt-get install vim 3. vim /etc/passwd 4. 找到gitlab-runner这个用户，将其uid改为0。如下 # 修改前 gitlab-runner:x:0:123:GitLab Runner:/home/gitlab-runner:/bin/bash # 修改后 gitlab-runner:x:0:0:GitLab Runner:/home/gitlab-runner:/bin/bash ---------------------------------- 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/*"
-
stages指定了ci job可能有的几个阶段。如果我们不指定，默认为build,test,deply。 其定义的顺序决定了job执行的顺序。所以我们在定义有依赖关系的job时，如果其对应的 stage本身的顺序跟job的依赖顺序是一致的，就可以省略掉dependencies的定义。 比如案例中的job2将在job1之后执行，与job的定义顺序无关，取决于stage的定义顺序。 -
job
上述job1跟job2定义了两个job，job1是job的名字。 只要不把job名设置为像stages这种关键字就没没问题。 -
指定当前job的阶段。注意，所有stage相同的job是可以并行运行的。 这个并行数取决于gitlab-runner的配置文件config.toml中的concurrent来设置 -
这个就是指明在什么情况下触发CI。比如， - only后直接跟一个值(only: xxx)，则表示应用到哪个分支 - only下的子项changes则表明哪里有变化(文件或者目录)则触发CI - only下的子项refs表明应用到哪个分支或者mr（值为merge_requests时） -
指定执行脚本的gitlab-runner。这个tag必须是gitlab-runner注册是填的tag -
job执行失败时是否影响后续的job执行。默认值时false true: 当前job执行失败不影响后续的job执行 false: 当前job执行失败则终端整个[pipline](https://docs.gitlab.com/ee/ci/pipelines/)(所有的job跟stage组成的流程) -
before_script、script、after_script
执行顺序从前到后。用法通常为 before_script: 初始化工作 script: 主体脚本 after_script: 收尾工作
关于更优雅的达成目标
关于如何优雅的实现本文所要达成的目标，我觉得有以下几点阻碍
- 如何优雅的让docker容器内的gitlab-runner用户能够访问
/var/run/docker.sock - 如何指定ci脚本的执行用户为root
