您好,登錄后才能下訂單哦!
這篇文章主要介紹“Drone與Jenkins舉例分析”,在日常操作中,相信很多人在Drone與Jenkins舉例分析問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”Drone與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帳戶的授權Oauth3應用程序,這部分的工作可以參考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也未嘗不可。
在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,就意味著要訪問庫的話,需要添加OAuth3 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與Jenkins舉例分析”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。