容器化OpenStack好处分析

　　2016年OpenStack中国峰会，最大的一个感受就是厂商都在做容器化OpenStack。这已经是一个不可逆转的势头。

　　Mirantis的Fuel也要实现容器化OpenStackCanonical的Ubuntu OpenStack，通过LXD实现容器化Rackspace通过LXC实现容器化OpenStack，已经投入生产红帽已经开始验证OpenStack计算节点的容器化。

　　国内的厂商。其实应该都在做，公开的就是海云捷迅，九州云，麒麟三家。对于容器公司来说，可以选择很多方式来玩，搞OpenStack是一件锦上添花的事情。对于OpenStack厂商来说，搞容器，可是生死攸关的事情。

　　技术实现

　　容器化的OpenStack实现，其实都差不多，就看各家谁更加彻底，更加优雅，更加安全。所谓彻底，就是完全对操作系统是免疫的，把容器删掉后，操作系统就好像没操作过一样。

　　一般来说都是

　　build各种服务的docker 镜像。利用工具进行编排，对镜像分发，把镜像启动起来。

　　有些厂商仅仅是把控制节点容器化。对于kolla项目来说，是把OpenStack和周边项目全部容器化

　　cephqemulibvirt

　　这些都容器化，甚至在讨论NTP服务，也需要进行容器化。

　　Kolla项目 https://github.com/openstack/kolla

　　厂商把OpenStack容器化，会带来哪些好处呢？

　　升级

　　这个其实大家都可以想到，容器最大的特点，就是升级。企业使用OpenStack，最大的一个顾虑，就是升级。尤其在OpenStack1年两个版本下，不断的有新的功能的需求的情况下，如果不能升级，其实是很痛苦。尤其在企业的迅速发展的过程中。

　　容器化的OpenStack，升级有多么简单呢？其实就是删掉容器，换上新的容器，用户基本是无感知的状态下完成。

　　升级子所以很困难，有一个很现实的原因，线上环境，很难模拟，升级验证测试很难进行。当采用容器化以后，我们很容易模拟出一个线上环境，进行升级测试，升级失败，回滚。其实这些都做的很漂亮。

　　灵活

　　以前厂商的解决方案，都是3个控制节点，如果我希望增加到5个控制节点，或者把控制节点某个服务单独部署，那么这个基本是很难完成的任务。

　　以前厂商都厂商把OpenStack的各个服务放到虚拟机里，这样部署灵活性提高不少。但是虚拟机还是很重，面对客户千百万化的需求，就有点无能为力。

　　举一个例子

　　企业基本节点，我规模很小，可能就只有几台机器，这时候，我可能不需要控制节点高可用，我就需要1个控制节点，管理机柜计算节点。随着时间的发展，希望扩大规模，控制节点变成高可用。规模进一步扩大，我就需要把消息队列单独出来部署，解决性能的问题。这种需求，很实在，OpenStack厂商也在努力满足企业的这些需求，其实Mirantis的Fuel，已经在很多程度，满足了企业这种需求，不过代价很大。

　　对于容器化的OpenStack，就变得很简单，无非就是调整各个节点的容器分布，编排的问题。控制节点是3个，还是五个，rabbitmq放在什么位置，根本就不是问题。

　　配置管理

　　OpenStack过去使用最广的配置管理工具是Puppet，对于企业用户来说，这个是很难掌控的。其实在国内，就算是互联网公司，负责Puppet的运维人员离职，其实都是很难招聘回来相应的人员。