Auto DevOps之gitlab CI/CD

2021-08-03  本文已影响0人  穹柏

@[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
上一篇下一篇

猜你喜欢

热点阅读