从威胁到整合，容器将改变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关于容器的技术，能够关注沙克老师的博客。源创君也将不断推出更多更精彩的内容，敬请期待！