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_scriptscriptafter_script

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

关于更优雅的达成目标

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

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

猜你喜欢

热点阅读