GitLab-CI与GitLab-Runner

1、持续集成（Continuous Integration）

要了解GitLab-CI与GitLab Runner，咱们得先了解持续集成是什么。

持续集成是一种软件开发实践，即团队开发成员常常集成他们的工做，一般每一个成员天天至少集成一次，也就意味着天天可能会发生屡次集成。每次集成都经过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程能够大大减小集成的问题，让团队可以更快的开发内聚的软件。

看完这段话，估计仍是有点懵。怎么理解呢？我是这样理解的：

软件集成是软件开发过程当中的一个环节，这个环节的工做通常会包括如下流程：合并代码---->安装依赖---->编译---->测试---->发布。软件集成的工做通常会比较细碎繁琐，为了避免影响开发效率，之前软件集成这个环节通常不会常常进行或者只会等到项目后期再进行。可是有些问题，若是等到后期才发现，解决问题的代价很大，有可能致使项目延期或者失败。所以，为了尽早发现软件集成错误，鼓励团队成员应该常常集成他们的工做，一般每一个成员天天应该至少集成一次。这就是所说的持续集成。因此说，持续集成是一种软件开发实践。

软件集成的工做细碎繁琐，之前是由人工完成的。可是如今鼓励持续集成，那岂不是要累死人，还影响开发效率。因此，应该考虑将软件集成这个工做自动化，这就出现了所谓的持续集成系统。

持续集成详情见百度百科-持续集成

2、GitLab-CI

GitLab-CI就是一套配合GitLab使用的持续集成系统（固然，还有其它的持续集成系统，一样能够配合GitLab使用，好比Jenkins）。并且GitLab8.0之后的版本是默认集成了GitLab-CI而且默认启用的。

3、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与GitLab-Runner关系示意图

Runner能够分布在不一样的主机上，同一个主机上也能够有多个Runner。

Runner类型

GitLab-Runner能够分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）。

Shared Runner：这种Runner（工人）是全部工程都可以用的。只有系统管理员可以建立Shared Runner。

Specific Runner：这种Runner（工人）只能为指定的工程服务。拥有该工程访问权限的人都可以为该工程建立Shared Runner。

4、GitLab-Runner的安装与使用

个人操做系统是：Centos 7.0 64位

安装gitlab-ci-multi-runner

• 添加yum源

  curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

• 安装

  yum install gitlab-ci-multi-runner

  这里是官网的安装教程，其它操做系统的请参考
  https://gitlab.com/gitlab-org/gitlab-ci-multi-runner

使用gitlab-ci-multi-runner注册Runner

安装好gitlab-ci-multi-runner这个软件以后，咱们就能够用它向GitLab-CI注册Runner了。

向GitLab-CI注册一个Runner须要两样东西：GitLab-CI的url和注册token。
其中，token是为了肯定你这个Runner是全部工程都可以使用的Shared Runner仍是具体某一个工程才能使用的Specific Runner。

若是要注册Shared Runner，你须要到管理界面的Runners页面里面去找注册token。以下图所示：

Shared Runner

若是要注册Specific Runner，你须要到项目的设置的Runner页面里面去找注册token。以下图所示：

Specific Runner

找到token以后，运行下面这条命令注册Runner（固然，除了url和token以外，还须要其余的信息，好比执行器executor、构建目录builds_dir等）。
gitlab-ci-multi-runner register
注册完成以后，GitLab-CI就会多出一条Runner记录，以下图所示：

GitLab-CI Runner

GitLab-CI会为这个Runner生成一个惟一的token，之后Runner就经过这个token与GitLab-CI进行通讯。

那么，问题来了。注册好了的Runner的信息存放在哪儿了呢？
原来，Runner的信息是存放在一个配置文件里面的，配置文件的格式通常是.toml。这个配置文件的存放位置有如下几种状况：

• 在类Unix操做系统下（0.5.0以后版本）
  1. 若是是以root用户身份运行gitlab-ci-multi-runner register，那么配置文件默认是/etc/gitlab-runner/config.toml
  2. 若是是以非root用户身份运行gitlab-ci-multi-runner register，那么配置文件默认是~/.gitlab-runner/config.toml
• 在其余操做系统下以及0.5.0以前版本
  配置文件默认在当前工做目录下./config.toml

通常状况下，使用默认的配置文件存放Runner的配置信息就能够了。固然，若是你有更细化的分类需求，你也能够在注册的时候经过-c或--config选项指定配置文件的位置。具体查看register命令的使用方法：gitlab-ci-multi-runner register --help。

问题：若是不运行gitlab-ci-multi-runner register命令，直接在配置文件里面添加Runner的配置信息能够吗？
回答：固然不能够。由于gitlab-ci-multi-runner register的做用除了把Runner的信息保存到配置文件之外，还有一个很重要的做用，那就是向GitLab-CI发出请求，在GitLab-CI中登记这个Runner的信息而且获取后续通讯所须要的token。

让注册好的Runner运行起来

Runner注册完成以后还不行，还必须让它运行起来，不然它没法接收到GitLab-CI的通知而且执行软件集成脚本。怎么让Runner运行起来呢？gitlab-ci-multi-runner提供了这样一条命令gitlab-ci-multi-runner run-single，详情以下：

[root@iZ25bjcxoq5Z ~]# gitlab-ci-multi-runner run-single --help
NAME:
   run-single - start single runner

USAGE:
   command run-single [command options] [arguments...]

OPTIONS:
   --name, --description   Runner name [$RUNNER_NAME]
   --limit     Maximum number of builds processed by this runner [$RUNNER_LIMIT]
   --ouput-limit    Maximum build trace size [$RUNNER_OUTPUT_LIMIT]
   -u, --url     Runner URL [$CI_SERVER_URL]
   -t, --token     Runner token [$CI_SERVER_TOKEN]
   --tls-ca-file    File containing the certificates to verify the peer when using HTTPS [$CI_SERVER_TLS_CA_FILE]
   --executor     Select executor, eg. shell, docker, etc. [$RUNNER_EXECUTOR]
   --builds-dir    Directory where builds are stored [$RUNNER_BUILDS_DIR]
   --cache-dir     Directory where build cache is stored [$RUNNER_CACHE_DIR]
   --env     Custom environment variables injected to build environment [$RUNNER_ENV]
   --shell     Select bash, cmd or powershell [$RUNNER_SHELL]
   --ssh-user     User name [$SSH_USER]
   --ssh-password    User password [$SSH_PASSWORD]
   --ssh-host     Remote host [$SSH_HOST]
   --ssh-port     Remote host port [$SSH_PORT]
   --ssh-identity-file    Identity file to be used [$SSH_IDENTITY_FILE]
   --docker-host    Docker daemon address [$DOCKER_HOST]
   --docker-cert-path    Certificate path [$DOCKER_CERT_PATH]
   --docker-tlsverify    Use TLS and verify the remote [$DOCKER_TLS_VERIFY]
   --docker-hostname    Custom container hostname [$DOCKER_HOSTNAME]
   --docker-image    Docker image to be used [$DOCKER_IMAGE]
   --docker-privileged   Give extended privileges to container [$DOCKER_PRIVILEGED]
   --docker-disable-cache   Disable all container caching [$DOCKER_DISABLE_CACHE]
   --docker-volumes    Bind mount a volumes [$DOCKER_VOLUMES]
   --docker-cache-dir    Directory where to store caches [$DOCKER_CACHE_DIR]
   --docker-extra-hosts   Add a custom host-to-IP mapping [$DOCKER_EXTRA_HOSTS]
   --docker-links    Add link to another container [$DOCKER_LINKS]
   --docker-services    Add service that is started with container [$DOCKER_SERVICES]
   --docker-wait-for-services-timeout  How long to wait for service startup [$DOCKER_WAIT_FOR_SERVICES_TIMEOUT]
   --docker-allowed-images   Whitelist allowed images [$DOCKER_ALLOWED_IMAGES]
   --docker-allowed-services   Whitelist allowed services [$DOCKER_ALLOWED_SERVICES]
   --docker-image-ttl     [$DOCKER_IMAGE_TTL]
   --parallels-base-name   VM name to be used [$PARALLELS_BASE_NAME]
   --parallels-template-name   VM template to be created [$PARALLELS_TEMPLATE_NAME]
   --parallels-disable-snapshots  Disable snapshoting to speedup VM creation [$PARALLELS_DISABLE_SNAPSHOTS]
   --virtualbox-base-name   VM name to be used [$VIRTUALBOX_BASE_NAME]
   --virtualbox-disable-snapshots  Disable snapshoting to speedup VM creation [$VIRTUALBOX_DISABLE_SNAPSHOTS]

 

要让一个Runner运行起来，--url、--token和--executor选项是必要的。其余选项可根据具体状况和需求进行设置。咱们能够看出来，这个命令里面的选项跟配置文件中Runner的配置项基本上是同样的。那这个命令的运行和配置文件有没有什么关系呢？从个人试验和思考来看，应该是没有什么关系的。由于：

1. 这个命令里面并无指定配置文件位置的选项，若是读取配置文件难道去读取默认位置吗？可是配置文件的位置是能够指定的，不必定在默认位置，这不符合逻辑，因此它应该不会去读配置文件。
2. 我删掉配置文件，这个命令依然可以运行

因此，这个命令应该只是一个能让Runner运行起来的基础命令。但这个命令运行起来的前提是，GitLab-CI中必须事先注册有这个Runner。

那配置文件有毛用？配置文件的做用在后面，可是从这里咱们知道一点：配置文件里面有Runner运行时所须要的信息。

可能你还有一个问题：我用root的用户注册Runner时，注册完Runner就能够用了，并无手动地去运行Runner啊？这个后面讲。

批量地运行Runner

正常状况下，若是我有多个Runner，我并不想手动一个个地运行，要是能一次运行多个Runner多爽啊！嗯哼，gitlab-ci-multi-runner就提供了这样一个命令gitlab-ci-multi-runner run，详情以下：

[root@iZ25bjcxoq5Z gitlab-runner]# gitlab-ci-multi-runner run --help
NAME:
   run - run multi runner service

USAGE:
   command run [command options] [arguments...]

OPTIONS:
   -c, --config "/etc/gitlab-runner/config.toml" Config file [$CONFIG_FILE]
   -n, --service "gitlab-runner"   Use different names for different services
   -d, --working-directory     Specify custom working directory
   -u, --user       Use specific user to execute shell scripts
   --syslog      Log to syslog

 

这个命令总共有5个选项，让咱们从选项来理解一下这个命令：

• -c, --config选项
  这个选项是用来指定配置文件路径的。若是你想同时运行多个Runner，你必须得知道你要运行哪些Runner以及这些Runner运行时所须要的信息。而前面咱们说过，配置文件里面就存放着Runner运行时所须要的信息。并且一个配置文件是能够存放多个Runner的信息的。若是不指定这个选项，就会使用默认的配置文件。
• -n, --service选项
  这个选项是用来指定服务的别名的。为何要有这个选项呢？指定别名有什么意义呢？咱们从上一个选项能够看出来，一次只能运行一批Runner，由于一次只能指定一个配置文件。那若是我有多个配置文件，我要运行多批Runner，那是否是给每一次批量运行服务取不一样的别名来区分更好一点呢。
• -d, --working-directory选项
  这个选项是用来指定这次批量运行服务的工做目录的。若是本身没有指定builds_dir的话，这次运行起来的Runner会把builds_dir放到这个目录里面。
• -u, --user选项
  这个选项很重要，它指定了该以什么用户权限来运行Runner。为了安全，我认为不该该给运行Runner的用户太高的权限，更不该该以root用户来运行Runner。
• --syslog选项
  若是指定了这个选项，则把日志记录到系统日志。

使用服务

可以批量地运行Runner已经很好了，可是还不够好，为何呢？

首先，gitlab-ci-multi-runner run默认是前台运行的，使用体验很差；
其次，当gitlab-ci-multi-runner run在后台运行的时候，要查看其运行状态不方便，并且也没有提供中止gitlab-ci-multi-runner run的命令。
因此，要是能将批量运行Runner这个功能安装为一项服务，就更爽了！

gitlab-ci-multi-runner确实就提供了这样的功能。
install、uninstall、start、stop、restart、status这6个命令就是和服务相关的。
我一开始对gitlab-ci-multi-runner的服务概念感受比较懵，让咱们来看看安装服务install这个命令到底干了一件什么事情。

[root@iZ25bjcxoq5Z ~]# gitlab-ci-multi-runner install --help
NAME:
   install - install service

USAGE:
   command install [command options] [arguments...]

OPTIONS:
   --service, -n "gitlab-runner"   Specify service name to use
   --working-directory, -d "/root"   Specify custom root directory where all data are stored
   --config, -c "/etc/gitlab-runner/config.toml" Specify custom config file
   --user, -u       Specify user-name to secure the runner

 

从选项能够看出，一项服务的信息有4个：服务名、工做目录、配置文件和用户。这个命令的选项和gitlab-ci-multi-runner run的选项基本同样。可见，批量运行Runner和服务之间的关系暧昧。至因而什么关系，往下看gitlab-ci-multi-runner start这个命令。

[root@iZ25bjcxoq5Z ~]# gitlab-ci-multi-runner start --help NAME: start - start service USAGE: command start [command options] [arguments...] OPTIONS: --service, -n "gitlab-runner" Specify service name to use

启动一项服务，只要指定服务的名称就好了（默认服务名称是gitlab-runner）。启动服务后，运行命令ps -aux | grep gitlab-runner查看后台程序，发现启动服务其实就是在后台执行了一个批量运行Runner的任务，因此服务安装命令的选项才会和批量运行Runner命令的选项基本同样。

root 18219 0.0 0.1 331872 5332 ? Ssl 00:06 0:00 /usr/bin/gitlab-ci-multi-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --user gitlab-runner --syslog

还有stop命令用于中止服务，restart命令用于重启服务，status用于查看服务状态。这三个命令的使用方法和start相似，就不一一介绍了。

5、其余一些思考

1. 什么状况下须要注册Shared Runner？
   好比，GitLab上面全部的工程都有可能须要在公司的服务器上进行编译、测试、部署等工做，这个时候注册一个Shared Runner供全部工程使用就很合适。

2. 什么状况下须要注册Specific Runner？
   好比，我可能须要在我我的的电脑或者服务器上自动构建我参与的某个工程，这个时候注册一个Specific Runner就很合适。

3. 什么状况下须要在同一台机器上注册多个Runner？
   好比，我是GitLab的普通用户，没有管理员权限，我同时参与多个项目，那我就须要为个人全部项目都注册一个Specific Runner，这个时候就须要在同一台机器上注册多个Runner。

6、最后

啰啰嗦嗦写了一堆，大致上也算把本身对GitLab-Runner的理解过程写清楚了。为了把GitLab-Runner的用法了解清楚，本身作了不少的测试，但也难全面，中间有一些内容也只是我的理解，未必准确，欢迎批评指正。