如何选择最佳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:
1、平台安装和管理
2、插件生态系统
3、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生态系统中都有一席之地。