如何選擇最佳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生態系統中都有一席之地。