容器化，OpenStack的生死抉择

　　OpenStack已经有6年的历史，对于开源软件来说，有一个客观规律，即5年将会步入成熟期，OpenStack也不例外。随着时间的推移，企业采用OpenStack的越来越多，风险也越来越小。聚焦OpenStack在国内的企业级市场，2016年才可称得上是正式启动年，相比国外大约晚两年。

　　“技术圈”知多少

　　企业用户在接受OpenStack时，最担心的问题应是：升级问题。以往OpenStack社区和技术厂商也做过很多的相关工作，社区中的各个项目，在代码级别就已经支持在线升级，虽是如此，传统的升级方式，通过操作系统的包管理进行升级的操作方法，在面对OpenStack一年两个版本的迭代速度来说，显然已经无能为力。

　　目前，各个技术厂商的发行版OpenStack产品，均通过自身发行版的包管理机制，实现手工升级。但是，若需要实现自动化升级，需要做大量的测试，但可利用的周期却很短，只有不到半年的测试时间，更别说跨版本升级工作所需要做的大量测试工作。

　　对此，在“容器（Docker）技术”出现以后，让OpenStack的厂商看到了希望。如果把OpenStack运行到Docker中，那么与之对应的升级问题，便迎刃而解。

　　OpenStack与Docker的关系

　　Docker从2013年出现至今，短短几年时间就已风靡全球技术圈。关于Docker是否会取代OpenStack，业界有过很多相关讨论。

　　任何技术，都不是完美的，也都有它的局限性。在现实世界中，Docker、VM和物理机器将长期并存。

　　在2015年OpenStack温哥华峰会上，OpenStack圈已经感觉到了来自Docker的威胁，为此，OpenStack调整了自身的定位，从开始定位于IaaS，建立私有云和公有云的平台，到后来演进成管理引擎，可以管理物理机器、虚拟机、Docker、网络和存储。

　　不仅如此，OpenStack还针对Docker技术，推出了3个与之息息相关的项目：Kolla将OpenStack容器化；Magnum、Solum、CO（包括Kubernetes、Swarm和Mesos）管理平台，为开发者使用容器来做应用开发。

　　另外，还有两个项目也与容器相关：Murano，提供容器的App Store功能；Kuryr，是Docker网络插件，通过Neutron为Docker容器提供网络服务。

　　业界的朋友曾经拿Docker开了句玩笑：“如果在OpenStack加拿大峰会上，OpenStack基金会没有能够针对Docker提出相应的策略，那么，OpenStack温哥华峰会很有可能将是最后一场。”玩笑归玩笑，但事实情况却有几分意味。

　　对Docker来说，OpenStack基金会适时地根据技术的变化来调整OpenStack的定位。既然要证明OpenStack具备管理容器的能力，那么就必须先将自身“容器化”。

　　得益于OpenStack的松耦合机制，即每个项目只做一件事情，在一个项目中各个模块的功能也可以进行拆分，这种设计同Docker的技术理念非常相近，即把OpenStack的每一个服务进程都放到Docker中，是非常合理的。

　　Kolla将OpenStack容器化？

　　Kolla项目诞生于2014年9月份，由Steven Dake提交。

　　Steven Dake（原红帽工程师）以前是HeatPTL，还是Corosync的作者。他对于OpenStack项目非常熟悉，现就职于思科公司并代表思科推出Kolla项目。

　　Kolla项目，是通过Docker来实现部署OpenStack。把OpenStack组件和相关项目全部都放在Docker里，实现Immutable infrastructure（不可变基础架构）。其中，它不能手工做任何修改，任何的修改都必须重新建立镜像，即重新来过。这样做的好处显而易见：方便升级、降级、故障修复，以及方便跟踪所有的修改。

　　目前，Kolla通过Ansible来管理容器，且已经支持生产使用。未来，将提供另外一种选择，即通过Kubernetes来管理Docker。Kolla的目标就要做到100个节点开箱即用，所有的组件HA都具备，即完全具备生产使用的需求。

　　能够解决的企业问题

　　1 升级。普遍认为容器最大的特点，就是升级。企业在使用OpenStack时，最大的顾虑就是升级问题。

　　容器化的OpenStack，升级就很容易了。简单来说，就是“删掉旧容器，换上新容器”，用户基本是在无感知的状态下，完成升级操作。

　　升级工作之所以很棘手，有一个很现实的原因是，线上环境很难模拟，且升级验证测试工作也很难进行。当采用容器化后，此问题迎刃而解。我们可以很容易地模拟出一个线上环境，并进行升级测试。若升级失败，“回滚（技术术语）”到初始状态即可。

　　2 安全。在金融行业和国企系统里，对生产系统的任何变更都需要做出周密的审批和记录，以往的操作方式是通过相关制度来实现的。而kolla部署的OpenStack，则可以依据Immutable Infrastructure的本身特性，即不能手工做任何修改，任何的修改都必须重新建立镜像。这样一来，恰到好处地满足了企业在安全方面的需求。

　　3 灵活。对于原有技术厂商的解决方案来说，大致是部署3个控制节点，如果客户希望增加到5个控制节点，或者把控制节点放在某个服务上单独部署，这样的需求基本上很难实现。为什么很难实现？以前的部署方法中，技术厂商会将OpenStack的各个服务放到虚拟机中，虽然灵活性提高不少，但虚拟机依然承载繁重，面对客户不断的新需求与旧需求变化，原有的操作方法显得有些无能为力。

　　例如在基本节点上，如果企业规模不大，只有几台网络设备，此时不需要控制节点的高可用，只需要1个控制节点，管理机柜计算节点即可。但随着企业的发展壮大，网络规模也需逐渐扩大，控制节点就需要实现高可用。网络规模只要一扩大，便需要将消息队列单独部署，用以解决性能的问题。

　　这种需求很现实，实际环境经常遇到，OpenStack技术厂商也在努力满足企业的这些变化需求，对于容器化的OpenStack来说，实现此类需求就显得很简单，无非就是调整各个节点的容器分布和编排的问题。无论控制节点是3个，还是5个，RabbitMQ在任何位置，借用容器化的OpenStack，便可轻松搞定。

　　4 配置管理。OpenStack所使用最广的配置管理工具是Puppet，对于企业用户来说，Puppet很难掌控。探究国内的现实情况，即便是几大互联网龙头公司，一旦负责Puppet的运维人员离职，损失都相当之大。不仅如此，对于OpenStack技术厂商来说，要想完全掌控Puppet，也是非常困难的，更别说还要满足各种灵活的企业需求。

　　然而，容器化后的OpenStack，其配置管理或编排工具，均有很多选择，例如Ansible、Salt、K8S都是可以支持和使用的，（不需要再受ruby的“折磨”了）。与此同时，也降低了企业掌控OpenStack的难度。

　　5 操作系统厂商依赖。现如今，众多技术厂商都在宣传所谓的“没有厂商绑定”。但在实际应用中，一旦选择了红帽的OpenStack，若想要更换到Ubuntu下，其更换过程非常“痛苦”，若是想更换成SUSE，难度就更高、更“痛苦”。

　　各种配置管理工具都是依赖其对应发行版的“包管理”。国内银行普遍使用SUSE公司产品。但社区Puppet工具却不支持SUSE，也就是说，操作系统发行版没有提供“包管理”，怎么办？

　　理论上，容器化的OpenStack可以运行在任何支持容器的操作系统之上。其内核版本高，无非就是性能更好一些。我们只需通过“点测试”，就可以实现这种跨操作系统的部署。实际中，容器可以使用rpm包、Deb包，也可以运行源码安装，这样一来，对于操作系统厂商来说，就不存在所谓的厂商依赖，即不受制于操作系统厂商。

　　6 软件依赖。随着OpenStack项目的增多，软件之间互相依赖的问题逐渐呈现出来。究其原因，主要是因为OpenStack有很多项目需要使用到外部资源，例如Ceph的“依赖问题”就和OpenStack组件的产生冲突。对此，容器化的OpenStack，可以很好地解决这个问题，让技术人员不再为此烦恼。

　　7 部署时间。在具体的生产环境中，部署时间无论是1个小时，还是一天24个小时，它们的意义区别不大，毕竟部署是一次性的工作。但对于测试工作来说，时间长短可就完全不一样了。如果10分钟可以完成一次部署，同几个小时才能完成一次的部署，相关测试内容的差异还是非常大的。

　　对此，容器化OpenStack可以大大缩短部署时间，通常情况下，10分钟便可完成一次完整功能的部署，与之对应的验证工作会大大减少。

　　8 显得简单。从企业使用OpenStack的反馈中，看对其抱怨最多的是过于复杂。因为OpenStack的松耦合特性，虽然其功能强大，但同时也让用户感觉相对复杂。尤其是在出现报错的时候，问题尤为凸显。

　　对此，容器化OpenStack后，用户可以感觉到OpenStack中的各个组件，其搭建模式类似于垒积木一样，可以按需选择相应的模块。我们可以很方便地安装某个模块，一旦不满意，删掉即可。其复杂的逻辑性，OpenStack社区已经成功完善，用户感觉容器化的OpenStack是可控的。

　　无论是采用外包还是企业自己运维，只有让企业感觉可以掌控OpenStack，OpenStack才有机会进入企业IT系统中。

　　9 计算节点HA。如果某个计算节点宕机，上接的虚拟机将自动启动其他节点。此类问题解决的办法有很多，但难点在于如何判断这台节点是否真的宕机。因为虚拟机是非常大的，很容易造成误判。

　　当OpenStack容器化后，我们可以利用容器强大的社区，第一时间知道节点是否失效，问题也就不再是“问题”了。

　　10 监控和日志分析。OpenStack社区一直都在完善其监控日志分析，但进展并不乐观。直到容器化的OpenStack才有所改观。在容器的技术范畴中，关于监控日志分析方面非常完善，我们可以利用强大的Docker社区，来完善OpenStack短板的地方。

　　11 创新。容器化的OpenStack可以带来很多意想不到的创新与变化。在OpenStack的版本发行周期中，大概分为B1、B2、B3，其中每个阶段大概45天，后续发布RC及正式版本。以往OpenStack技术厂商都是等到正式版本发布后，再进行打包、测试、验证，经过3个月到半年的时间，才可以正式对外发布。很显然，以往的发布周期已经跟不上OpenStack发展的步伐，例如Mitaka版本发布的时候，红帽的Liberty版本才正式对外发布。

　　那么，能不能实现OpenStack一边开发，其发行版也在同步进行打包、测试呢？其实在OpenStack发展初期，已经有这样的建议，不过对操作系统厂商来说，代价过大，没有厂商乐意去做。但容器化后的OpenStack截然不同，我们已经完全不需要依赖操作系统的打包，便可以根据自身的需求，进行BuildImage、测试，这样一来，产品的发布周期也会大大缩短。

　　基于OpenStack技术平台，很多企业级的实际问题都可以被解决，但一直没有得到普及的原因在于使用OpenStack不是那么“容易”。相比之下，强大的容器Docker社区在解决问题方面切实可行。故而，容器对OpenStack来说非常重要。

　　■作者九州云99Cloud副总裁 陈沙克