从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是最成熟的，剩下的几个也都在发展中。