软件容器不同于托管它们的虚拟机和虚拟层，它们需要一套完全不同的管理工具，以便在大型企业、超大规模数据中心和云环境中被使用。我们无法用Docker全面替代虚拟层，并且想当然地认为所有东西都能够正常工作。现实情况要比这复杂的多。
更为重要的是，Docker和OpenVZ、Rocket、LXC等容器解决方案正在将软件和它们的运行时打包、管理，并逐渐开始分解和孤立“微服务”应用的模块，因为它们不仅能够在独立的服务器集群中被升级、管理和迁移，同时还能够继续协同工作。这种在不为系统和网络性能增加过多的虚拟化日常开支情况下，管理软件堆栈的能力是HPC和分析领域中广泛部署容器的原因之一。而在HPC和分析领域中，流行使用裸机已经有很长的时间了。
在OpenStack世界，由OpenStack联合创始成员Rackspace主导的Magnum项目虽然是一个相对较新的项目，但是它们扮演了一个重要角色。可以肯定，在即将于5月18日在加拿大温哥华开幕的OpenStack Summit上，Magnum项目将成为一个热门话题。Rackspace首席架构师兼Magnum 容器即服务团队主管Adrian Otto日前与The Platform.net网站就Magnum项目，以及对其成熟时的期望值展开了一些探讨。（Otto还担任由Rackspace与Canonical、Cloudsoft、Cumulogic、Docker、eBay和红帽于2013年10月联合推出的Solum项目的主管。）
Magnum项目推出的同时，OpenStack社区内部的技术人员也在考虑应该如何管理容器。在Linux世界，管理容器至少由控制组和命名空间两大核心功能组成，这两大功能类似于搜索引擎巨头谷歌开发的隔离大型基础设施中工作负载的技术。谷歌在过去八年中一直在为这些功能提供帮助，帮助将这些功能植入到Linux内核当中。
Otto称，起初虽然未必每个人都会认同，但是他还是建议将现有的OpenStack计算控制器Nova拓展用于控制Linux环境中的容器；最终致力于解决这一问题的技术人员认识到，容器完全不同于虚拟机，他们的管理系统也完全不同于其项目所使用的虚拟层。
Magnum项目由此诞生。它们所做的工作是实现OpenStack与集群中的容器管理系统的互动。这其中包括用于Docker容器和谷歌Kubernetes的Docker Swarm。Docker Swarm不仅能够控制Docker容器，还可以为CoreOS 的AppC容器格式提供支持。此外，它们还可以与针对容器的flannel虚拟网络服务实现协作。
目前，CoreOS正在考虑将flannel虚拟网络服务作为其Tectonic容器管理系统的一部分。尽管这些容器管理系统对于他们的工作来说已经足够了，但是出于多种原因，他们还需要像OpenStack这样的云控制器系统。首先，企业创建云的目的可能是希望拥有许多在其集群上运行的Swarm和Kubernetes实例，为（运行在公有云上的）客户、工作负载或（企业中的）业务部门提供所需要的隔离。一些东西必须要为每个独立的Swarm或Kubernetes集合管理资源分配。
其次，Magnum可以作为一个适合不同容器工具管理风格的接口。Otto说：“OpenStack不会对用户所选择的虚拟化或网络类型有所挑剔，我们也不会对用户所选择的容器技术有所限制。”这意味着如果用户希望接入支持LXC、OpenVZ、rkt或其他容器格式与运行时的容器管理系统，那么Magnum的可插入式架构将使之成为可能。
Otto称，Magnum支持并不仅仅局限于Linux，即便是目前现有的容器也可以某种形式使用控制组和命名空间。正如我们之前所报道的那样，微软正在将Windows Server容器和Hyper-V容器这两个不同类型的容器整合至Windows Server 2016（也就是之前所说的Windows Server 10）之中。这两个容器都可以由Docker Engine管理。很自然地，Magnum最终将能够覆盖Docker或微软自己的容器管理工具，以管理OpenStack云中的微软容器与虚拟层技术。
Otto在谈及对Docker非常友好的Windows Server 版本时说：“我认为，在用户能够真正使用之前还需要数年开发时间，不过这真的非常重要。”
在单个云控制器中实现多种类型的虚拟化这一理念并不是什么新东西。Rackspace自己有两个针对Nova计算控制器的不同驱动。一个是针对公有云使用的是Xen虚拟机，另一个使用的是由OpenStack的Ironic功能所提供的裸机实例。后者已经做好了在黄金时间使用OpenStack最新的Kilo版本（在4月30日刚刚发布的2015.1.0版本）的准备。此外，Rackspace还有一个用于创建Windows和Linux机器的主机聚合驱动，因为这种让两种类型服务器共存在其集群中的方式与众不同。
“Magnum会为OpenStack配置服务Heat请求计算实例，但是它们并不在意提供的是哪种类型的计算实例。它们可能来自裸机服务器的Nova，也可能是运行在Xen或KVM上的Nova虚拟机，或者是运行在其他容器内部的实例。这样一来，我能够拥有自己的容器操作环境，而这个环境运行在容器内部。这听起来可能有点让人感到混乱，但是这恰恰是我们想这么做的原因。因此我们并不在意底层云使用的是哪种virt驱动。”Otto说。
目前，Rackspace正在运行一项基于容器技术服务的内部前瞻版，该版本的基础是libvirt-lxc驱动，而该驱动正是之前OpenStack Havana版本的一部分。顾名思义，这一针对Magnum的驱动能够到达并控制LXC容器。预计2015年下半年就可以在Rackspace 云上使用该产品。
展望未来，Otto认为，Rackspace必须要解决如何将容器与虚拟网络结合在一起的问题。尽管还没有做出任何决定，但是这一理念与一起使用虚拟机的解决方案类似。在它们上面不必增加任何管理层，用户使用虚拟交换机就可能将容器彼此连接在一起。在即将召开的OpenStack Sunmmit上，将做出决策的一个大问题是，针对虚拟机的Neutron虚拟网络功能如何实现与针对容器的虚拟网络的整合。在许多情况下，企业将在虚拟机内部运行容器，与单独使用虚拟机相比，前者可以提供更高的安全性和更好的资源隔离。
在OpenStack的众多项目中，Magnum还是一个相对较新的项目。OpenStack社区在2014年11月才接受其首个提交，并在2015年3月底了推出其首个版本。Otto称，Magnum的复杂程度不亚于在OpenStack项目早期阶段出现的Nova控制器。得益于所有工作的不断推进，以及OpenStack开发者在开发Nova过程所积累的丰富经验，Magnum在OpenStack计划于2015年10月推出的“Liberty”版本时将进入生产级。不过，这还将取决于温哥华OpenStack Summit上，OpenStack社区如何决定Magnum项目的发展方向，以及多长时间能够编写出所确定功能的代码。
