Magnum项目是OpenStack中的容器编排服务引擎，向上提供统一API，向下异构兼容K8S，Mesos，Swarm等容器管理平台，是OpenStack与容器结合的官方正式项目。
当说到基于 OpenStack的IaaS平台上的Docker时，不得不提Magnum。Magnum旨在让用户可以直接在OpenStack环境中部署Containers，也是OpenStack和Docker集成支持度最好的项目。
上图为所有Release中，各公司参与Magnum项目的Commits统计数量。不难看出，呈现出很明显的4巨头格局，IBM、Huawei、NEC 和 Intel。看得出来，国内华为对该项目的热情和投入是非常高的。
谈谈Magnum社区
Mangum现在应该是OpenStack里边比较热门的一个和Docker集成的新项目。Magnum是去年巴黎峰会后开始的一个新的专门针对Container的一个新项目，用来向用户提供容器服务。
从去年11月份开始在Stackforge提交第一个Patch，今年3月份进入OpenStack Namespace，这个项目应该是OpenStack社区从Stackforge迁移到OpenStack Namespace最快的一个项目。
Magnum现在可以为用户提供Kubernetes as a Service、Swarm as a Service和这几个平台集成的主要目的是能让用户可以很方便的通过OpenStack云平台来管理K8s，Swarm等这些已经很成型的Docker集群管理系统，使用户很方便的使用这些容器管理系统来提供容器服务。
下图主要是想强调Magnum社区现在快速发展，也反应出了Magnum社区的一些情况。
主要列出了一些为Magnum做贡献的公司，包括IBM、Rackspace、HPE、Cisco等等，IBM目前在这个项目排第一位。
通常情况下，一个公司对哪些项目比较看重，或者它对OpenStack社区的最近的一些策略，都可以通过分析每个公司对OpenStack的贡献来得到一定的结论。如果某个公司在某个项目贡献比较多的话，可能就意味着这个公司会在相关领域有一些动作。
如果大家如果感兴趣的话，可以通过网站http://stackalytics.com/去研究一下自己感兴趣的公司最近在OpenStack的一些动态。
为什么是Magnum？
接下来我们看下为什么需要Magnum、OpenStack现在和Docker集成现在主要有三块，包括Nova Docker Driver，Heat Docker Driver和Kilo推出的Magnum，当然还包含一些别的项目，例如Sahara，Murano，Kolla，Solum等等。
Nova Docker Driver介绍
上图是Nova Docker Driver，这个Driver是OpenStack和Docker的第一次集成，相信对Docker和OpenStack感兴趣的人，应该都用过这个Driver，它把Docker作为一种新的Hypervisor来处理，把所有的Container当成VM来处理。提供了一个Docker的Nova Compute Driver。
这个Driver的优点是实现比较简单，只需要把Nova Compute中的一些对虚拟机操作的常用接口实现就可以，现在主要支持创建，启动，停止，暂停等虚拟机的基本操作。
另外一个是因为Nova Docker Driver也是一个Nova的Compute Driver，所以他可以像其他的Compute Driver一样使用OpenStack中的所有服务，包括使用Nova Scheduler来做资源调度，使用Heat来做应用部署，服务发现，扩容缩容等等，同时也可以通过和Neutron集成来管理Docker网络。也支持多租户，为不同的租户设置不同的Quota，做资源隔离等等。IBM现在的SuperVessel Cloud使用的就是这个Driver。
他的缺点也很明显，因为Docker和虚拟机差别也挺大的，Docker还有一些很高级的功能是VM所没有的，像容器关联，就是使不同容器之间能够共享一些环境变量，来实现一些服务发现的功能，例如K8s的Pod就是通过容器关联来实现的。
另外一个是端口映射，K8s的Pod也使用了端口映射的功能，可以把一个Pod中的所有Container的port都通过Net Container Export出去，便于和外界通信。还有一个是不同网络模式的配置，因为Docker的网络模式很多，包括Host模式，Container模式等等，以上的所有功能都是Nova Docker Driver不能实现的。
Heat Docker Driver介绍
上图是Heat Docker Driver，因为Nova Docker Driver不能使用Docker的一些高级功能，所以社区就想了另一个方法，和heat去集成，因为Heat采用的也是插件模式，所以就在Heat实现了一个新的Resource，专门来和Docker集成。
这个Heat插件是直接通过Rest API和Docker交互的，不需要和Nova、Cinder、Neutron等等来进行交互。
所以这个Driver的优点首先是完全兼容Docker的API，因为我们可以在Heat Template里边去定义我们关心的参数，可以实现Docker的所有高级功能，用户可以在Heat Template定义任意的参数。另外因为和Heat集成了，所以默认就有了Multi Tenat的功能，可以实现不同Docker应用之间的隔离。
但是，其缺点也非常明显，因为他是Heat直接通过Rest SPI和Docker交互的，所以Heat Docker Driver没有资源调度，用户需要在Template中指定需要在哪一台Docker服务器上去部署应用，所以这个Driver不适合大规模应用,因为没有资源调度。
另外因为没有和Neutron去交互，所以网络管理也只能用Docker本身的网络管理功能，没有Subnet，网络隔离也做得不是太好，需要依赖于用户手动配置Flannel或者OVS等等。
Magnum简介
所以社区就推出了Magnum这个项目。上图是Magnum的一个架构图。
Magnum主要概念
它的结构其实很简单，首先我们看下magnum的主要概念，在这个图的右边，主要包括Bay、Baymodel、Node、Pod、Service、RC、Container。
Bay：Bay在magnum主要表示一个集群，现在通过Magnum可以创建K8s和Swarm的Bay，也就是K8s和Swarm的集群。
Baymodel：Baymodel是Flavor的一个扩展，Flavor主要是定义虚拟机或者物理机的规格，Baymodel主要是定义一个Docker集群的一些规格，例如这个集群的管理节点的Flavor，计算节点的Flavor，集群使用的Image等等，都可以通过Baymodel去定义。
Node：主要是指Bay中的某个节点。
Container：就是具体的某个Docker容器。Pod、Replication Controller和Service的意思和在K8s的意思是一样的。在这简单介绍下这三个概念。
Pod：是Kubernetes最基本的部署调度单元，可以包含多个Container，逻辑上表示某种应用的一个实例。比如一个Web站点应用由前端、后端及数据库构建而成，这三个组件将运行在各自的容器中，那么我们可以创建包含三Pod，每个Pod运行一个服务。或者也可以将三个服务创建在一个Pod，这个取决于用户的应用需求。一个Pod会包含N个Container，多出来的那一个Container是Net Container，专门做路由的。
Service：可以理解为是Pod的一个路由，因为Pod在运行中可能被删除或者IP发生变化，Service可以保证Pod的动态变化对访问端是透明的。
Replication Controller：是Pod的复制抽象，用于解决Pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多份资源，并且根据负载情况动态伸缩。通过Replication Controller，我们可以指定一个应用需要几份复制，Kubernetes将为每份复制创建一个Pod，并且保证实际运行Pod数量总是与预先定义的数量是一致的(例如，当前某个Pod宕机时，自动创建新的Pod来替换)。
Magnum主要服务
接下来看下Magnum中的主要服务，现在主要有两个服务，一个是Magnum-API，一个是Magnum-Conductor。
Magnum-API和其它的项目的api的功能是一样的，主要是处理Client的请求，将请求通过消息队列发送到Backend，在Magnum，后台处理主要是通过Magnum-Conductor来做的。
Magnum现在支持的Backend有K8s，Swarm，Docker等等，Magnum-Conductor的主要作用是将client的请求转发到对用的Backend，Backend在Magnum的官方术语叫CoE(Container Orchestration Engine)
Magnum工作流程
第一步需要创建BayModel，就是为需要提供容器服务的bay创建一些集群的定义规格。
第二步就可以在第一步创建的BayModel基础上创建Bay了，用户可以选择使用Kubernetes或者Swarm，未来还会有Mesos。
第三步，当bay创建完成后，用户就可以通过调用Magnum API和后台的k8s或者swarm交互来创建container了。
Magnum Notes
另外想强调一下，Magnum现在没有调度模块，因为现在支持的CoE有Swarm和 Kubernetes，所以对Container的调度，完全是通过Kubernetes和Swarm本身的调度器来工作的，Magnum只是负责将用户创建Container的请求进行转发，转发到对应的CoE，最终的请求由具体的backend去调度。
Magnum现在也支持对Docker进行管理，但是因为没有调度，目前建议对Docker的管理通过Swarm Bay来进行管理，因为Swarm是Docker官方的Docker集群管理工具。
Magnum现在还支持Multi-Tenant，每个租户可以有自己的Bay，Baymodel，Pod，Service，RC等等，这样可以保证不同租户的资源隔离。每个租户只能看到和操作属于自己的资源。
Magnum现在本身不管理Docker的网络，都是通过上层的CoE自己去管理的，例如Kubernetes的Bay现在通过flannel去管理，其实用的还是Tunnel技术。
Magnum Bay
上图是Magnum目前支持的两个Bay，Kubernetes和Swarm，Bay创建完成后，可以直接通过Magnum API和Kubernetes或者Swarm交互创建Container。
Magnum现在自己通过Swagger实现了一套自己的kubernetes API，Magnum通过kubernetest的Rest-API来和后台的kubernetes交互。
简单总结：Magnum自身作为一套 API 框架，本身调用其它的容器管理平台的 API 来实现功能。目前支持的后端包括 Kubernetes、Swarm和Mesos。
如果说 Nova 是一套支持不同 Hypervisor 虚拟机平台的 API 框架，那么 Magnum 则是支持不同容器机制的 API 框架。Magnum Conductor是整个项目的核心，首先通过Heat部署虚拟机实例或者裸机实例上。然后通过Cloud init在虚拟机实例或者裸机实例上，调用Kubernetes、Swarm或者Mesos部署容器集群。
