2016年OpenStack中國峰會，最大的一個感受就是廠商都在做容器化OpenStack。這已經是一個不可逆轉的勢頭。

　　Mirantis的Fuel也要實現容器化OpenStackCanonical的Ubuntu OpenStack，通過LXD實現容器化Rackspace通過LXC實現容器化OpenStack，已經投入生產紅帽已經開始驗證OpenStack計算節點的容器化。

　　國內的廠商。其實應該都在做，公開的就是海云捷迅，九州云，麒麟三家。對于容器公司來說，可以選擇很多方式來玩，搞OpenStack是一件錦上添花的事情。對于OpenStack廠商來說，搞容器，可是生死攸關的事情。

　　技術實現

　　容器化的OpenStack實現，其實都差不多，就看各家誰更加徹底，更加優雅，更加安全。所謂徹底，就是完全對操作系統是免疫的，把容器刪掉后，操作系統就好像沒操作過一樣。

　　一般來說都是

　　build各種服務的docker 鏡像。利用工具進行編排，對鏡像分發，把鏡像啟動起來。

　　有些廠商僅僅是把控制節點容器化。對于kolla項目來說，是把OpenStack和周邊項目全部容器化

　　cephqemulibvirt

　　這些都容器化，甚至在討論NTP服務，也需要進行容器化。

　　Kolla項目 https://github.com/openstack/kolla

　　廠商把OpenStack容器化，會帶來哪些好處呢？

　　升級

　　這個其實大家都可以想到，容器最大的特點，就是升級。企業使用OpenStack，最大的一個顧慮，就是升級。尤其在OpenStack1年兩個版本下，不斷的有新的功能的需求的情況下，如果不能升級，其實是很痛苦。尤其在企業的迅速發展的過程中。

　　容器化的OpenStack，升級有多么簡單呢？其實就是刪掉容器，換上新的容器，用戶基本是無感知的狀態下完成。

　　升級子所以很困難，有一個很現實的原因，線上環境，很難模擬，升級驗證測試很難進行。當采用容器化以后，我們很容易模擬出一個線上環境，進行升級測試，升級失敗，回滾。其實這些都做的很漂亮。

　　靈活

　　以前廠商的解決方案，都是3個控制節點，如果我希望增加到5個控制節點，或者把控制節點某個服務單獨部署，那么這個基本是很難完成的任務。

　　以前廠商都廠商把OpenStack的各個服務放到虛擬機里，這樣部署靈活性提高不少。但是虛擬機還是很重，面對客戶千百萬化的需求，就有點無能為力。

　　舉一個例子

　　企業基本節點，我規模很小，可能就只有幾臺機器，這時候，我可能不需要控制節點高可用，我就需要1個控制節點，管理機柜計算節點。隨著時間的發展，希望擴大規模，控制節點變成高可用。規模進一步擴大，我就需要把消息隊列單獨出來部署，解決性能的問題。這種需求，很實在，OpenStack廠商也在努力滿足企業的這些需求，其實Mirantis的Fuel，已經在很多程度，滿足了企業這種需求，不過代價很大。

　　對于容器化的OpenStack，就變得很簡單，無非就是調整各個節點的容器分布，編排的問題。控制節點是3個，還是五個，rabbitmq放在什么位置，根本就不是問題。

　　配置管理

　　OpenStack過去使用最廣的配置管理工具是Puppet，對于企業用戶來說，這個是很難掌控的。其實在國內，就算是互聯網公司，負責Puppet的運維人員離職，其實都是很難招聘回來相應的人員。