GitLab持续集成(CI)的介绍与运行机制

GitLab-CI

GitLab-CI就是一套配合GitLab使用的持续集成系统(当然,还有其它的持续集成系统,同样可以配合GitLab使用,比如Jenkins)。而且GitLab8.0以后的版本是默认集成了GitLab-CI并且默认启用的。

首先要明白它的组成. 它有两个东西来支撑:

  1. gitlab-ci server
  2. gitlab-ci-runner

gitlab-ci server负责调度、触发Runner,以及获取返回结果.

而gitlab-ci-runner则是主要负责来跑自动化CI的一个宿主机子.

那么我们总结一下流程,其实是这个样子的:

 

GitLab-Runner

GitLab 8.0+提供了持续集成的功能,在GitLab中有个Runners的概念。runner可以想象成一个守护进程,来守护你注册好的servicegitlab-ci绑定. 一个宿主机里的runner可以维护多个不同的service. gitlab-ci在收到需要build的请求时,会通知service执行你在.gitlab-ci.yml里面指定好的脚本,然后根据命令行的返回结果来决定这次build的成功还是失败.

在了解完了这些概念以后我们就可以很轻松的搭建一个runner.

 

Runner一共有三种类型

1) 本地Runner

2) 普通的服务器上的Runner

3) 基于DockerRunner

Runner可以分布在不同的主机上,同一个主机上也可以有多个Runner。

Runner类型

GitLab-Runner可以分类两种类型:Shared Runner(共享型)Specific Runner(指定型)

Shared Runner:这种Runner(工人)是所有工程都能够用的。只有系统管理员能够创建Shared Runner。

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

 

GitLab-CI与GitLab-Runner的关系示意图

 

那GitLab-Runner又是什么东东呢?与GitLab-CI有什么关系呢?

GitLab-Runner是配合GitLab-CI进行使用的。一般地,GitLab里面的每一个工程都会定义一个属于这个工程的软件集成脚本,用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时,比如有人push了代码,GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner,并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。

所以,GitLab-Runner就是一个用来执行软件集成脚本的东西。你可以想象一下:Runner就像一个个的工人,而GitLab-CI就是这些工人的一个管理中心,所有工人都要在GitLab-CI里面登记注册,并且表明自己是为哪个工程服务的。当相应的工程发生变化时,GitLab-CI就会通知相应的工人执行软件集成脚本。如下图所示:

 

 

GitLab CI-CD流程图

 

 

 

   

 

 

 

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐