從威脅到整合，容器將改變openstack的將來？

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

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

1、OpenStack 重要發展歷程

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

在2015年，Openstack 引入了「大賬篷」策略。這個策略是指先定義出來一些必須用到的核心模塊，像Nova、Glance、Swift這些，剩下的再根據用戶實際需求選用。採用大賬篷策略之後，項目爆長，爲了應對用戶對虛擬機、容器、物理機等等上面的需求，Openstack變得愈來愈複雜。

2、OpenStack搭建流程

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

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

3、OpenStack的痛點和難點

一、安裝和部署困難

在安裝Openstack的時候，可能本身在測試的時候都很順，但在實際的企業環境中就會面對各類的挑戰。好比，國內有不少企業是徹底是不能聯網的，怎麼在網絡不通的狀況下完成安裝部署？實際上很是具備挑戰。並且有的企業在聯網狀況下安裝完能夠很好的運行，一旦網絡很差或者斷網，效率可能變得很低。這些問題若是沒有在實際安裝過程當中親身經歷過，很難提早想象。

二、維護更加困難

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

三、升級難上加難

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

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

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

4、容器給Openstack帶來新突破

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

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

並且，隨着容器化的使用，廠商的配置管理也啓用了專門的工具。在Openstack升級上有個很大的問題，就是升級致使的衝突問題，這個很是很差解決，解決起來也沒有任何的意義，徹底是拼體力。但用Docker隔開之後，已經能夠徹底避免這個問題了。還有以前當操做系統跟Openstack不是同一個語言的時候，也很容易致使它的依賴關係有衝突，解決起來不但沒有任何意義，還沒完沒了，容器化後一樣能進行規避。

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

5、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是最成熟的，剩下的幾個也都在發展中。

6、結語

本文內容整理自10月15日、16日的OSC成都、重慶源創會上陳沙克老師的演講，主要對Openstack和容器化進行介紹，想了解更多Openstack關於容器的技術，能夠關注沙克老師的博客。源創君也將不斷推出更多更精彩的內容，敬請期待！