1、升級(jí)

這個(gè)其實(shí)大家都可以想到，容器最大的特點(diǎn)，就是升級(jí)。企業(yè)使用OpenStack，最大的一個(gè)顧慮，就是升級(jí)。尤其在OpenStack 1年兩個(gè)版本下，不斷的有新的功能的需求的情況下，如果不能升級(jí)，其實(shí)是很痛苦。尤其在企業(yè)的迅速發(fā)展的過(guò)程中。

容器化的OpenStack，升級(jí)有多么簡(jiǎn)單呢?其實(shí)就是刪掉容器，換上新的容器，用戶基本是無(wú)感知的狀態(tài)下完成。

升級(jí)子所以很困難，有一個(gè)很現(xiàn)實(shí)的原因，線上環(huán)境，很難模擬，升級(jí)驗(yàn)證測(cè)試很難進(jìn)行。當(dāng)采用容器化以后，我們很容易模擬出一個(gè)線上環(huán)境，進(jìn)行升級(jí)測(cè)試，升級(jí)失敗，回滾。其實(shí)這些都做的很漂亮。

2、靈活

以前廠商的解決方案，都是3個(gè)控制節(jié)點(diǎn)，如果我希望增加到5個(gè)控制節(jié)點(diǎn)，或者把控制節(jié)點(diǎn)某個(gè)服務(wù)單獨(dú)部署，那么這個(gè)基本是很難完成的任務(wù)。

以前廠商都廠商把OpenStack的各個(gè)服務(wù)放到虛擬機(jī)里，這樣部署靈活性提高不少。但是虛擬機(jī)還是很重，面對(duì)客戶千百萬(wàn)化的需求，就有點(diǎn)無(wú)能為力。

舉一個(gè)例子

企業(yè)基本節(jié)點(diǎn)，我規(guī)模很小，可能就只有幾臺(tái)機(jī)器，這時(shí)候，我可能不需要控制節(jié)點(diǎn)高可用，我就需要1個(gè)控制節(jié)點(diǎn)，管理機(jī)柜計(jì)算節(jié)點(diǎn)。

隨著時(shí)間的發(fā)展，希望擴(kuò)大規(guī)模，控制節(jié)點(diǎn)變成高可用。

規(guī)模進(jìn)一步擴(kuò)大，我就需要把消息隊(duì)列單獨(dú)出來(lái)部署，解決性能的問(wèn)題。

這種需求，很實(shí)在，OpenStack廠商也在努力滿足企業(yè)的這些需求，其實(shí)Mirantis的Fuel，已經(jīng)在很多程度，滿足了企業(yè)這種需求，不過(guò)代價(jià)很大。

對(duì)于容器化的OpenStack，就變得很簡(jiǎn)單，無(wú)非就是調(diào)整各個(gè)節(jié)點(diǎn)的容器分布，編排的問(wèn)題?？刂乒?jié)點(diǎn)是3個(gè)，還是五個(gè)，RabbitMQ放在什么位置，根本就不是問(wèn)題。

　　3、配置管理

OpenStack過(guò)去使用最廣的配置管理工具是Puppet，對(duì)于企業(yè)用戶來(lái)說(shuō)，這個(gè)是很難掌控的。其實(shí)在國(guó)內(nèi)，就算是互聯(lián)網(wǎng)公司，負(fù)責(zé)Puppet的運(yùn)維人員離職，其實(shí)都是很難招聘回來(lái)相應(yīng)的人員。

對(duì)于OpenStack廠商來(lái)說(shuō)，要想完全掌控Puppet，還是很困難的。更別說(shuō)，要滿足各種靈活的需求。

配置管理工具，其實(shí)Salt和Ansible，是Python開(kāi)發(fā)，比較易用，不過(guò)在OpenStack的生態(tài)圈里，不如Puppet強(qiáng)大，很難超越Puppet。

容器化后的OpenStack，配置管理工具，或者編排的工具，就很多選擇，Ansible、Slat、Kubernetes，都是可以支持。你就不需要受Ruby的折磨。

其實(shí)這也是大大降低企業(yè)掌控OpenStack難度。

4、操作系統(tǒng)廠商依賴

廠商都在宣傳所謂沒(méi)有廠商綁定。其實(shí)你用了紅帽的OpenStack，要想換到Ubuntu下，不是不可能，其實(shí)肯定很痛苦。如果要換成Suse，難度就更高。

各種配置管理工具，其實(shí)都是依賴發(fā)行版的包管理。國(guó)內(nèi)的銀行其實(shí)都使用Suse。但是社區(qū)的Puppet工具不支持Suse?；蛘呶蚁Ｍ娴捻?xiàng)目，操作系統(tǒng)發(fā)行版沒(méi)有提供包，怎么辦?

容器化的OpenStack。其實(shí)理論上，可以跑在任何支持容器的操作系統(tǒng)上。內(nèi)核的版本高，無(wú)非就是性能更好一點(diǎn)。其實(shí)你只需要做點(diǎn)測(cè)試，就可以實(shí)現(xiàn)這種跨操作系統(tǒng)的部署。

容器里，可以使用RPM包，Deb包，也是可以跑源碼安裝，這樣其實(shí)對(duì)于操作系統(tǒng)廠商來(lái)說(shuō)，基本就沒(méi)任何的依賴。不受制操作系統(tǒng)廠商。

5、軟件依賴

OpenStack項(xiàng)目的增多，軟件互相依賴的問(wèn)題，越來(lái)越嚴(yán)重。因?yàn)镺penStack很多項(xiàng)目是需要使用外部項(xiàng)目，例如Ceph，他的依賴很可能和OpenStack組件的依賴產(chǎn)生沖突。

這種問(wèn)題，可以解決，但是解決，沒(méi)任何的意義和技術(shù)含量，很讓技術(shù)人員抓狂。其實(shí)發(fā)行版都在投入大量的精力去解決各個(gè)軟件包的互相依賴的問(wèn)題。

容器化的OpenStack，很好的解決了這個(gè)問(wèn)題。

6、部署時(shí)間

在生產(chǎn)環(huán)境中，部署時(shí)間1個(gè)小時(shí)，和一天，其實(shí)區(qū)別不大，畢竟部署是一次性的工作。對(duì)于測(cè)試來(lái)說(shuō)，就完全不一樣。如果我10分鐘可以完成一次部署，可以測(cè)試驗(yàn)證的東西，和幾個(gè)小時(shí)才能完成一次的部署，差異還是很大的。

容器化OpenStack，大大加快了部署的時(shí)間，通常10分鐘，就可以完成一次完整功能的部署，驗(yàn)證OpenStack各種新功能的代價(jià)，就大大減少。

7、顯得簡(jiǎn)單

OpenStack在企業(yè)的實(shí)際使用中，都是抱怨太復(fù)雜，這其實(shí)也是因?yàn)镺penStack，松耦合，功能強(qiáng)大，同時(shí)也讓用戶感覺(jué)很復(fù)雜。尤其在出現(xiàn)錯(cuò)誤的時(shí)候，很無(wú)奈。

容器化后，用戶感覺(jué)OpenStack各個(gè)組件，就類(lèi)似累積木一樣，搭建起來(lái)，可以根據(jù)自己的需求，選擇哪個(gè)模塊。感覺(jué)自己是可控的。你可以很方便的裝上某個(gè)模塊，不滿意，刪掉。背后的復(fù)雜的邏輯，社區(qū)已經(jīng)幫你完善。

遇到問(wèn)題，尋求幫助，也顯得簡(jiǎn)單很多。因?yàn)榇蠹胰萜骼锏臇|西都是一樣的，無(wú)非就是外面的配置文件。

也只要讓企業(yè)感覺(jué)自己可以掌控OpenStack，這樣OpenStack才會(huì)大量的進(jìn)入企業(yè)的IT系統(tǒng)。這個(gè)時(shí)候，無(wú)論是采用外包還是自己運(yùn)維。

　　8、計(jì)算節(jié)點(diǎn)HA

如果實(shí)現(xiàn)計(jì)算節(jié)點(diǎn)掛掉后，上面的虛擬機(jī)自動(dòng)在別的節(jié)點(diǎn)啟動(dòng)起來(lái)。這個(gè)問(wèn)題解決的辦法，其實(shí)有很多，解決的難點(diǎn)，就在于我如何判斷這臺(tái)節(jié)點(diǎn)真的掛掉。因?yàn)樘摂M機(jī)的遷移的東西，是很大的，必須很小心。也很容易造成誤判。

海云捷迅提出一個(gè)使用Consul的解決方案，就是一個(gè)容器里做健康檢查的組件，放到OpenStack計(jì)算節(jié)點(diǎn)，類(lèi)似peer-to-peer，互相檢查。

當(dāng)容器化的OpenStack后，那么就可以利用容器強(qiáng)大社區(qū)，各種的實(shí)現(xiàn)方式，第一時(shí)間知道節(jié)點(diǎn)失效。肯定你也是可以使用Consul來(lái)解決這個(gè)問(wèn)題，更加直接。

9、監(jiān)控和日志分析

OpenStack一直都在完善自己的監(jiān)控日志分析。不過(guò)進(jìn)展并不太好。容器化的OpenStack，面臨的監(jiān)控，日志的問(wèn)題，和以前的OpenStack有很大差異。

不過(guò)不得不承認(rèn)，容器的世界里，這方面非常完善，太多選擇，可以幫助你解決監(jiān)控和日志分析的問(wèn)題。

可以利用強(qiáng)大的Docker社區(qū)，來(lái)完善OpenStack短板的地方。

10、創(chuàng)新

容器化后的OpenStack，其實(shí)帶來(lái)很多意想不到的創(chuàng)新和變化。很多以前很炫的概念，慢慢走向現(xiàn)實(shí)。

OpenStack一個(gè)版本的發(fā)行周期大概是分為B1、B2、B3，每個(gè)階段大概45天，后續(xù)就發(fā)布RC，正式版本。

以往OpenStack公司都是等到一個(gè)版本正式發(fā)布后，進(jìn)行打包，測(cè)試，驗(yàn)證，經(jīng)過(guò)3個(gè)月和半年，正式對(duì)外發(fā)布。那么這種發(fā)布周期，其實(shí)已經(jīng)有點(diǎn)跟不上OpenStack的步伐。例如Mitaka版本發(fā)布的時(shí)候，紅帽的Liberty版本才正式對(duì)外發(fā)布。

能不能做到，OpenStack一邊開(kāi)發(fā)，發(fā)行版也在同步進(jìn)行打包，測(cè)試呢?其實(shí)在OpenStack發(fā)展初期，有人提出這樣的建議，不過(guò)對(duì)操作系統(tǒng)廠商來(lái)說(shuō)，代價(jià)太大，不愿意去做。

有了容器化以后，完全不需要依賴操作系統(tǒng)的打包，我可以根據(jù)自己的需求，進(jìn)行build image，測(cè)試，這樣我的產(chǎn)品的發(fā)布周期，就會(huì)大大縮短。

總結(jié)

OpenStack上的很多問(wèn)題，都是可以解決，只是解決起來(lái)很費(fèi)勁，容器化，解決就顯得很優(yōu)雅。有強(qiáng)大的Docker社區(qū)，你解決問(wèn)題的方法，方式就更多。