容器技术目前在计算领域可谓炙手可热。它们能够以高效而切实的方式帮助我们完成应用程序部署工作。不过当复杂性较高的应用程序被拆分至多种容器当中时，情况将因此而变得更加复杂。面对这种情况，容器机制往往需要能够更为有效地彼此协作，而这也正是容器编排方案的诞生意义。编排机制能够简化容器体系的管理难度，从而确保不同容器之间能够顺畅对接并以适当的方式实现协作，从而最终达成我们为其赋予的功能预期。
云环境之下的容器编排类工具可谓多种多样，那么问题来了——管理员应该如何从中挑选出最适合自己的解决方案?Gigaspaces公司创始人兼CTO Nati Shalom和他的几位同事就这一话题展开了探讨，希望能够帮助管理员们通过本次OpenStack温哥华峰会找到上述问题的答案。他们的对话将主要围绕几款不同容器编排工具之间的差异而展开，其中包括Kubernetes、Heat、Fleet、MaestroNG以及TOSCA。除此之外，他们还将提供适用于不同用例的、能够切实帮助各位挑选出理想解决方案的***实践。
Nati将在本次OpenStack温哥华峰会上以主题演讲的形式带来更多信息，我们的关注重点则集中在他如何看待容器、编排机制以及OpenStack的未来发展方向层面。
Q：如何从最简洁的表达出发，您希望各位与会者能够在此次OpenStack峰会当中获得怎样的启示?
A：本次对话主要关注各类热门编排方案，旨在勾勒出各方案之间的主要差异以及潜在协同疚——而后深入剖析***实践，探讨如何针对特定任务选择正确的工具。由于我们的时间有限，因此我们恐怕无法为每款工具提供现场示例或者从整体用户体验层面作出比较，不过专注于解决各类编排方案之间、经常导致语义区别的差异之处。
为了回答这个问题——云管理员需要首先整理出几个关键性的待验证问题。其中每一个问题可能都会为当前任务带来某种***工具/解决方案。我会根据大家的具体环境将这些问题进行分类，而后参考大家在管理这些环境时所使用的具体工具，***是考量各位需要的编排机制属于哪种层级——到底是面向特定项目的一次性方案还是面向长期或者全局的通用型方案，再将其与应用程序堆栈结合并进行综合评估。
因此作为***步，大家需要考虑自己的运行环境到底属于纯OpenStack、纯容器还是可能包含有传统基础设施的混合型模式(例如vSphere或者物理硬件)。
如果大家选择的是纯OpenStack环境，那么各位的***选项肯定是Heat。将其与其它互补性堆栈相结合能够很好地完成软件配置、监控、任务流程以及管理政策等日常工作。其中一部分可能由OpenStack下辖的项目直接提供，而某些情况下大家可能应该更倾向于使用其它相关开源项目。如果各位有计划迁移至纯容器环境，那么***方案很可能会是Docker。就目前的情况看，我们需要整合一大堆互补性堆栈才能实现常见的日志、监控以及任务流程管理工作——举例来讲，Kubernetes能够提供一套专门面向微服务架构的高级编排方案。如果大家的环境属于包含有容器、配置管理工具(例如Puppet、Chef以及SaltStack)、私有云(例如OpenStack以及VMware)或者公有云(例如Amazon以及谷歌)的混合型体系，那么最理想的选择应该是基于TOSCA的编排方案——其同时不会对基础设施以及工具链的具体类型提出任何限制。很明显，上述结论并不包括已经在Chef或者Puppet等工具身上投入了重金的现有客户，在这种情况下我们的***方案是选择那些能够以内置方式支持此类框架的编排工具——毫无疑问。
接下来的问题在于，大家到底是希望这套编排方案仅仅针对单一产品/项目，还是要选择一套适用于多数应用程序的通用型机制，而后者的具体效果当然会更好一些。
很多产品本身就自带编排方案，而且其针对该应用程序的特定用例进行了量身订做——最明显的例子就是Cloud Foundry/Bosh以及Hadoop/Yarn这两套组合。其它编排工具则通常属于通用型解决方案，其中内置在面向各类应用程序的模板，它们在某些情况下也能带来良好的表现。举例来说，一部分编排工具专门针对NFV等网络应用程序进行了优化与调整，其它一些则主要面向大数据类用例，因此在这方面即使我个人更倾向于选择省力省心的通用型编排工具、但必须承认专用方案才最破例我自己的目标工作负载。
另一大重要考量标准就是可嵌入能力，将编排工具作为另一款产品的组成部分可不像为自己的数据中心运营体系选择编排工具那么简单。在这种情况下，我一般会考虑那些能够将运行时负担控制在***程度的轻量级解决方案，其往往只属于一套代码库。大家也许还需要决定自己到底是要选择一套能够面向整个生命周期内各个后部署层面(包括监控、自我修复以及自动规模伸缩)的编排工具，还是单纯强调安装或者配置流程。
一部分编排工具将自身限定为了主要用于处理安装流程，但也有一些编排工具能够涵盖应用程序整个生命周期当中更为广泛的后部署管理任务——其中包括监控、更新政策、规模伸缩以及自我修复等等。
***，很重要的一点就是了解自己的堆栈在网络、DevOps工具链、监控以及语言等层面到底表现出什么样的面貌。很多DevOps环境都是由一系列开源项目所构成，这些项目各自负责日志、监控以及生命周期中的其它各方面工作。这类工具组合的发展变化速度很快。一部分编排工具当中内置有用于此类工具的整合机制，但其实际效果在将新型工具纳入整个体系时仍然比较有限。这种情况在此类工具恰好属于其自有集群的一部分时表现得尤为突出，因此我们需要在应用程序编排与特定工具编排之间找到更为明确且可行的高级关系。考虑到这一情况，我们最终需要编排领域中的编排工具——最明显的例子就是应用程序编排与网络编排，或者应用程序编排与大数据编排，其中应用程序编排机制需要与工具编排进行交互并将一部分职责分配给后者。
#p#
Q:您认为不同格式之间正在出现汇聚趋势?或者说，其中一到两种最终是否会在云环境下压倒其它备选方案?
A:从我的角度来看，我敢说未来很可能形成三大阵营并立的局面：
1.纯Docker(或者大部分由Docker构成)——此类工具将由Go语言编写而成，且将作为现有Docker项目的扩展成果出现。在这一阵营中，大部分占主导地位的框架可能都将由Docker自身所提供(例如Swarm、Compose或者Machine等)。
2.特定基础设施——这些工具将大部分负责提供映射至特定基础设施的核心功能，此阵营的主要目标面向那些有意将应用程序单纯部署在特定环境下的受众群体。Amazon Cloud Formation以及OpenStack Heat正是这一类别中的典型代表。
3.混合型——对于各类环境而言，其编排机制天然拥有混合属性，其中包含有大量除Docker之外的其它技术堆栈，例如Chef、Puppet或者Ansible，又或者VMware、OpenStack以及AWS等云方案。我认为在这一阵营当中，TOSCA很有可能成为其最为重要的特定编排选项，这也是由其内置中立性所决定的。
Q:纵观这次涉及范畴极广的OpenStack温哥华峰会，其中最令您感到兴奋的内容是什么?您认为未来我们面前又会出现哪些重大的发展议题?
A:在NFV(即网络功能虚拟化)以及客户用例范畴，我们了解到客户们如何实际使用OpenStack，这一点非常令人兴奋。我当然也希望听到更多与OpenStack发展路线图相关的消息——只有对未来版本内正处于规划中的内容有所了解，才能作出更有针对性的探讨。***一个问题的答案是，网络：峰会一直是与开发人员及决策制定者们进行交流的一片独特舞台，我们也能在这里了解到与人们接触并为OpenStack项目作出贡献相关的令人振奋的消息。
Q:作为OpenStack这样一个项目，在未来的发展过程中需要关注哪些重点内容?Liberty版本会带来哪些新特性，特别是在编排方面?
A:我个人认为，OpenStack如果能够能够找到正确的途径、引导更多云服务供应商为其提供或者添加支持，那么这一项目的未来成功将更有保障，其中包括那些被广泛视为OpenStack竞争对手的AWS、谷歌以及微软Azure。同样的，如果OpenStack项目能够以类似于其它高人气开源项目的方式激励人们为其提供原生支持，那么其未来同样会更加光芒四射。
我认为到目前为止，人们的大多数关注重点还集中在OpenStack作为Amazon替代方案的可能性层面。就我个人看来，这样的战略思路可能会导致OpenStack在大多数实践项目中缺乏施展空间。我觉得VMware为OpenStack提供支持就是个很好的例子，它证明了潜在竞争对手的基础设施同样可以与OpenStack相对接、相兼容。如果我们能够简化其中的流程及难度，引导其它基础设施供应商将OpenStack兼容能力并入OpenStack API，那么我们所获得的成就将远远超过单纯将OpenStack作为一套可行的竞争性替代方案。基本上，我认为包容性而非排他性才是至关重要的，这也正是开源的基本原则。
如果从编排机制的角度思考，我认为***的方式就是让Heat能够成为其它编排框架与OpenStack相融合的集成点，也就是我们之前谈到过的那些框架方案。在这种情况下，将TOSCA支持能力添加到Heat当中也将成为正确的发展步调，从而通过Heat翻译器项目为OpenStack带来明确的下一步发展方向。
在我看来，OpenStack Kilo与Liberty所带来的各类令人兴奋的功能特性都是在纳入众多最适合私有云环境或者NFV的独特能力。其中包括对裸机的支持能力(Ironic)，即将推出的共享文件系统(Manila)再加上允许用户对资源利用进行进一步控制的高级调度规则等。我个人觉得，Ironic出现在容器体系当中将把性能表现与资源利用水平提升到新的量级，而且这样一来企业客户在针对OpenStack项目进行投资回报讨论时、也能得到更有说服力的分析结论。
必须强调的是，我认为Kilo发布所透露的核心消息在于，如今OpenStack已经没那么多新消息可曝光了。很明显，这一迹象证明了OpenStack项目已经最终走向稳定，其目前追求的是核心业务的完整性、而非不断向其它新型领域扩展。
Q:您还有什么要补充的内容吗?
A:由于这次对话的主题可以非常宽泛，因此我欢迎大家通过评论观点或者建议告诉我们更多探讨哪些各位感兴趣的领域。我也乐于看到大家在使用过程中就OpenStack本身或者相关工具所总结出的经验，各位可以点击此处访问我的Twitter。总而言之，我希望自己的对话能够尽可能多地涵盖听众朋友们感兴趣的内容。
除此之外，我也要借此机会提醒各位，接下来世界范围内还将陆续召开一系列其它OpenStack活动，因此没能来到温哥华的朋友们也不必灰心。而且我强烈建议各位没能到场的朋友点击此处查看相关日程安排，就在本次峰会结束后一场激动人心的OpenStack Days秀也将马上开始自己的欧洲、非洲与中东地区旅程。我个人将参与到OpenStack以色列大会中去，在那里将有来自世界各地的宣讲人分享自己的真知灼见——其中最值得一提的就是来自德国电信公司的Axel Clauberg，在我心目中他所主持的OpenStack项目可谓迄今为止***野心的发展成果。
原文标题：How to orchestrate containers in OpenStack
