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，服務器必須對全世界開放

和其它Kubernetes應用程序一樣，從容器中安裝Drone需要通過一系列部署文件。我調整了在repo中找到的那些部署文件。在配置映射規範文件中，我們需要修改若幹值。也就是說，我們需要為我們的賬戶設置特定的、與Github相關的值。我們將從設置步驟中獲取客戶端密鑰，並將密鑰放入該文件以及授權用戶的用戶名中。通過Drone的密鑰文件，我們可以將Github密碼置於適當處。

Jenkins與源代碼的交互方式則與Drone的方式很不一樣。在Jenkins中，每個作業都可以獨立於另一個作業來定義其與源控制的關系。如此一來，用戶就可以從包括Github、Gitlab、svn等各種不同的庫中提取源代碼

與此同時，不要忘記了Kubernetes集群！Rancher可以輕松啟動和管理Kubernetes集群。本文使用的是最新的穩定版Rancher 1.6。然而，Rancher 2.0與Rancher 1.6安裝的信息和步驟是一樣的，因此，如果您想嘗試使用更新的Rancher也未嘗不可。

在Kubernetes和Rancher上啟動Drone，就像復制粘貼一樣簡單。使用默認的K8s儀表盤啟動文件，從命名空間和配置文件開始依次上傳，Drone就可以開始運行了。[您可在此找到部分我使用到的部署文件：https://github.com/appleboy/drone-on-kubernetes/tree/master/gke]。我從庫中拉取了鏡像並進行了本地的編輯。該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，但要註意，每個作業只能使用一個源。

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鏡像所需的全部內容。

最終任務是任何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生態系統中都有一席之地。

如何選擇最佳CI工具：Drone VS. Jenkins