GitLab CI/CD工作原理及使用

持续集成(Continuous Integration)

持续集成指的是频繁的将代码集成到主干,每次集成都通过自动化的构建(包括编译、发布、自动化测试)来验证,它的好处主要有两个:

  • 快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易;
  • 防止分支大幅偏离主干。如果不经常集成,很容易导致集成难度变大,以至于难以集成。

GitLab CI/CD

8.0版开始,GitLab持续集成(CI)完全集成到GitLab本身,它还具有持续部署和持续交付功能,可用于构建、测试和部署你的应用程序。下面是GitLab CI/CD流程图。
GitLab CI/CD工作原理及使用_第1张图片
那么怎样让GitLab CI工作起来呢?总结起来就两条:

  1. .gitlab-ci.yml文件添加到远程仓库的根目录;
  2. GitLab项目配置为使用Runner

设置好这些后,你每次push代码到Git仓库,Runner都会自动触发CI pipeline,你可以在项目的Pipelines页面下。如下图所示:
GitLab CI/CD工作原理及使用_第2张图片
如果一切运行正常,你可以看到绿色复选标记,这样你就可以在查看代码之前轻松查看任何提交是否导致测试失败。

.gitlab-ci.yml

说了这么多,那么.gitlab-ci.yml是什么,怎么创建呢?下面就来了解一下。
.gitlab-ci.yml文件配置CI对项目执行的操作,它告诉GitLab runner该做什么。它位于存储库的根目录中,你代码的每次提交,GitLab都会查找.gitlab-ci.yml这个文件,并根据这个文件的内容,在Runner上启动你提交的工作。
默认情况下,它运行一个包含三个stage的管道:buildtestdeploy。你不需要使用所有三个stage,没有工作的stage将会被忽略。

创建.gitlab-ci.yml文件

.gitlab-ci.yml是一个YAML文件,所以你必须特别注意缩进。始终使用空格键,而不是Tab键。

你需要在你仓库的根目录下创建一个名为.gitlab-ci.yml的文件,下面是一个Ruby工程示例。它是最简单的配置,适用于大多数Ruby应用程序。

before_script:
  - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
  - ruby -v
  - which ruby
  - gem install bundler --no-ri --no-rdoc
  - bundle install --jobs $(nproc)  "${FLAGS[@]}"

rspec:
  script:
    - bundle exec rspec

rubocop:
  script:
    - bundle exec rubocop

上面的配置主要做了两件事:

  1. 使用不同的命令执行两个jobrspecrubocop(名称是任意的);
  2. 在每个job之前,执行before_script定义的命令。

关于.gitlab-ci.yml的语法讲解,可以查看官网的介绍Configuration of your jobs with .gitlab-ci.yml,也可以看这个翻译后的文章Gitlab CI yaml官方配置文件翻译。然后根据项目的具体需求,使用这些语法,创建自己的脚本。
如果需要检查项目的.gitlab-ci.yml是否有效,可以在项目命名空间的页面/ci/lint下找到一个Lint工具。也可以在CI/CD下找到CI Lint按钮进入此页面,然后点击Pipelines and Pipelines,最后进入项目中的job

配置Runner

GitLab中,Runner运行你在.gitlab-ci.yml中定义的jobRunner可以是虚拟机、VPS、裸机、Docker容器甚至是容器集群,GitLabRunners通过API进行通信,因此唯一的要求是Runner的及其可以访问GitLab服务器。理想情况下,GitLab Runner不应该和GitLab安装在同一台机器上。

Runner的安装

GitLab Runner可以安装在GNU/LinuxmaxOSFresBSDWindows上,有三种方式进行安装:

  • 手动下载二进制文件;
  • 使用rpm/deb包的仓库;
  • 使用Docker

下面主要介绍如何在Docker容器中运行GitLab Runner

1.首先安装Docker

curl -sSL https://get.docker.com/ | sh

2.将配置卷安装到gitlab-runner容器中以用于配置和其他资源,在macOS上,将/srv代替为/Users/Shared

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

你也可以使用配置容器来安装自定义数据卷

docker run -d --name gitlab-runner-config \
    -v /etc/gitlab-runner \
    busybox:latest \
    /bin/true

3.运行Runner

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

4.注册Runner

docker run --rm -t -i -v /path/to/config:/etc/gitlab-runner --name gitlab-runner gitlab/gitlab-runner register \
  --non-interactive \
  --executor "docker" \
  --docker-image alpine:3 \
  --url "https://gitlab.com/" \
  --registration-token "PROJECT_REGISTRATION_TOKEN" \
  --description "docker-runner" \
  --tag-list "docker,aws" \
  --run-untagged \
  --locked="false"

上面中的有些配置要根据项目的具体内容,做相应变更。例如你的GitLab实例地址,token,描述信息等。有关这些信息的具体配置内容可以在你的GitLab中找到,例如下图:
GitLab CI/CD工作原理及使用_第3张图片

Runner分类

Runner可以限定于某个特定项目,也可以为多个项目提供服务。具体来说可以分为三种:Shared,SpecificGroup Runners

  • Shared Runners,对于多个项目之间具有类似要求的job非常有用,你可以拥有一个或多个可以处理多个项目的Runner,而不是让多个Runner闲置,这样可以更轻松的维护和更新它们。Shared Runners使用公平的队列处理作业,与使用FIFO队列的specific Runner相比,这样可以防止项目创建数百个可能导致消耗掉所有共享资源的情况。
  • Specific Runners,对于有特定需求的项目非常有用,它使用FIFO队列处理作业。
  • Group Runners当你在一个组下有多个项目,并且希望所有项目都可以访问一组Runner时,Group Runner非常有用。Group Runners也使用FIFO队列处理作业。

参考文章:
1. GitLab Continuous Integration (GitLab CI/CD)

你可能感兴趣的:(git学习总结)