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