容器化OpenStack对未来架构的影响
导读：目前 OpenStack 的一个趋势，就是厂商都在做容器化 OpenStack。这已经是一个不可逆转的势头。本文是 OpenStack 社区资深人士在高可用架构群的分享。
陈沙克，目前在浙江九州云信息科技有限公司担任副总裁。从 2010 年至今一直从事云计算相关工作。2010 - 2011 年在云快线担任产品经理职位。2011 - 2014 年在中金数据担任云计算总监，负责金融行业的云计算解决方案。2014 - 2015 年，在文思海辉担任云计算部门总监职位，负责 OpenStack 在金融行业的方案和实施。
今天给大家介绍 OpenStack 容器化带来的好处，以及能解决那些问题。
2016 年 OpenStack 中国峰会的最大的一个感受，就是厂商都在做容器化 OpenStack，这已经是一个不可逆转的势头。
Mirantis 的 Fuel 要实现容器化 OpenStack；
Canonical 的 Ubuntu OpenStack，通过 LXD 实现容器化；
Rackspace 通过 LXC 实现容器化 OpenStack，已经投入生产；
红帽已经开始验证 OpenStack 计算节点的容器化。
国内也有不少厂商在做，公开的就是海云捷迅，九州云，麒麟三家。
对于容器公司来说，可以选择很多方式来玩，搞 OpenStack 是一件锦上添花的事情。但对于 OpenStack 厂商来说，搞容器可是生死攸关的事情。
OpenStack 要证明自己有管理容器的能力，就先要把自己容器化。OpenStack 容器化，是一个革命性的东西，以前很多积累，比如 puppet 脚本，基本就全部报废了。
技术实现
容器化的 OpenStack 实现大体差不多，就看谁更加彻底、更加优雅、更加安全。所谓彻底，就是完全对操作系统是免疫的，把容器删掉后，操作系统就好像没操作过一样。
一般来说都是 build 各种服务的 docker 镜像。利用工具进行编排，对镜像分发，把镜像启动起来。
有些厂商仅仅是把控制节点容器化。对于 kolla 项目来说，是把 OpenStack 和周边项目全部容器化：
ceph
qemu
libvirt
上面这些都容器化了，甚至也在讨论 NTP 服务也需要进行容器化。
Kolla 项目可参看 https://github.com/OpenStack/kolla
厂商把 OpenStack 容器化，会带来哪些好处呢？
升级
大家可以想到，容器最大的特点就是升级。企业使用 OpenStack，最大的一个顾虑就是升级。尤其在 OpenStack 一年两个版本下，不断的有新的功能的需求的情况下，如果不能升级，其实是很痛苦，尤其在企业的迅速发展的过程中。
容器化的 OpenStack 升级有多么简单呢？就是删掉容器，换上新的容器，用户基本是无感知的状态下完成。
升级之所以很困难，有一个很现实的原因，线上环境很难模拟，升级验证测试很难进行。当采用容器化以后，我们很容易模拟出一个线上环境，进行升级测试，升级失败回滚，这些都可以做的很简单。
灵活
以前厂商的解决方案，都是 3 个控制节点，如果希望增加到 5 个控制节点，或者把控制节点某个服务单独部署，基本是很难完成的任务。
以前厂商把 OpenStack 的各个服务放到虚拟机里，这样部署灵活性提高不少。但是虚拟机还是很重，面对客户千百万化的需求，就有点无能为力。
举一个例子，企业基本节点，规模很小，可能就只有几台机器，这时候可能不需要控制节点高可用，只需要 1 个控制节点管理机柜计算节点。随着时间的发展，希望扩大规模，控制节点变成高可用。规模进一步扩大，就需要把消息队列单独出来部署，解决性能的问题。
这种需求很实在， OpenStack 厂商也在努力满足企业的这些需求，Mirantis 的 Fuel 已经在很多程度满足了企业这种需求，不过代价很大。
对于容器化的 OpenStack，就变得很简单，无非就是调整各个节点的容器分布，编排的问题。控制节点是 3 个，还是 5 个，rabbitmq 放在什么位置，根本就不是问题。
配置管理
OpenStack 过去使用最广的配置管理工具是 Puppet，对于企业用户来说是很难掌控的。在国内，就算是互联网公司，负责 Puppet 的运维人员离职，是很难招聘回来相应的人员。
对于 OpenStack 厂商来说，要想完全掌控 Puppet，还是很困难的。更别说，要满足各种灵活的需求。
配置管理工具，Salt 和 Ansible 是 Python 开发，比较易用，不过在 OpenStack 的生态圈里，不如 puppet 强大，按照传统的包管理方式，很难超越 Puppet。
容器化后的 OpenStack ，配置管理工具，或者编排的工具，就很多选择，ansible，slat，K8S，都是可以支持。你就不需要受 Puppet 工具 Ruby 的折磨。这也是大大降低企业掌控 OpenStack 难度。
操作系统厂商依赖
厂商都在宣传没有厂商绑定。但其实你用了红帽的 OpenStack，要想换到 Ubuntu 下，不是不可能，目前是很痛苦。如果要换成 Suse，难度就更高。
各种配置管理工具，都依赖发行版的包管理。国内的银行大多使用 Suse。但是社区的 Puppet 工具不支持 Suse。或者希望玩的项目，操作系统发行版没有提供包，怎么办？
容器化的 OpenStack 。理论上可以跑在任何支持容器的操作系统上。内核的版本高，无非就是性能更好一点。你只需要做点测试，就可以实现这种跨操作系统的部署。
容器里，可以使用 rpm 包，Deb 包，也是可以跑源码安装，这样对于操作系统厂商来说，基本就没任何的依赖。不受制操作系统厂商。
软件依赖
OpenStack 项目的增多，软件互相依赖的问题，越来越严重。因为 OpenStack 很多项目是需要使用外部项目，例如 Ceph，他的依赖很可能和 OpenStack 组件的依赖产生冲突。
这种问题可以解决，但是解决没任何的意义和技术含量，很让技术人员抓狂。因此发行版都在投入大量的精力去解决各个软件包的互相依赖的问题。
容器化的 OpenStack，很好的解决了这个问题。
部署时间
在生产环境中，部署时间 1 小时和 1 天，区别不大，毕竟部署是一次性的工作。对于测试来说，就完全不一样。如果 10 分钟可以完成一次部署，可以测试验证的东西，和几个小时才能完成一次的部署，差异还是很大的。
容器化 OpenStack，大大加快了部署的时间，通常 10 分钟，就可以完成一次完整功能的部署，验证 OpenStack 各种新功能的代价，就大大减少。
使用简单
OpenStack 在企业的实际使用中，都是抱怨太复杂，这是因为 OpenStack 松耦合，功能强大，同时也让用户感觉很复杂。尤其在出现错误的时候，很无奈。
容器化后，用户感觉 OpenStack 各个组件，就类似累积木一样，搭建起来，可以根据自己的需求，选择哪个模块。感觉自己是可控的。你可以很方便的装上某个模块，不满意，删掉。背后的复杂的逻辑，社区已经帮你完善。
遇到问题，寻求帮助，也显得简单很多。因为大家容器里的东西都是一样，无非就是外面的配置文件的差异。
也只要让企业感觉自己可以掌控 OpenStack ，这样 OpenStack 才会大量的进入企业的 IT 系统，无论是采用外包还是自己运维。
计算节点 HA
如果实现计算节点挂掉后，上面的虚拟机自动在别的节点启动起来。解决的办法有很多，解决的难点就在于如何判断这台节点真的挂掉。因为虚拟机的迁移的东西，是很大的，必须很小心。也很容易造成误判。
海云捷迅提出一个使用 consul 的解决方案，就是一个容器里做健康检查的组件，放到 OpenStack 计算节点，类似 peer to peer，互相检查。
当容器化的 OpenStack 后，就可以利用容器强大社区，各种的实现方式，第一时间知道节点失效。你也是可以使用 consul 来解决，更加直接。
监控和日志分析
OpenStack 一直在完善自己的监控日志分析。不过进展并不太好。容器化的 OpenStack ，面临的监控，日志的问题，和以前的 OpenStack 有很大差异。
不过不得不承认，容器的世界里，这方面非常完善，太多选择，可以帮助你解决监控和日志分析的问题。因此可以利用强大的 Docker 社区，来完善 OpenStack 短板的地方。
创新
容器化后的 OpenStack 带来很多意想不到的创新和变化。很多以前很炫的概念，慢慢走向现实。
OpenStack 一个版本的发行周期大概是分为 B1，B2，B3，每个阶段大概 45 天，后续就发布 RC，正式版本。
以往 OpenStack 公司需要等到一个版本正式发布后，进行打包，测试，验证，经过 3 个月和半年，正式对外发布。这种发布周期，已经有点跟不上 OpenStack 的步伐。例如 Mitaka 版本发布的时候，红帽的 Liberty 版本才正式对外发布。
能不能做到，OpenStack 一边开发，发行版也在同步进行打包测试呢？在 OpenStack 发展初期，有人提出这样的建议，不过对操作系统厂商来说，代价太大，不愿意去做。
有了容器化以后，完全不需要依赖操作系统的打包，可以根据自己的需求，进行 build image，测试，这样产品的发布周期，就会大大缩短。
总结
OpenStack 上的很多问题，都可以解决，只是解决起来很费劲，容器化，解决就显得很优雅。有强大的 Docke r社区，你解决问题的方法，方式就更多。
Q&A
提问：OpenStack 网卡必须设置成 promisc 模式？
陈沙克：这个问题，和你网络选择模式有关，不是必须
提问：promisc 模式什么情况下必须，什么情况下不必须？
陈沙克：我配置 openstack，就是把交换机端口设置成 trunk 模式，如果采用 vlan 的设置。
提问：对象存储选择 Ceph 还是 Swift？有啥建议？
陈沙克：只能说，目前 ceph 社区很强大，对象存储的功能，已经和 swift 基本一致。所以 ceph 还是未来。建议选择 ceph。
提问：OpenStack 的块存储服务使用 Cinder？有其他更好的选择？
陈沙克：这个问题应该是 cinder 底下的存储使用什么。目前生产使用的，开源使用 ceph。还有各种商业的存储都有 cinder 的 driver。目前 OpenStack 已经默认采用 boot from volume，虚拟机就建立在 cinder上。
提问：你们修复了 OpenStack 的什么bug，能否简单介绍？
陈沙克：今天就讲 kolla 的 bug 吧，很多是因为不同的版本及参数设置导致的问题，这种 bug 社区是可以查看到，https://review.openstack.org/#/q/project:openstack/kolla+bug:
提问：你们使用 OpenStack 的过程中踩过那些坑？
陈沙克：基本是因为我们没有好好阅读每个版本的变化，导致配置的错误，这是最多的坑。建议大家一定要仔细。
提问：你们使用 Docker 容器化的过程中踩过那些坑？
陈沙克：openstack 容器化，难点肯定在于网络和 qemu。一个例子，就是一个 qemu 的进程，其实就是一个虚拟机。我更换 qemu 的 docker，肯定不能把 vm 也删掉。这些问题，社区技术上都解决了。网络上，由于 ovs 也容器化，也带来一些挑战，不过也基本都解决了。国内在 docker 的研究，还是很深入，高手很多。我遇到问题，找身边 docker 的朋友沟通，基本都可以解决。大家都知道，docker 同步时间的问题。kolla 也都遇到并解决了。
最后一点，kolla 现在是可以生产使用。
相关阅读
本文策划邓启明，转播尹雯玉，想了解更多 OpenStack 及 Docker 内容，请关注「ArchNotes」微信公众号以阅读后续文章。转载请注明来自高可用架构及包含以下二维码。
高可用架构
改变互联网的构建方式
长按二维码 关注「高可用架构」公众号