2016年OpenStack中国峰会，最大的一个感受，就是厂商都在做容器化OpenStack。这已经是一个不可逆转的势头。
-
Mirantis的Fuel也要实现容器化OpenStack；
-
Canonical的Ubuntu OpenStack，通过LXD实现容器化；
-
Rackspace通过LXC实现容器化OpenStack，已经投入生产；
-
红帽已经开始验证OpenStack计算节点的容器化。
国内的厂商。其实应该都在做，公开的就是海云捷迅、九州云、麒麟三家。对于容器公司来说，可以选择很多方式来玩，搞OpenStack是一件锦上添花的事情。对于OpenStack厂商来说，搞容器，可是生死攸关的事情。
容器化的OpenStack实现，其实都差不多，就看各家谁更加彻底，更加优雅，更加安全。所谓彻底，就是完全对操作系统是免疫的，把容器删掉后，操作系统就好像没操作过一样。
一般来说都是：
-
build各种服务的Docker 镜像；
-
利用工具进行编排，对镜像分发，把镜像启动起来。
有些厂商仅仅是把控制节点容器化。对于Kolla项目来说，是把OpenStack和周边项目全部容器化。
-
Ceph
-
QEMU
-
Libvirt
这些都容器化，甚至在讨论NTP服务，也需要进行容器化。
Kolla项目 https://github.com/openstack/kolla
厂商把OpenStack容器化，会带来哪些好处呢？
这个其实大家都可以想到，容器最大的特点，就是升级。企业使用OpenStack，最大的一个顾虑，就是升级。尤其在OpenStack 1年两个版本下，不断的有新的功能的需求的情况下，如果不能升级，其实是很痛苦。尤其在企业的迅速发展的过程中。
容器化的OpenStack，升级有多么简单呢？其实就是删掉容器，换上新的容器，用户基本是无感知的状态下完成。
升级子所以很困难，有一个很现实的原因，线上环境，很难模拟，升级验证测试很难进行。当采用容器化以后，我们很容易模拟出一个线上环境，进行升级测试，升级失败，回滚。其实这些都做的很漂亮。
以前厂商的解决方案，都是3个控制节点，如果我希望增加到5个控制节点，或者把控制节点某个服务单独部署，那么这个基本是很难完成的任务。
以前厂商都厂商把OpenStack的各个服务放到虚拟机里，这样部署灵活性提高不少。但是虚拟机还是很重，面对客户千百万化的需求，就有点无能为力。
举一个例子
企业基本节点，我规模很小，可能就只有几台机器，这时候，我可能不需要控制节点高可用，我就需要1个控制节点，管理机柜计算节点。
随着时间的发展，希望扩大规模，控制节点变成高可用。
规模进一步扩大，我就需要把消息队列单独出来部署，解决性能的问题。
这种需求，很实在，OpenStack厂商也在努力满足企业的这些需求，其实Mirantis的Fuel，已经在很多程度，满足了企业这种需求，不过代价很大。
对于容器化的OpenStack，就变得很简单，无非就是调整各个节点的容器分布，编排的问题。控制节点是3个，还是五个，RabbitMQ放在什么位置，根本就不是问题。
OpenStack过去使用最广的配置管理工具是Puppet，对于企业用户来说，这个是很难掌控的。其实在国内，就算是互联网公司，负责Puppet的运维人员离职，其实都是很难招聘回来相应的人员。
对于OpenStack厂商来说，要想完全掌控Puppet，还是很困难的。更别说，要满足各种灵活的需求。
配置管理工具，其实Salt和Ansible，是Python开发，比较易用，不过在OpenStack的生态圈里，不如Puppet强大，很难超越Puppet。
容器化后的OpenStack，配置管理工具，或者编排的工具，就很多选择，Ansible、Slat、Kubernetes，都是可以支持。你就不需要受Ruby的折磨。
其实这也是大大降低企业掌控OpenStack难度。
厂商都在宣传所谓没有厂商绑定。其实你用了红帽的OpenStack，要想换到Ubuntu下，不是不可能，其实肯定很痛苦。如果要换成Suse，难度就更高。
各种配置管理工具，其实都是依赖发行版的包管理。国内的银行其实都使用Suse。但是社区的Puppet工具不支持Suse。或者我希望玩的项目，操作系统发行版没有提供包，怎么办？
容器化的OpenStack。其实理论上，可以跑在任何支持容器的操作系统上。内核的版本高，无非就是性能更好一点。其实你只需要做点测试，就可以实现这种跨操作系统的部署。
容器里，可以使用RPM包，Deb包，也是可以跑源码安装，这样其实对于操作系统厂商来说，基本就没任何的依赖。不受制操作系统厂商。
OpenStack项目的增多，软件互相依赖的问题，越来越严重。因为OpenStack很多项目是需要使用外部项目，例如Ceph，他的依赖很可能和OpenStack组件的依赖产生冲突。
