编者的话： 我们今天来看看被寄予厚望的OpenStack容器项目的发展走向。Magnum项目的PTL Adrian Otto将为我们介绍Magnum的工作方式，以及它到底能够帮助我们解决哪些问题。
到现在我们似乎都难以平复对容器这一当前即是老技术又是新技术的兴奋之情。在OpenStack东京峰会上，我们从Rackspace杰出架构师 Adrian Otto那里获得了一些关于Magnum 项目的内部消息。Otto为我们介绍了OpenStack的容器即服务项目能够真正为我们解决的问题。 超大型项目 作为Magnum项目的PTL，Otto在多个大型会议中介绍过这个OpenStack的容器项目。东京峰会上，Otto重新升级了Magnum项目的相关数据，具体如下：
Otto说：“这表明我们正在评估代码。在提交给上游部门之前，我们正在努力完善代码，不过我们并没有对这一代码做出过多的修改。我们只做了很少的修改就能够让它们变得更好。这些代码正在被人们所接受，而且这一接受速度并不慢。” Magnum的愿景 Magnum过去在OpenStack中被作为一级资源容器。“由于我们已经实现了这一功能，因此这种用途已经过时了。如今，Magnum的用途是将最好的基础设施软件与最好的容器软件整合在一起。我希望所有的人都认识到，容器软件是无法解决我们的问题的。”Otto说。 反驳争议 Otto表示，“关于容器是什么”还存在着许多争议。如果有人认为容器像虚拟机一样，只是体积更小、速度更快，那么我们只需要做这一件事，那就是反驳他们。 他说：“如果他们这么说，那么我们可以据理反驳。容器与那些运行在主机上的程序密切相关。我们可以关闭它们，启动它们，设置它们的环境变量，绑定文 件系统卷，将终端与它们连接在一起，在它们中运行程序。”将这些功能都添加至OpenStack的计算项目Nova中是不合适的，因此他们决定创建一个带 有自己的API的新项目。
Magnum能解决什么？ Otto表示，当尝试在容器上运行应用时出现的大多数问题都是基础设施问题。这些问题包括：“我如何与我们的网络连接在一起？”，“我利用自己的存 储能够做哪些工作？”，“我的地址来自哪里？”，“这些事情是如何联系在一起的？”，“我如何编排它们？如何扩展它们？”等等。 容器软件能够在应用层提供帮助，帮助打包和分发，但是它们并不能解决基础设施层面的所有问题。他补充说：“Magnum正在尝试整合一些解决方案，以解决所有的这些问题。”  Bay Magnum是一个额外的服务，允许我们创建一个新的实体，即一个名为Bay的新的云资源。Bay中有我们的容器编排引擎（COE）。通过Liberty版本，我们可以运行Docker Swam、Kubernetes和ApacheMesos。 Bay的设计初衷是为用户提供原生工具体验，它通过DockerCLI 或Cube CTL命令挑战集群。 Otto说：“我们能够享受到不同COE自带的功能，不需要Magnum团队再在它们上面创建一些东西才能使用这些功能。我们还可以依靠Magnum创建Bay并扩展这一基础设施，随后我们可以通过原生工具交互和创建容器，以及管理容器。” 容器DIY Magnum还提供了一个创建容器的功能。对此，Otto已经在加拿大温哥华OpenStack峰会上详细介绍过。该功能允许我们在Kubernetes上创建一个端口，不过我们需要选择以原生的方式运行它们。根据我们所选择的Bay，我们可以获得不同的原生API体验。 Node Node实质上是Nova实例。一个Bay可以是一组Nova实例，因此目前Magnum中的所有Bay至少有三个抽象。 Pod Pod是一组共同运行在同一个主机上的容器。该服务能够将网络端口与容器连接在一起；Bay是一组Nova实例；Node则与相关的Nova实例一一对应。 Liberty版本的新增功能 Otto谈及了他喜欢的Magnum功能，例如Mesos Bay Type、SecurityBays (TLS)、外部负载均衡支持，以及Kubernetes的Multi-Master功能等。
未来会怎样？无法抑制的兴奋 Otto 说：“我最为自豪的是来自28个不同机构的101位工程师之间展开的通力协作。我们都感受到了这一新技术为我们指引的方向，这是一件非常值得高兴的事情。” |
