【下一代核心技術DevOps】:(一)容器服務的Rancher選型

元始天尊門下皮皮蝦發表於2017-12-14
  1. 為什麼說是下一代核心技術

         其實經過網際網路的多次變革說起,早期的C/S架構,到後來的B/S架構,一直到現在最普遍的M/S架構,他們的背後都是技術不斷的優化改進,以適應促進IT技術的發展

         整體而言在過去10年時間,網際網路技術可以說是以手工製造的方式為準,類似於傳統銷售,設計,製作,然後打包銷售。每個環節都需要大量的人員來操作,也需要不斷

         有人接班學習來延續對應的環節。而未來10年將會是以流水線的方式為主 ,其主要原因是網際網路雲端計算技術的高速發展及可持續快速交付的業務需求。其對應的DevOps

         方式將完美契合。開發運維一體化確切的說是一種方式,而這種方式需要全新的技術來支撐才行執行下去,我們將之稱為下一代核心技術。

 

         2. 傳統技術與下一代核心技術區別

         傳統的技術主要問題是高耦合,其耦合存在於伺服器,硬體儲存,內外網之間(網路通訊),應用程式之間,程式碼之間,業務模組之間,雖然經過近幾年的發展,在不斷的

         去耦合化大趨勢下,已經儘可能的將這幾大塊之間進行低耦合處理,但是由於傳統技術的限制,無法從根本上解決這些問題。比如最常用的程式連線資料庫。傳統的方式多

          將資料庫連線字串寫到程式的配置檔案裡,導致其連線資料庫IP不能變,多節點部署程式需要一一手動修改資料庫連線字串。非常麻煩,隨著技術的發展優化,有經驗的

          研發人員會將資料庫連線放到JNDI裡面(如Tomcat),由中介軟體管理,這樣將程式和資料庫之間進行解耦。這也是傳統技術,架構常用的做法。但是對於多節點的部署變更,

          需要改變多個節點Tomcat的JNDI配置,還是存在易用性,可維護性,可靠性方面的問題。當然也有高階別的中介軟體來集中解決這些問題,如WebSphere的叢集管理,這都屬於

          為了解決問題而解決問題,受限於傳統技術,無法從根因上解決各個元件,軟硬體之間的耦合問題。而且需要商業付費,非常的貴。

           下一代核心技術,受益於雲端計算,微服務,容器服務的高速發展,採取DevOps的模式進行整合,實現硬體伺服器,儲存,網路,軟體程式,程式碼之間的全低耦合甚至0耦合

           將大大提高交付能力,降低運維成本,實現網際網路產品的快速迭代。

 

            3. 容器服務的Rancher選型

           我之前的文章已經對微服務做了基本分析,本章節及後續章節會陸續對雲端計算的分析應用和容器服務的分析應用做逐一的講解。 微服務主要是對軟體程式碼層面進行解耦,

           雲端計算主要從硬體支撐層進行解耦,而容器服務主要從應用層面進行解耦。容器服務的飛速發展,主要是Docker的巨大功勞,將傳統的虛擬化技術帶到一個全新的層面。

           Docker的優勢在此不做多講,主要是其原生的管理基於命令列,對於簡單應用較為方便。但是在DevOps模式下就需要有一整套的規範介面來統一管理整個流水線。對於

           Docker容器的管理系統目前比較流行的有幾個: K8S,Rancher,Shipyard等,其他還有一些不是很有名的在此不多做列舉了,大家可以自行研究學習。

內容   原生             K8s               Rancher  Shipyard
管理端及易用性 Docker EE (易用性★★★) K8s管理(易用性★★) Rancher(易用性★★★★☆) (易用性★★★★)
引擎/編排工具 Swarm Kubernetes

Cattle、Swarm、Kubernetes、Mesos,Windows

多主(叢集) 支援 支援 支援 不支援
資源看板 ★★★ ★★ ★★★★
DevOps整合 不支援 外掛支援 外掛支援、原生支援 不支援
外掛數量 ★★★ ★★★★ 不支援

          經過對比試用選型,在容器管理考慮到易用性包括跨主機通訊的管理,DevOps的支援力度等方面,Rancher以各方面優先勝出。Rancher目前在開源社群非常火爆,支援眾多

          的編排引擎,當前最新版本為 1.6.12  ,大家可以下載試用。

相關文章