如何选择最佳CI工具：Drone VS. Jenkins

介绍

多年来，Jenkins一直是行业标准的CI工具。它包含了许多功能，在其生态系统中有近1000个插件，对于那些推崇简单的人来讲，这可能使人望而生畏。Jenkins在容器出现以前就已存在，不过它仍是很适合容器环境的。但也不得不说，之前Jenkins并无给予容器什么特殊关注，它并无很致力于让容器变得更好，不过如今Blue Ocean和pipeline的出现和发展让这一状况有了很大改观。

Drone是一个广受欢迎的开源CI工具。它实际上是原生Docker，全部的进程都在容器内进行。这使得Drone很是适合像Kubernetes这样的平台，由于在Kubernetes上启动容器很简单。

Rancher容器管理平台对Drone和Jenkins都能提供优秀的支持，用户经过一个自动化的过程便可方便快速地建立Kubernetes集群。我用Rancher 1.6在GCE上部署了K8s 1.8集群，过程之简单简直使人惊喜。

本文将把Drone部署在Kubernetes（Rancher）上，并将从如下三个方面比较Drone与Jenkins:

一、平台安装和管理
二、插件生态系统
三、Pipeline细节

最后，我会对Jenkins及Drone进行一个总体的比较。其实一般状况下，这样的对比并不会有一个明确的赢家。由于虽然这两者在本质上有一些相同之处，但不一样的工具仍然会有不一样的核心焦点。

前期准备

在开始以前，咱们须要先完成一些设置工做，包括将Drone设置为具备Github账户的受权Oauth2应用程序，这部分的工做能够参考Drone的官方技术文档。

在设置Drone时，我曾遇到过一个问题：Drone与源代码控制库之间是一种被动关系。这意味着Drone是经过与Github创建网络链接的方式来通知事件的。默认行为是创建在push和PR合并事件的基础上的。为使Github可以正确地通知Drone，服务器必须对全世界开放。固然，若是有其余内部供应链管理软件，状况可能会有所不一样，但这不适用于本文示例的状况。为此，我在GCE上设置了个人Rancher服务器，以便它能够从Github.com访问。

和其它Kubernetes应用程序同样，从容器中安装Drone须要经过一系列部署文件。我调整了在repo中找到的那些部署文件。在配置映射规范文件中，咱们须要修改若干值。也就是说，咱们须要为咱们的帐户设置特定的、与Github相关的值。咱们将从设置步骤中获取客户端密钥，并将密钥放入该文件以及受权用户的用户名中。经过Drone的密钥文件，咱们能够将Github密码置于适当处。

Jenkins与源代码的交互方式则与Drone的方式很不同。在Jenkins中，每一个做业均可以独立于另外一个做业来定义其与源控制的关系。如此一来，用户就能够从包括Github、Gitlab、svn等各类不一样的库中提取源代码。而截至目前，Drone只支持基于git的开发项。

与此同时，不要忘记了Kubernetes集群！Rancher能够轻松启动和管理Kubernetes集群。本文使用的是最新的稳定版Rancher 1.6。然而，Rancher 2.0与Rancher 1.6安装的信息和步骤是同样的，所以，若是您想尝试使用更新的Rancher也何尝不可。

任务1 - 安装和管理

在Kubernetes和Rancher上启动Drone，就像复制粘贴同样简单。使用默认的K8s仪表盘启动文件，从命名空间和配置文件开始依次上传，Drone就能够开始运行了。[您可在此找到部分我使用到的部署文件：https://github.com/appleboy/d...]。我从库中拉取了镜像并进行了本地的编辑。该repo属于Drone贡献者全部，包括有关如何启动GCE以及AWS的说明。咱们在这里惟一须要的只是Kubernetes的yaml文件。要进行复制，只需使用您的特定值编辑ConfigMap文件便可。个人其中一个文件的示例以下：

Jenkins也能够依此方式启动，因为它能够部署在Docker容器中，所以您能够构建一个相似的部署文件并在Kubernetes上启动。以下所示，该文件取自Jenkins CI服务器的GCE示例repo。

启动Jenkins也很简单。鉴于Docker和Rancher自身的简单易用性，若您想要启动Jenkins，只需将一组部署文件粘贴到仪表板中便可。个人首选方法是使用Kubernetes仪表板进行全部管理。能够逐个上传Jenkins文件，让服务器启动并运行。

Drone Server是经过在启动阶段设置的配置文件来进行管理的。它必须链接到Github，就意味着要访问库的话，须要添加OAuth2 token，以及（在本文示例中）须要用户名和密码。后期想要作修改，就须要经过Github授予组织访问权限，或者用新凭据来重启服务器。这么作不免会对开发工做带来影响，由于这意味着Drone不能处理多个源。而正如咱们前文提到的，Jenkins在这一方面会好一些，它容许任何数量的源repos，但要注意，每一个做业只能使用一个源。

任务2 - 插件

Drone插件的配置和管理很是简单。事实上，要成功启动一个Drone的插件，你须要作的事情并很少。与Jenkins相比，Drone的生态系统要小得多，但几乎全部可用的主要工具在Drone中都有插件可用。大多数主要的云提供商都有插件，而且与流行的源代码控制repo相集成。如前所述，能够将Drone容器视做“头等公民”，这意味着每一个插件和执行的任务都是一个容器。

Jenkins是毫无争议的插件之王。大多数状况下，没有什么任务是Jenkins的插件完成不了的。Jenkins插件的可选择范围很是广，可供使用的插件约有1000个，但有时难就难要在从一系列看上去类似的插件中肯定哪一个才是最佳选择。

Drone有用于构建push和镜像的docker插件，也有用于部署集群的AWS和K8s插件等各类插件。因为Drone平台推出的时间短，它的插件比Jenkins少得多。然而，这并不影响它们的有效性和易用性。drone.yml文件中的一个简单节无需其余输入就能自动下载、配置和运行选定的插件。此外，因为Drone与容器的关系，每一个插件都保存在一个镜像中，不须要再添加额外项进行管理。若是插件建立者完成了他们的工做, 全部的内容都将包含在该容器中，用户再无需管理任何依赖关系。

当我为简单节点应用程序构建drone.yml文件时，添加Docker插件很是简单，只须要几行代码，镜像就构建好了，并将其push到我选择的Dockerhub repo上。在下一节中，您能够看到标有docker的部分。本节是配置和运行插件以构建和推进Docker镜像所需的所有内容。

任务3

最终任务是任何CI系统的基础。Drone和Jenkins都旨在构建应用程序。最初，Jenkins是针对java应用程序构建的，但多年来，该范围已经扩展到任何能够编译和执行的代码。Jenkins甚至在新的管道和cron-job方面都游刃有余。然而，尽管它很是适合容器生态系统，但仍旧不是原生容器。

相比之下，这是同一应用的Jenkinsfile。

虽然这个例子解释起来很冗长，可是您能够看到，构建Docker镜像可能比Drone更复杂，并且还不包括Jenkins和Docker之间的交互。由于Jenkins不是原生Docker，因此必须提早配置代理以实现与Docker守护进程正确交互。 这可能会使人不解，但正是Drone的发展方向。Drone已经在Docker上运行了，它的任务也在同一Docker上运行。

结论

Drone是一款很棒的CI软件，而且正在成为时下流行的选择，若是您想要一个简单且能快速启动和运行的原生容器CI解决方案，Drone很是值得一试。虽然它仍处于预发布状态，不少工程师已经愿意而且在开始生产中尝试Drone了。在我看来，它占用内存小，使用简单，很适合在快速启动和运行方面有需求的小团队。

尽管Drone发展很快，但要撼动Jenkins在CI社区的根深蒂固的霸主地位仍需不少努力。Jenkins在适应市场方面一直很是成功，尤为是如今Blue Ocean和容器Pipeline为其CI界的领导性地位更加提供了强有力的支持。Jenkins能够适用于各类规模的团队并表现出色。因为其既往表现和众多整合因素，较大规模的组织更喜欢Jenkins。不论对开源社区，仍是经过CloudBees提供企业级支持，Jenkins都能提供不一样的支持选项。但与全部工具同样，Drone和Jenkins在CI生态系统中都有一席之地。