谈 OpenStack 与 Docker 的落地方案选择

转自： https://www.sdk.cn/news/5086

OpenStack & Docker 综述

---

时至今日，云计算已经从概念、评估而逐步进入了 Gartner 定义的复苏期 （Slope of Enlightenment） ，逐步在企业中落地推广。而云计算中热门的两个技术 OpenStack 与 Docker也早已是企业中不可或缺的技术话题，看看国内围绕两大技术的创业公司、技术Meetup、技术大会以及各联盟组织就可见一斑。Google Trends 的趋势曲线也印证了两大技术的火热情况：

图 1 OpenStack & Docker Google Trends

先简单回顾一下两大技术的历史和现状：

OpenStack 起源于2010年7月的 Austin 版本，作为典型的云计算 IaaS 层的具体实现工具，在与当年的 OpenNebula、CloudStack 的血拼中脱颖而出。通过命名为 Nova、Neutron、Keystone、Glance 等各组件实现对裸机、虚机、块存储、对象存储、文件目录、网络、负载均衡、防火墙等数据中心基础架构的统一调度管理，目前已经发布到 M 版本，形成了较强的开源生态圈和产业链，同时也成为了国内企业开源私有云构建的事实首选。

Docker 起源于2013年3月的首版，是基于LXC为基础构建的容器引擎，通过 Namespace 和 Cgroup 实现了资源隔离和调配，使用分层存储来构建镜像，这些特性实现了将 OS 和应用捆绑的方法，直接造成了整个玩法的变革，使得应用系统环境标准化、集装箱化传递成为现实。如果说 OpenStack 只能让数据中心的架构师、系统网络工程师兴奋的话，那么 Docker 则是可以让开发、测试、应用运维、系统网络工程师都兴奋的东西（从曲线的热度即可印证），同时随着DevOps、CI/CD、微服务的火热，Docker 正好是实现上述名词的极佳载体。由于 Docker 本身是缺乏集群调度、管理、监控、服务注册发现等集群化运行管理能力的，因此目前也存在三种主流的 COEs（Container Orchestration Engines） 容器调度引擎：原生的 Docker Swarm、Google 的 Kubernetes（Borg 简化版）以及 Apache Mesos，这三种主流的 COEs 目前还在都还在发展中，下图为 Google Trends：

图 2 Kubernetes & Mesos & Docker Swarm Google Trends

OpenStack & Docker 的融合开源技术方案

---

Nova Docker

---

图 3 Nova Docker 方案，来源：OpenStack官网 Wiki

该方案将容器像 VM 一样操作，通过增加 Nova Docker driver，实现对 Docker容器的启停、创建等常规 VM 的操作，可以通过 Docker save 方式将镜像存放在 Glance 之中，该种方案很大的好处在于可以使用现成的 OpenStack Neutron 来管理网络、实现租户的资源配额、使用 Host OS（注：此处不等于 BareMetal ）等 OpenStack 的天然好处。然而缺点也明显，没法使用 Docker/COEs 带来的更有价值功能，例如服务发现、端口映射等。国内某大型电商就使用的该方案。该方案是早期的集成方案。目前已经不在官方版本中。参考 https://wiki.openstack.org/wiki/Docker。

Zun

---

社区的新项目，6月刚刚起步。目标在于解决 Nova Docker 方案存在的问题，独立于 Nova 之外实现 Docker 部署调度框架，自身实现与 Glance、Neutron、Cinder等组件的集成。然而并不实现对COEs的部署调度。该项目由国内民族 IT 企业社区活跃大神主导，参考 https://wiki.openstack.org/wiki/Zun。

图 4 Zun方案，来源：https://wiki.openstack.org/wiki/Zun

Heat Docker plugin

---

图 5 Heat Docker plugin 方案，来源 GitHub

该方案不依赖于 Nova 的调用，而是通过 OpenStack 编排组件 Heat 进行编排调用，通过使用 Heat Docker plugin 在创建的 VM 上使用 Heat Templates 设定 Docker 的参数，这样则可以使用 Docker API 提供的所有功能，缺点在于 VM 上使用 Docker，无法实现资源调度，需要较多的配置工作，无法实现规模集群管理 。参考 https://github.com/MarouenMechtri/Docker-containers-deployment-with-OpenStack-Heat。

Magnum

---

在14年的 Nove Docker 及 Nove Heat plugin 总是不够完美的情况下，社区于15年3月推出了 Magnum 版本。通过管理 COEs，将 COEs 作为服务进行提供。同时在15年的官方白皮书中也再次发布了容器与 OpenStack 的未来：通过 Magnum 管理在 VM 及 BareMetal 上提供 COEs 的服务。

图 6 OpenStack 与 COEs 的规划，来源：OpenStack 白皮书

图 7 Magnum 架构图，来源：https://wiki.openstack.org/wiki/Magnum

现在的 Magnum 的架构图如上，目前对 Swarm、Kubernetes、Mesos 均可以支持。通过定义 Bay、Node、Pod 映射为 COEs 的集群、Pod 的实现，完成对 COEs 的部署调度，由 COEs 调度部署 Docker，可以理解成 COEs as a service 的实现。通过 OpenStack现有的 Heet、Nova、Heat、Neutron、Glance 和 Keystone 等组件实现租户、编排、镜像、认证、网络等其他功能管理功能。现有的方案还不能实现在 BareMetal 上的部署。网络方案一直是各种集成解决方案的重中之重，目前 Magnum 主要为通过与 COEs 的 Flannel 的 Overlay 方案，存在一定性能问题，同时由于现有 COEs 的网络方案还存在多样性和变数，因此存在需要多种驱动的逐一实现的问题。

不过毕竟 Magnum 是 OpenStack 官方主攻的容器集成方案，因此有大量的贡献者在完善该项目，通过 Magnum 的 Blueprints 可以看到即将发布（10月）的 OpenStack Newton 版本将进行大量的更新，其中重要的在裸机上部署COEs将得到完全支持：

图 8 Magnum Blueprints，来源：https://blueprints.launchpad.net/magnum

Kuryr

---

刚才提到了由于 COEs 网络方案的多样性与变数，因此社区专门孵化了 Kuryr 项目，该项目用于实现 Neutron 与 Docker/COEs 网络的驱动映射工作，未来可成为 Magnum 网络的选择，实现容器网络的功能性能加强。参考 https://wiki.openstack.org/wiki/Kuryr。

图 9 Kuryr 架构图，来源：https://wiki.openstack.org/wiki/Kuryr

Kolla

---

前面谈到的方案均是 OpenStack 怎么与 COEs/Docker 结合，提供不同形式的混合负载给上层使用的需求，而 Kolla 则是用于实现 OpenStack 这个“庞大复杂“的管理工具自身的部署/升级/维护的。虽然 OpenStack 也有许多的自动化运维项目，如 Fuel、Ansible、Puppet 等项目，然而随着 OpenStack 的日益发展和被管理的节点及环境日志扩张，在庞大的生产系统长期维护和运行一套/多套 OpenDtack（Day 2 Operations） 也会日渐成为严重的问题。而随着容器化的发展，OpenStack 社区也想到自身使用容器进行部署将不仅解决上述问题，也证明自己充分拥抱容器的决心。

图 10 Kolla 架构，来源：https://wiki.openstack.org/wiki/kolla

目前 Kolla 通过容器化绝大部分的 OpenStack 组件，并通过 Ansible 来实现配置自动化管理。实现 OpenStack 自身的容器化管理。未来也会逐步成为国内企业 OpenStack 的管理方案首选。参考 http://docs.openstack.org/developer/kolla/。

以上所描述的方案是无论是完美的还是有缺陷的，也无论方案现在是否热门主流，对于在开源社区分享贡献开源技术方案的个人或团队都是值得钦佩与尊敬的。

落地方案的选择

---

想要进行数据中心整体资源管理调度，实现裸机、VM、容器、LB、FW、Storage 等多层级服务，可以参考以下落地方案进行选择：

OpenStack 与 Docker 都没有部署

---

等 OpenStack Newton 版本出来再开始试用，也不需要等太久。那时 Magnum 将更成熟，且支持裸机的部署，同时 COEs 也都会有一定进展，可以更清晰的选择 COEs。

已经部署了 OpenStack ，等不急 Newton 版本

---

OpenStack 的大版本生产升级本身就是个工程，因此 OpenStack 与 COEs 的部署建议从物理上分开，各自部署各，当然可以在前端 UI 上进行整合。在 newton 发布后进行迁移及升级评估，看是否能较无缝进行后端技术方案集成升级。

已经独立部署了 COEs 其中的一种，是否还需要 OpenStack

---

OpenStack 最大的用处是实现整个数据中心基础架构的管理，比如硬件服务器、存储、负载均衡、SDN 硬件、防火墙等，已经有大量的软硬件厂商与其实现了驱动集成，因此如果考虑的是整个数据中心的整体调度管理的话，则可选用OpenStack Magnum + COEs的方案。如果考虑的是上层的 PaaS 层的资源调度及管控以及 CI/CD ，则还是坚持只使用 COEs。

开源世界唯一不变的是变化，所以无论选择哪种方式都必定会踩很多坑，需要做好充分的技术准备或者找到合适的合作伙伴，充分评估自己的需求及选择合适的技术方案。

【作者简介：陈爱珍 ，七牛云布道师。多年企业级系统的应用运维及分布式系统实战经验。现专注于容器、微服务及DevOps落地的研究与实践。】