Jenkins X 還是 2.0?

Jenkins X 還是 2.0?

近期發佈的Jenkins X在開源界備受關注。在這篇文章裡,我將探討新產品裡一些吸引人的功能,這些功能尚未在文檔裡被特別提及。如果你需要一個產品指南或者其他類型的說明文檔,我強烈建議閱讀一下動機和功能文檔。

它只是一個新的炒作工具嗎?在容器裡運行Jenkins有什麼特別之處嗎?

Kubernetes已然是管理容器,分佈式應用以及虛擬基礎設施的事實標準。主流的公有云廠商都有提供它的託管服務,而且可以按需在本地安裝。如果用戶今天構建了一個雲應用並且希望它可以在任何地方運行,那麼Kubernetes會是你的選擇!

儘管Kubernetes的生態系統很龐大,它仍然非常年輕而且把更多精力放在處理“第一階段”的挑戰上,比如Kubernetes的推廣。首先解決最緊迫的問題是很自然的事情。可以預見的是2018年Kubernetes將給用戶帶來更多的穩定性,集成度和用戶體驗方面的提升。今天,在這裡我們考慮一下第二階段的操作,如何在其之上構建一些東西,並且使開發人員的工作效率更高。

Jenkins X在這塊填補了整體CI/CD管理的空白。

它只是Jenkins 2.0的一次品牌重塑嗎?

Jenkins是一款在雲成為標準之前就已經開發出來的工具,它絕對不是雲原生工具,這意味著它不能夠開箱即用(OOTB)的抗衡停機,無縫擴展等。

幸運的是,它是可擴展的。 Jenkins X通過Kubernetes插件演繹了一場魔術,它使得你不必再為slave配備虛擬機或者物理服務器;每個作業使用一次性代理,運行在不同的容器中,這些容器可以隨集群一起擴展。

通過Jenkins X,你不僅可以獲得面向應用程序的Kubernetes流水線,還可以獲得可擴展的CI/CD解決方案。

Jenkins X 還是 2.0?

你能為我們團隊安裝Jenkins嗎?

當Kubernetes以一個項目平臺的形式提供時,這是開發團隊最常見的問題。對組織而言,遷移主要工具往往意味著大量的變更;從字面上看,它會影響所有主要的DevOps流程,並且需要花費大量的學習精力。

Jenkins X與Kubernetes流水線,代理以及集成一起提供了一種更簡單的遷移到Kubernetes和微服務的方式。

版本控制怎麼做?

Jenkins X採用了GitOps概念。

保持版本控制中的所有配置意味著更高的安全性,災難恢復以及將所有軟件開發生命週期(SDLC)實踐應用於運維任務的可能性。

開箱即用,將CI/CD基礎架構配置保存到Git中,並且工具包始終遵循該原則。

即便是一些緊急情況,用戶也無法僭越這一規則,設計就是這樣的!

構建塊

Jenkins2.0 :"老牌好用"的CI服務器

Helm:包管理器

Draft:開發環境構建工具

Monocular:Helm倉庫的UI

Chartmuseum:帶有云後端支持的Helm倉庫

Nexus:資料庫

Docker registry:容器鏡像中心

以上所有內容均受jx工具的控制,並且配置以一個個的“平臺”,一組Helm圖的形式發佈。

Jenkins X 還是 2.0?

全新視角下的環境管理

這是我最感興趣的功能之一!

環境作為一個實體交由工具控制,你可以管理生命週期,升級(promote)和配置! 你可以輕鬆地自定義,模板和重用它。

它使用的是GitOps模式,並且每個環境都有一個存儲庫。這是一個最佳實踐,由jx驅動OOTB。

Helm用於配置管理。 環境被表示為一個Helm包,每個應用程序都被添加為一個依賴項,同時可以升級(promote)。這種做法很有意義,因為環境配置是最不標準的地方。很多團隊花了很多時間,直到我找到類似的東西。 而你完全是免費獲取的!

瑞士軍刀般的CLI

Jx CLI是該框架所有功能的入口點。

最重要的是:這是一個關鍵結構,在CD管道中被廣泛使用。 它們可以很容易地直接播放和調試,任何步驟都可以通過CLI循環和重放。


分享到:


相關文章: