分享嘉賓簡介：九州云99Cloud副總裁陳沙克，多年深耕于開源云計算平臺Openstack技術，目前主要負責九州云99Cloud的產品、社區和研發。

從2010年發布到現在，就IaaS層面在目前的開源領域，Openstack已然成為一個代名詞。在這期間，Openstack也曾因為種種原因發生過一些調整和改變，而容器的出現，也對Openstack造成了革命性的影響。

一、OpenStack 重要發展歷程

在2013年基金會成立的時候， Rackspace將OpenStack的控制權交給基金會負責，OpenStack把自己定位為一個“可以做私有云、公有云的平臺”。 當Docker出來時，Openstack已然經過兩年的磨練，也考慮到市場環境因素，將定位調整為一款“管理引擎”，可以管理虛擬化、物理機、虛擬機、容器等等存儲網絡。就目前來講，它被賦予的使命非常多，但同時也飽受Docker的威脅。而且由于Openstack什么都要管，它的功能模塊非常多，基本上每個模塊都要實現一個功能，目前除了基本功能以外，已有三四十個大項目，每個大項目下面還有好幾個子項目。所以如果去GitHup上瀏覽，會發現Openstack的項目列表里面包含有幾百個項目。實際上，對用戶有用的或者說跟用戶實際功能相關的項目數量，大概在三四十個左右。

在2015年，Openstack 引入了“大帳篷”策略。這個策略是指先定義出來一些必須用到的核心模塊，像Nova、Glance、Swift這些，剩下的再根據用戶實際需求選用。采用大帳篷策略以后，項目爆長，為了應對用戶對虛擬機、容器、物理機等等上面的需求，Openstack變得越來越復雜。

二、OpenStack搭建流程

對企業來說，要將Openstack引入，首先要準備硬件，把存儲準備好，然后要裝操作系統。目前很多廠商已經對安裝操作系統那一塊做了自動化，減輕用戶部署的痛苦。再就是安裝Openstack的各種服務，配置Openstack各個節點的高可用。

安裝完這些還不夠，還需配置整個平臺，做日志的收集和監控。后續還需要對整個Openstack平臺進行運維和升級。下圖基本上就是企業在引入Openstack的時候，必須要做的一些過程。

三、OpenStack的痛點和難點

1、安裝和部署困難

在安裝Openstack的時候，可能自己在測試的時候都很順，但在實際的企業環境中就會面對各種的挑戰。比如，國內有很多企業是完全是不能聯網的，怎么在網絡不通的情況下完成安裝部署?實際上非常具有挑戰。而且有的企業在聯網情況下安裝完可以很好的運行，一旦網絡不好或者斷網，效率可能變得很低。這些問題如果沒有在實際安裝過程中親身經歷過，很難提前想象。

2、維護更加困難

當Openstack節點數量大的時候，靠傳統的人工維護方式是非常麻煩的。在幾十個節點上面，如果想要去查看日志或者修改配置，都是很難做的事情。

3、升級難上加難

Openstack進入企業面臨***的挑戰，就是升級。2016年是國內企業采納Openstack最多的一年，也是發展***的一年，但同時升級的問題也被不斷提出。當企業有了新功能、新特性，希望升級的時候，會面臨這樣一個問題：

以往軟件升級都是采用發行版、安裝包的方式實現，像紅帽采用的Yum，烏班圖的 apt-get 。但Openstack不行，因為Openstack現在一年兩個版本，中間只有半年的時間，廠商要對其進行打包和測試，加上Openstack現在的組件有幾十個那么多，廠商根本無法在那么短的時間內完成那么多的工作。而且當某次升級你沒跟上，時間就會越拖越長。

在之前，很多廠商都只能通過手動操作熬夜通宵來給企業升級，因為只有這種辦法才能完成。Openstack可以在不宕機、影響很小的情況下完成升級，但是這個過程是很長很累的，需要手動一點點地更新，而且每個客戶的情況都不太一樣，只能區別對待。而且不同的版本需要處理的問題是不一樣的，經驗的積累也是不一樣的。所以，對廠商來說，升級是件很痛苦的事。

四、容器給Openstack帶來新突破

那么，究竟要怎么幫助企業去解決這個問題呢?

可以說，在容器出現之前，這個問題是無解的。容器出現后，看到了希望，把Openstack放在容器里面進行升級。接觸過容器的應該知道，在容器里面沒有安裝的過程，它已經提前把安裝文件錄入到file里面。只需將Docker放到相應的機器上面，啟動起來，再把配置文件放回去，就可以把Openstack裝起來。這樣，整個過程能減少很多問題。至少，之前很容易遇到的語言沖突、包沖突的問題可以解決掉。

而且，隨著容器化的使用，廠商的配置管理也啟用了專門的工具。在Openstack升級上有個很大的問題，就是升級導致的沖突問題，這個非常不好解決，解決起來也沒有任何的意義，完全是拼體力。但用Docker隔開以后，已經可以完全避免這個問題了。還有之前當操作系統跟Openstack不是同一個語言的時候，也很容易導致它的依賴關系有沖突，解決起來不但沒有任何意義，還沒完沒了，容器化后同樣能進行規避。

更多好處可以參考"容器化 OpenStack 的10個好處"一文。試想，把Openstack容器化，整個安裝過程(不包括安裝操作系統)可能只需要20分鐘。在生產環境中，裝20分鐘和裝2個小時甚至一天的區別并不太大，但是在開發測試和驗證環境里面，20分鐘和2個小時存在很大差異。Openstack里面有許多功能需要反復的測試和操作，當時間減少至20分鐘的時候，將帶來極大的好處。

五、Openstack容器化的成熟項目——Kolla

對于Openstack的廠商來說，都曾體會過前面提到的痛點和難點，所以也都在很積極地解決這些問題。Rackspace、烏班圖的Canonical、 TCB Cloud 、Mirantis都做了相應的解決辦法去推動容器化，只是做法各有差異。除了廠商，社區也在努力，Kolla就是Openstack社區里推出的一個專門做Openstack容器化的項目。

目前來說，Kolla已經非常成熟，可以投入使用。Kolla不僅僅是把Openstack的組件容器化，還把周圍的所有的組件也容器化。簡單點說，一臺機器如果把容器刪掉，那么這臺機器將不會有任何剩留。因為它做得非常徹底，把所有的東西都放在了容器里面。這樣做的好處也顯而易見，這臺機器不管做什么東西，迭代都會非?？?。

Kolla之所以能迅速成熟是因為它有個理念——“怎么簡單怎么來”。它可以通過源碼或發行版的RTM發安裝包完成安裝，也能通過鏡像去配置文件，再放到相應的節點上去完成配置。當然，這個非常理想的狀況，因為在實際部署中，會面臨很多的東西。

沒有用過Kolla，或對Docker不是很熟悉的，只要了解Docker的理念，就會發現這種方式非常理想化，只需要在這臺機器以前的Docker file或master文件里面，不斷在相應的節點上放進去你想要達到的目標，啟動起來就可以了。這種靈活性也的確能給實際操作帶來很多好處。

下圖是Kolla的工作流程。一個Docker裝Openstack，Openstack在容器里跑。Docker在現在的企業使用中會遇到很多挑戰性的問題，比如說安全的問題，比如說網絡性能的問題。但是，Kolla的使用沒有面臨性能的問題，也沒有面臨安全的問題，因為它是內部的使用Docker，它的網絡直接是通過網橋出去的，就沒有網絡、性能的問題。所以說，Kolla利用了Docker非常穩定的部分，幫助Openstack實現了容器化。

目前來說，容器化給Openstack帶來了許多革命性的變化。未來有一種趨勢，它會自己容器化，也會管理容器，會用容器給用戶提供一些終端的服務。從今年的發展趨勢也能看到，未來很多東西會通過容器來啟動，Openstack上面有很多的服務，以前都是要很重地往里面裝一些東西，以后則可以直接放入Docker file啟動。下面列了幾個Openstack里面容器相關的項目，到目前來講，Kolla是最成熟的，剩下的幾個也都在發展中。