雲上自動化:全球雲上自動化編排系統比拼

程式猿da哥發表於2018-09-28

、領域 澄清

首先明確我們在講什麼,也就是本文描述的應用編排,資源編排是什麼東西。

在雲上編排的含義一般有兩種:

1.雲平臺上自動化建立雲服務,並部署應用。叫做資源編排or應用編排or服務編排。

2. 容器應用,根據資源要求,排程到哪個節點上。叫做容器編排or資源排程。

本文描述範圍,為第1種。

雲上自動化:全球雲上自動化編排系統比拼

公有云編排 服務 介紹

AWS  Cloudformation

Cloudformation文件地址:

AWS的Cloudformation基本屬於雲上自動化(編排)這個領域的領頭羊,功能完備,支援的自動化場景豐富。

在整體生態打造的也很成功,Cloudformation模板,與ServiceCatalog服務目錄,與Marketplace應用市場,一條線從上到下都打通了。


谷歌 CDM: (Cloud Deployment Manager)

谷歌CDM文件地址:

使用Jinja2語法(Yaml類)和Python語法,實現較為討巧。大部分操作,主推透過命令列完成。雖然控制檯介面也有,但功能主要在命令列裡(意思是介面比較low)。

谷歌CDM支援編排資源列表:


微軟 Azure-RM Resource Manager)

Azure-RM文件地址:

使用Json語法。且整體模板語法偏複雜,使用門檻比較其他家的還高一點。

有兩個比較有特點的功能:

1.支援根據使用者已經在Azure上建立好的資源資訊,匯出模板。實現類似的“備份”or“快照”的功能。

2.支援任意物件,指定重複建立次數。實現批次複製的能力。

Azure-RM編排提供的內建函式非常豐富:


阿里 ROS

ROS文件地址:

整體能力跟隨AWS Cloudformation,但是還略有距離。視覺化模板編輯器,目前並不是很穩定,使用體驗一般。

ROS支援編排的資源列表:


Open S tack  Heat

Heat文件地址:

整體能力跟隨AWS Cloudformation,搞了一些Cloudformation語法相容的活,連cfn-tools都照著AWS來。但是目前還略有距離。

也沒有圖形化設計器。

Heat可以編排的資源列表:


華為 AOS

AOS文件地址:

https://support.huaweicloud.com/usermanual-aos/aos_01_0000.html

使用以應用視角為中心的編排,支援Kubernetes叢集中的物件編排,並圍繞應用支援編排基礎資源+服務。與AWS的Cloudformation相比,發力角度從虛機應用轉向容器應用。

圖形化的模板設計器,體驗很好。特別是智慧輔助對於編寫模板確實很便捷。可以稱作領域標杆。

AOS支援編排物件列表:

https://support.huaweicloud.com/tr-aos/aos_01_4013.html


K8S Helm

Helm文件地址:

Helm其實自己定位並不是編排,而是一個K8S的manifest包管理工具。不過它有自動化部署K8S物件的能力,所以加入比較。

特點是隻認識K8S叢集裡面的物件,基礎的雲服務不支援編排。使用範圍有限。


青雲 RO

RO(Resources Orchestration)文件地址:

青雲的資源編排特點是,不開放模板語法,只提供圖形化設計器。

並且這個圖形化設計器體驗還不錯,有所見即所得的感覺。

但是由於沒有開放模板語法,只靠圖形化設計器,複雜場景編排能力不足。

雲上自動化:全球雲上自動化編排系統比拼


RedHat  Ansible

Red Hat在2015年收購Ansible,並用在OpenShift裡面作為編排服務。

Ansible定位是基於虛機的自動化運維管理工具,類似的系統還有Chef和Puppet。不過Ansible的特點是無需在目標機器上安裝Agent,僅使用SSH遠端執行命令就可以完成目標機器的軟體安裝配置,所以很容易在已有環境中使用。它的本質上是一個工具,而不是一個服務,因為它使用本地目錄+檔案的方式來管理“模板”。

雲上自動化:全球雲上自動化編排系統比拼

語法使用Yaml語言,可以和Jinja2配合,方便表達出複雜的邏輯。

不過Ansible只支援任務按順序單個依次執行,也就是無法設定複雜的有向無環圖(DAG)依賴關係。

所以對流程的編排能力弱了點,但好在支援的物件數量非常豐富,有超過400多種外掛。


騰訊無

雲上自動化能力是一個雲平臺的剛需,這裡一首涼涼送給騰訊雲。。。


公有云編排 服務對比

我們直接給出分析結果,省去囉嗦的文字。(文字時效原因,如果有不正確的,及時聯絡更正哈)


編排 能力對比

 √表示“強/做得好”,O表示“一般/待增強”,X表示“沒有此特性”。 

雲上自動化:全球雲上自動化編排系統比拼

設計器 能力對比

 √表示“強/做得好”,O表示“一般/待增強”,X表示“沒有此特性”。

雲上自動化:全球雲上自動化編排系統比拼

一張圖對比

雲上自動化:全球雲上自動化編排系統比拼

總結

亞馬遜CFN與阿里 ROS

阿里的ROS的定位與AWS的CFN是一致的,功能上也是瞄著CFN追趕。當前情況為:ROS在虛機應用的支援能力遠不及AWS-CFN。不過這個cfn-tools也是AWS的殺手鐧,各大雲廠商都沒有。只有Heat做了一些努力去相容。

ROS的設計器能力需要增強。目前功能較弱,且在使用中有偶現異常。


亞馬遜CFN 華為 AOS

    從功能&語法層面,CFN與AOS基本屬於第一陣營,各自互有領先。比如AOS在設計器上領先CFN。不過CFN在虛機應用,及複雜多服務組合場景下,領先AOS。所以AOS需要在後續用更多的場景去進一步催熟。


阿里ROS 華為 AOS

ROS在虛機應用部署,及可編排服務的多樣性上優於AOS。而AOS在容器應用相關的能力上優於ROS。圖形化模板編輯器能力則是AOS大幅度領先。


青雲

設計器所見即所得的方式,大幅降低使用門檻,使用者體驗很好。建議將模板語法儘快開放出來,因為編排僅靠圖形化設計器,支援的場景有限。


騰訊雲

雲平臺上居然沒有編排服務,畢竟目前為止,所有公有云都有的剛需服務。希望騰訊雲的技術專家回家好好反省,並儘快補齊這個必備的能力。(比如挖一些華為AOS的專家,你看天下武功出少林,中國容器看華為,都一家人嘛)


微軟 Azure

微軟的模板使用Json語法,函式的使用是混雜在Json內部,並不像aws-cfn那麼簡潔,整體體驗並不好。感覺把複雜度都提高了很多。

當然,天然的Visual Studio編輯器支援,是編寫模板一個便捷之處。Infrastructureas Code嘛,寫程式碼當然有好的IDE才行。


谷歌CDM

CDM(CloudDeployment Manager)使用了jinja2和Python作為模板語法,使得模板覆蓋複雜場景的能力大大增強,算一種優勢吧。

然而沒有合適的UI介面,我想你太不懂國人了。


Helm

語法層面的能力OK,足夠支撐在單個K8S叢集中,各種k8s物件的複雜編排場景。自身定位為K8S上的管理工具,一般不作為公有云獨立服務,僅為容器服務的附屬功能。

沒有圖形化設計器,也不能將基礎資源與K8S物件混合編排。目前進入CNCF的孵化專案,作為K8S生態一環。


OpenStack Heat

定位是與AWS的Cloudformation一致的,實際編排能力與效果與ROS相似,也就是與CFN還有些差距。根據CFN語法和能力做了很多相容工作。

沒有圖形化設計器,主要側重OpneStack物件or生態的編排,其他服務支援一般。屬於OpenStack生態一環。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31548113/viewspace-2215179/,如需轉載,請註明出處,否則將追究法律責任。

相關文章