概念
我从官网搜了一下，GitLab Runner 是一个开源项目， 它用来运行你定制的任务(jobs)并把结果返回给 GitLab。 GitLab Runner 配合GitLab CI(GitLab 内置的持续集成服务) 协调完成任务。
gitlab
想要了解 GitLab Runner之前，我们先要知道或者说必须要知道GitLab是什么东东？
GitLab是由GitLabInc.开发，使用MIT许可证的基于网络的Git仓库管理工具，且具有wiki和issue跟踪功能。使用Git作为代码管理工具，并在此基础上搭建起来的web服务。简单来说就是github的翻版，一个存放代码的仓库平台。最简单的应用场景就是开发使用git提交代码(push)到gitlab，也可以从gitlab下拉代码(pull)到本地。
对于开发者们来说，git + GitLab已经满足了日常的全部，根本没想过还有GitLab Runner这个东东。那么官方为什么还要推出GitLab Runner这个开源项目？它有哪些应用场景？对于开发者来说有没有必要学习GitLab Runner呢?
GitLab为什么要推出Gitlab Runner？
我个人观点是：GitLab为了加入可持续集成工具(CI/CD)市场。在国内IT界技术人士眼里几乎都听到过大名鼎鼎的jenkins，因为jenkins是一个可持续集成、交付、部署的web平台，jenkins在这个领域几乎占领了整个国内市场。当然还有一些国外的集成工具，但国内几乎都不用。
GitLab-CI(GitLab可持续集成服务)确实在大家眼里是一个比较陌生的概念，因为GitLab是从8.0版本才开始集成GitLab-CI功能的，应用的人本来就很少，所以知道人就更少了，但是随着近年来GitLab的发展越来越强盛，版本更新速度非常之快，功能应用也越来越丰富，其GitLab Runner就孕育而成了。
在当今，git + gitlab + jenkins还是主流的万精油方案，这无可厚非，但由于git + gitlab + gitlab-CI 部署非常轻便，加上越来越多人开始理解和应用gitlab-CI + gitlab-runner发布方案，大多数人都在朝着更加方便快捷部署方向前进，若干年后jenkins在国内的霸主地位岌岌可危，但最终还是要由市场来决定。
GitLab Runer 和 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-runner应用在web发布环境中，所以在实际应用中我进行了一些调整，把gitlab-runner当作“中转站”，一对多方式。“中转站”与各源站通过ssh连接，“中转站”定义好执行的脚本，脚本内容就是通过ssh连接到各源站执行git pull等操作。如下图所示：
使用“中转站”的好处是：
1)单台server管理所有Runner即可，脚本管理集中化；
2)不用每台源站PC都要安装Runner，然后再注册，过于繁琐；
3)ssh 连接方式主流、便捷，但需要控制好防火墙策略；
4)在gitlab UI界面，管理runners也简洁明了；
5)单个job执行后，所有源站反馈结果信息集中化，方便查看；
其他方案
第一种(推荐)：公用1个runner，很简单，所有后方集群向gitlab-ci注册，公用runner根据定义不同的脚本(脚本命名为不同集群名称，容易识别)去往不同的集群。(都是ssh连到集群执行命令)
第二种(高级)：1台多个runner，虽然多，但是压力分摊到不同runner进程上，但也不适用建太多runner，这样管理反而不方便。
我为什么要运行多个runner？
这个主要还是为了区分业务，每一类业务使用一个runner执行，这样在管理上也方便区分，当然，所有业务也可以共用一个runner。
最后，对于开发者来说有没有必要学习GitLab Runner？
我个人觉得GitLab的可持续集成服务和发布对于开发者来说只要知道有这个功能就可以了，而对于web框架部署或是运维人员来说就非常有必要学习一下了。
本文错漏不足之处还请见谅！
