1、升級
這個其實大家都可以想到，容器最大的特點，就是升級。企業使用OpenStack，最大的一個顧慮，就是升級。尤其在OpenStack 1年兩個版本下，不斷的有新的功能的需求的情況下，如果不能升級，其實是很痛苦。尤其在企業的迅速發展的過程中。
容器化的OpenStack，升級有多么簡單呢?其實就是刪掉容器，換上新的容器，用戶基本是無感知的狀態下完成。
升級子所以很困難，有一個很現實的原因，線上環境，很難模擬，升級驗證測試很難進行。當采用容器化以后，我們很容易模擬出一個線上環境，進行升級測試，升級失敗，回滾。其實這些都做的很漂亮。
2、靈活
以前廠商的解決方案，都是3個控制節點，如果我希望增加到5個控制節點，或者把控制節點某個服務單獨部署，那么這個基本是很難完成的任務。
以前廠商都廠商把OpenStack的各個服務放到虛擬機里，這樣部署靈活性提高不少。但是虛擬機還是很重，面對客戶千百萬化的需求，就有點無能為力。
舉一個例子
企業基本節點，我規模很小，可能就只有幾臺機器，這時候，我可能不需要控制節點高可用，我就需要1個控制節點，管理機柜計算節點。
隨著時間的發展，希望擴大規模，控制節點變成高可用。
規模進一步擴大，我就需要把消息隊列單獨出來部署，解決性能的問題。
這種需求，很實在，OpenStack廠商也在努力滿足企業的這些需求，其實Mirantis的Fuel，已經在很多程度，滿足了企業這種需求，不過代價很大。
對于容器化的OpenStack，就變得很簡單，無非就是調整各個節點的容器分布，編排的問題。控制節點是3個，還是五個，RabbitMQ放在什么位置，根本就不是問題。
3、配置管理
OpenStack過去使用最廣的配置管理工具是Puppet，對于企業用戶來說，這個是很難掌控的。其實在國內，就算是互聯網公司，負責Puppet的運維人員離職，其實都是很難招聘回來相應的人員。
對于OpenStack廠商來說，要想完全掌控Puppet，還是很困難的。更別說，要滿足各種靈活的需求。
配置管理工具，其實Salt和Ansible，是Python開發，比較易用，不過在OpenStack的生態圈里，不如Puppet強大，很難超越Puppet。
容器化后的OpenStack，配置管理工具，或者編排的工具，就很多選擇，Ansible、Slat、Kubernetes，都是可以支持。你就不需要受Ruby的折磨。
其實這也是大大降低企業掌控OpenStack難度。
4、操作系統廠商依賴
廠商都在宣傳所謂沒有廠商綁定。其實你用了紅帽的OpenStack，要想換到Ubuntu下，不是不可能，其實肯定很痛苦。如果要換成Suse，難度就更高。
各種配置管理工具，其實都是依賴發行版的包管理。國內的銀行其實都使用Suse。但是社區的Puppet工具不支持Suse。或者我希望玩的項目，操作系統發行版沒有提供包，怎么辦?
容器化的OpenStack。其實理論上，可以跑在任何支持容器的操作系統上。內核的版本高，無非就是性能更好一點。其實你只需要做點測試，就可以實現這種跨操作系統的部署。
容器里，可以使用RPM包，Deb包，也是可以跑源碼安裝，這樣其實對于操作系統廠商來說，基本就沒任何的依賴。不受制操作系統廠商。
5、軟件依賴
OpenStack項目的增多，軟件互相依賴的問題，越來越嚴重。因為OpenStack很多項目是需要使用外部項目，例如Ceph，他的依賴很可能和OpenStack組件的依賴產生沖突。
這種問題，可以解決，但是解決，沒任何的意義和技術含量，很讓技術人員抓狂。其實發行版都在投入大量的精力去解決各個軟件包的互相依賴的問題。
容器化的OpenStack，很好的解決了這個問題。
6、部署時間
在生產環境中，部署時間1個小時，和一天，其實區別不大，畢竟部署是一次性的工作。對于測試來說，就完全不一樣。如果我10分鐘可以完成一次部署，可以測試驗證的東西，和幾個小時才能完成一次的部署，差異還是很大的。
容器化OpenStack，大大加快了部署的時間，通常10分鐘，就可以完成一次完整功能的部署，驗證OpenStack各種新功能的代價，就大大減少。
7、顯得簡單
OpenStack在企業的實際使用中，都是抱怨太復雜，這其實也是因為OpenStack，松耦合，功能強大，同時也讓用戶感覺很復雜。尤其在出現錯誤的時候，很無奈。
容器化后，用戶感覺OpenStack各個組件，就類似累積木一樣，搭建起來，可以根據自己的需求，選擇哪個模塊。感覺自己是可控的。你可以很方便的裝上某個模塊，不滿意，刪掉。背后的復雜的邏輯，社區已經幫你完善。
遇到問題，尋求幫助，也顯得簡單很多。因為大家容器里的東西都是一樣的，無非就是外面的配置文件。
也只要讓企業感覺自己可以掌控OpenStack，這樣OpenStack才會大量的進入企業的IT系統。這個時候，無論是采用外包還是自己運維。
8、計算節點HA
如果實現計算節點掛掉后，上面的虛擬機自動在別的節點啟動起來。這個問題解決的辦法，其實有很多，解決的難點，就在于我如何判斷這臺節點真的掛掉。因為虛擬機的遷移的東西，是很大的，必須很小心。也很容易造成誤判。
海云捷迅提出一個使用Consul的解決方案，就是一個容器里做健康檢查的組件，放到OpenStack計算節點，類似peer-to-peer，互相檢查。
當容器化的OpenStack后，那么就可以利用容器強大社區，各種的實現方式，第一時間知道節點失效。肯定你也是可以使用Consul來解決這個問題，更加直接。
9、監控和日志分析
OpenStack一直都在完善自己的監控日志分析。不過進展并不太好。容器化的OpenStack，面臨的監控，日志的問題，和以前的OpenStack有很大差異。
不過不得不承認，容器的世界里，這方面非常完善，太多選擇，可以幫助你解決監控和日志分析的問題。
可以利用強大的Docker社區，來完善OpenStack短板的地方。
10、創新
容器化后的OpenStack，其實帶來很多意想不到的創新和變化。很多以前很炫的概念，慢慢走向現實。
OpenStack一個版本的發行周期大概是分為B1、B2、B3，每個階段大概45天，后續就發布RC，正式版本。
以往OpenStack公司都是等到一個版本正式發布后，進行打包，測試，驗證，經過3個月和半年，正式對外發布。那么這種發布周期，其實已經有點跟不上OpenStack的步伐。例如Mitaka版本發布的時候，紅帽的Liberty版本才正式對外發布。
能不能做到，OpenStack一邊開發，發行版也在同步進行打包，測試呢?其實在OpenStack發展初期，有人提出這樣的建議，不過對操作系統廠商來說，代價太大，不愿意去做。
有了容器化以后，完全不需要依賴操作系統的打包，我可以根據自己的需求，進行build image，測試，這樣我的產品的發布周期，就會大大縮短。
總結
OpenStack上的很多問題，都是可以解決，只是解決起來很費勁，容器化，解決就顯得很優雅。有強大的Docker社區，你解決問題的方法，方式就更多。
京公網安備 11010502049343號