基本概念

Pipeline

流水线:执行一次流水线相当于一次构建任务,里面可以包含多个流程,如安装依赖,运行测试,编译,部署测试服务器,部署生成服务器等等。任何根据我们设置的提交或MR合并都可以触发Pipeline。

Stages

构建阶段:其实也就是上面提到的流程,我们可以在一次Pipeline里定义多个Stages,每个阶段都有这样的特点:

  • 所有Stages都会按照顺序执行,即当一个Stage完成后,下一个Stage才会开始执行。

  • 只有当所有Stages都执行完成以后,该Pipeline才会构建成功。

  • 如果任何一个Stage失败,那么它后面的所有Stages都不再执行,该Pipeline就会失败。

Jobs

构建工作/任务:表示某个Stage里面要执行的工作。我们可以在Stages里定义多个Jobs,每个Job都会有这样的特点:

  • 相同Stage中的Jobs会并行执行。

  • 相同Stage中的Jobs都执行成功后,该Stage才算成功。

  • 如果任何一个Job失败,那么该Stage就会失败,也就是整个Pipeline也会失败。

GitLab Runner

说完了上面几个概念后,那么由谁来执行这些构建任务呢?上面我们在说配置文件时已经提到它了,就是GitLab Runner。

一般来说,构建任务是耗时又耗资源的工作,如果这件事情交给GitLab CI来做的话,就会导致GitLab的性能大幅降低,更何况GitLab CI又要承担管理各个项目的构建状态,所以就引入了GitLab Runner来帮我们做这件事情。通常我们把GitLab Runner安装在不同的机器上,所以在构建任务运行期间并不会影响到GitLab的性能。

Runner类型可以分为下面两类:

  • Shared Runner(共享型)

    这种Runner(工人)是所有项目都能够使用的。但是也只有系统管理员能够创建Shared Runner。

  • Specific Runner(指定型)

    这种Runner(工人)只能为指定的项目服务。拥有该项目访问权限的人都能够为该项目创建Specific Runner。

安装

# For Debian/Ubuntu
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
$ sudo apt-get install gitlab-ci-multi-runner
# For CentOS
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
$ sudo yum install gitlab-ci-multi-runner

总结

每当我们执行提交或者推送操作时,GitLab就会将这个变动通知GitLab CI,这是GitLab CI会找出与这个工程相关联的GitLab Runner,并通知这些Runner运行一次我们的流水线,对应执行Stages里面的Jobs任务,也就是预先定义好的脚本。所以GitLab Runner 就是一个用来执行软件集成脚本的东西,它就像工厂里面一个个工人,而GitLab CI就是这个工厂的管理中心,所有工人都需要在GitLab CI里面进行注册,并且表明自己的身份,即是为哪个项目服务的,当我们的工程发生变化时,GitLab CI就会通知相应的负责这个项目的工人「Runner」执行对应项目的集成脚本,即流水线上面的工作/任务。 在进行CI之前,我们需要先注册Runner。