Openstack与Docker的融合
OpenStack & Docker 综述
时至今日，云计算已经从概念、评估而逐步进入了 Gartner 定义的复苏期 （Slope of Enlightenment） ，逐步在企业中落地推广。而云计算中热门的两个技术 OpenStack 与 Docker也早已是企业中不可或缺的技术话题，看看国内围绕两大技术的创业公司、技术Meetup、技术大会以及各联盟组织就可见一斑。Google Trends 的趋势曲线也印证了两大技术的火热情况：
先简单回顾一下两大技术的历史和现状：
OpenStack 起源于2010年7月的 Austin 版本，作为典型的云计算 IaaS 层的具体实现工具，在与当年的 OpenNebula、CloudStack 的血拼中脱颖而出。通过命名为 Nova、Neutron、Keystone、Glance 等各组件实现对裸机、虚机、块存储、对象存储、文件目录、网络、负载均衡、防火墙等数据中心基础架构的统一调度管理，目前已经发布到 W 版本，形成了较强的开源生态圈和产业链，同时也成为了国内企业开源私有云构建的事实首选。
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：
OpenStack & Docker 的融合开源技术方案
Nova Docker
该方案将容器像 VM 一样操作，通过增加 Nova Docker driver，实现对 Docker容器的启停、创建等常规 VM 的操作，可以通过 Docker save 方式将镜像存放在 Glance 之中，该种方案很大的好处在于可以使用现成的 OpenStack Neutron 来管理网络、实现租户的资源配额、使用 Host OS（注：此处不等于 BareMetal ）等 OpenStack 的天然好处。然而缺点也明显，没法使用 Docker/COEs 带来的更有价值功能，例如服务发现、端口映射等。国内某大型电商就使用的该方案。该方案是早期的集成方案。目前已经不在官方版本中。
参考 https://wiki.openstack.org/wiki/Docker
Zun
OpenStack是一个主流的开源云管理平台，旨在提供丰富的云平台服务，支持轻松实施、大规模向上/下扩展和统一标准。数百家全球知名企业正在以OpenStack为基础运营业务，以降低成本并加快行动。
Zun是Openstack的一个组件，提供容器管理服务，出现于2016年6月。
Zun的目标是提供统一的Openstack API用于启动和管理容器，支持多种容器技术。Zun原来称为Higgins，后改名为Zun。Zun计划支持多种容器技术，Docker，Rkt，clear container等，目前只支持Docker。OpenStack Queens版本发布，由于容器社区的火热，一项值得关注的补充则为“Zun”，它在OpenStack项目中负责提供容器服务，旨在通过与Neutron、Cinder、Keystone以及其它核心OpenStack服务相集成以实现容器的快速普及。通过这种方式，OpenStack的原有网络、存储以及身份验证工具将全部适用于容器体系，从而确保容器能够满足安全与合规性要求。
参考 https://wiki.openstack.org/wiki/Zun
Magnum
Magnum是OpenStack中一个提供容器集群部署的服务。
Magnum是一个Pass层的OpenStack项目。Magnum使用Heat部署一个包含Docker和Kubernetes的操作系统镜像，让容器集群运行在虚拟机（Virtual Machine）或者裸机（Bare Metal）中。
Magnum项目创建之初，项目目标以Caas为宗旨，即容器即服务。但在后续的发展过程中，社区更倾向于分离容器的集群部署功能和Docker容器集群的管理功能。因此Magnum重新修改了项目目标，Magnum本身专注于容器的集群部署功能。另一个项目Zun专注管理Docker容器集群。
参考 https://wiki.openstack.org/wiki/Magnum
Heat Docker plugin
该方案不依赖于 Nova 的调用，而是通过 OpenStack 编排组件 Heat 进行编排调用，通过使用 Heat Docker plugin 在创建的 VM 上使用 Heat Templates 设定 Docker 的参数，这样则可以使用 Docker API 提供的所有功能，缺点在于 VM 上使用 Docker，无法实现资源调度，需要较多的配置工作，无法实现规模集群管理 。
参考 https://github.com/MarouenMechtri/Docker-containers-deployment-with-OpenStack-Heat
Kuryr
刚才提到了由于 COEs 网络方案的多样性与变数，因此社区专门孵化了 Kuryr 项目，该项目用于实现 Neutron 与 Docker/COEs 网络的驱动映射工作，未来可成为 Magnum 网络的选择，实现容器网络的功能性能加强。
参考 https://wiki.openstack.org/wiki/Kuryr
Kolla
前面谈到的方案均是 OpenStack 怎么与 COEs/Docker 结合，提供不同形式的混合负载给上层使用的需求，而 Kolla 则是用于实现 OpenStack 这个“庞大复杂“的管理工具自身的部署/升级/维护的。虽然 OpenStack 也有许多的自动化运维项目，如 Fuel、Ansible、Puppet 等项目，然而随着 OpenStack 的日益发展和被管理的节点及环境日志扩张，在庞大的生产系统长期维护和运行一套/多套 OpenDtack（Day 2 Operations） 也会日渐成为严重的问题。而随着容器化的发展，OpenStack 社区也想到自身使用容器进行部署将不仅解决上述问题，也证明自己充分拥抱容器的决心。
目前 Kolla 通过容器化绝大部分的 OpenStack 组件，并通过 Ansible 来实现配置自动化管理。实现 OpenStack 自身的容器化管理。未来也会逐步成为国内企业 OpenStack 的管理方案首选。