Auto DevOps之gitlab CI/CD

@[toc]

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我们提交的代码

https://docs.gitlab.com/ee/ci/introduction/img/gitlab_workflow_example_11_9.png

ci整体原理

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

安装gitlab runner

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

   docker volumes create gitlab-runner
   #如果选择直接挂载一个文件目录，则忽略这一步
   #相对于直接挂载一个文件目录，该方式有更好的可移植性，其他更多优势[请参考](https://docs.docker.com/storage/volumes/)
   

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命令的方式跟宿主机通信
   

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的。
   所以接下来得先把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/*"

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](https://docs.gitlab.com/ee/ci/pipelines/)(所有的job跟stage组成的流程)
   

7. before_script、script、after_script

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

关于更优雅的达成目标

关于如何优雅的实现本文所要达成的目标，我觉得有以下几点阻碍

1. 如何优雅的让docker容器内的gitlab-runner用户能够访问/var/run/docker.sock
2. 如何指定ci脚本的执行用户为root