openstack 容器

容器是当前计算中的热门话题。 它们是用于部署应用程序的有效方法。 但是，当复杂的应用程序在多个容器之间拆分时，事情会变得有些复杂。 发生这种情况时，容器需要能够有效地协同工作，这就是容器编排的目的。编排器可以促进容器的管理，并确保它们可以按照所需的方式进行连接和协作以正常运行。

在云环境中，有许多不同的容器编排工具，那么管理员如何选择最适合他们的解决方案？ Gigaspaces的创始人兼首席技术官Nati Shalom及其几个同事将在温哥华OpenStack峰会上的演讲中帮助管理员回答这个问题。 他们的演讲将探讨几种不同的容器编排工具之间的差异：Kubernetes，Heat，Fleet，MaestroNG和TOSCA，并提供最佳实践，以针对不同的用例选择理想的解决方案。

我们采访了Nati，以了解有关在温哥华OpenStack峰会更多信息以及他对容器，业务流程和OpenStack的未来发展有何看法。

在不花太多钱的情况下，您在OpenStack峰会上的演讲与会者能期望得到什么？

演讲的重点是流行的编排方法，概述了一般差异和潜在的协同作用，然后探讨了一些最佳实践，以了解如何为正确的工作选择合适的工具。 由于我们最终有时间限制，因此我们可能无法展示每个工具的实时示例或比较整体用户体验，而将主要关注通常会导致语义差异的各种编排方法之间的差异。

要回答这个问题-云管理员首先需要问自己一些关键的合格问题。 所有这些都将为工作带来最佳的工具/解决方案。 首先，我将根据您的环境来划分这些问题，然后询问您要使用哪些工具来管理这些环境，最后是要寻找的编排级别是一个项目，还是更长的时间？ -term或全局以及应用程序堆栈注意事项。

因此，最重要的是，您需要考虑您的环境是仅OpenStack，仅容器还是混合模型，例如旧版基础架构（即vSphere或物理硬件）。

如果您仅在OpenStack环境中，那么首选将是Heat以及其他互补堆栈的集成，以处理软件配置，监控，工作流，策略等。其中一些可能来自OpenStack的项目，在某些情况下，它可能来自OpenStack。最好选择一个相关的开源项目。 如果您打算迁移到仅容器环境，那么您的首选可能是Docker。 按照今天的现状，您需要集成大量互补的堆栈来处理日志记录，监视，工作流，例如，Kubernetes提供了专门针对的更高级的编排。 如果您的世界更多是由容器和配置管理工具（Puppet，Chef，SaltStack）以及私有云（OpenStack，VMware）或公共云（Amazon，Google）组成的，那么最好的选择就是基于TOSCA编排-也与基础架构和工具链无关。 显然，不用说，如果您已经对Chef或Puppet进行了大量投资，那么最好的选择就是编排工具，该工具内置了对此类框架的支持。

接下来，问题是您是在寻找针对特定产品/项目的业务流程，还是作为许多应用程序的通用解决方案，而这在这里变得更加棘手。

许多产品都具有针对该应用程序的特定用例量身定制的编排–一个很好的例子是Cloud Foundry / Bosh或Hadoop / Yarn。 其他编排工具带有通用解决方案以及用于特定应用程序的内置模板，并且每个模板都有一定的优势。 例如，有些编排工具针对网络应用程序（例如NFV）或针对大数据进行了调整，因此即使在我使用通用编排工具的情况下，我也会寻找最合适的编排工具。我的目标工作量。

另一个重要标准是可嵌入性，将业务流程工具作为另一产品的一部分与选择业务流程工具来运行数据中心操作大不相同。 在这种情况下，我将寻找一种轻量级的解决方案，该解决方案可以以最小的运行时开销使用，可能仅用作库。 您还需要决定是否要寻找一个完整的生命周期流程，其中还应包括部署后的方面（监视，自我修复和自动缩放），或者主要是安装或配置。

一些业务流程工具将自己限制在大部分安装阶段，但是一些业务流程工具为部署后的管理任务提供了更广泛的方面，涵盖了应用程序的整个生命周期，包括监视，更新策略，扩展和自我修复。 。

最后，了解网络，DevOps工具链，监控和语言方面的堆栈外观非常重要。 许多DevOps环境由一系列开源项目组成，用于处理日志记录，监视以及生命周期的其他方面。 这套工具往往变化很快。 一些业务流程工具内置了针对此类工具的集成，但是在向组合中添加新工具时最终受到很大限制。 在工具恰好是它们自己的集群的情况下尤其如此，因此需要在应用程序编排和特定于工具的编排之间建立更高级的关系。 在这种情况下，我们将进行业务流程的编排-一个很好的例子是应用程序业务流程和网络业务流程，或者应用程序业务流程和大数据业务流程，其中应用程序业务流程需要交互并将责任委托给工具业务流程。

您是否看到格式之间的融合？ 还是一两个胜出云计算的其余部分？

从我所看到的，我敢说，将有可能成为三个主要阵营：

• 仅适用于Docker（或主要适用于Docker）-将用Go编写的工具，并将是当前Docker项目的扩展。 最主要的框架可能来自Docker本身（Swarm，Compose或Machine）。
• 特定于基础架构的工具-这些工具将提供映射到特定基础架构的大多数核心功能，该组主要针对仅对在特定环境中部署应用程序感兴趣的用户。 Amazon Cloud Formation或OpenStack Heat是此类中的好例子。
• 混合-用于自然混合环境的编排，包括Docker以外的其他技术堆栈（例如Chef，Puppet或Ansible）或云（例如VMware，OpenStack，AWS等）。我认为TOSCA将成为有意义的鉴于其内置的中立性，该组的主要编排规范选择。

纵观更广泛的OpenStack峰会，您在温哥华最兴奋的是什么？ 您认为我们会看到哪些大主题？

NFV（网络功能虚拟化）和客户使用案例，使我们了解客户如何实际使用OpenStack令人兴奋。 我还希望听到有关OpenStack路线图的更多信息，以了解计划形成下一个版本并参与这些讨论的内容。 最后，建立网络：峰会始终是与开发人员和决策者会面的唯一场所，只是发现人们参与并为该项目做出贡献的所有令人兴奋的方式。

作为一个重点关注下一个版本的项目，对于OpenStack来说，什么是重要的？ Liberty版本可能带来什么，尤其是在编排方面？

我个人认为，如果OpenStack能够找到一种方式，使更多的云提供商能够增加对OpenStack的支持，其中包括那些被视为与OpenStack竞争的竞争对手，例如AWS，Google和Azure，那么OpenStack将会更加成功。 同样，如果能够找到鼓励其他流行的开源项目对OpenStack进行本机支持的方法，那么它将取得更大的成功。

我认为到目前为止，人们一直在关注使OpenStack成为Amazon的替代产品。 我认为，这种策略导致将OpenStack项目分散到许多项目中。 我认为VMware对OpenStack的支持就是一个很好的例子，说明了潜在的竞争对手基础架构如何与OpenStack兼容。 如果我们可以使其他基础架构提供商更轻松地将OpenStack兼容性添加到OpenStack API中，那么与仅专注于使OpenStack成为可行的竞争替代产品相比，我们将获得更多的收益。 基本上，我会说包容性是本质，而不是排他性：开源方式。

在业务流程的背景下，我认为Heat最好成为其他业务流程框架到OpenStack的集成点，例如我的演讲中提到的框架。 在这种情况下，通过Heat转换器项目，为Heat添加对TOSCA的支持听起来像是朝着正确方向迈出了一步。

在我看来，OpenStack Kilo和Liberty带来的令人兴奋的功能是添加了最适合私有云环境或NFV的独特性能的功能。 这包括对裸机（Ironic）和即将到来的共享文件系统（Manila）的支持，以及高级调度规则，可以更好地控制资源利用。 我个人认为，将Ironic与容器结合使用将带来一个数量级的更好的性能和利用率，因此，将使选择OpenStack背后的ROI争论更加明显。

话虽如此，我认为Kilo公告中的主要新闻是新闻不多！ 显然，这有力地表明，OpenStack项目最终将朝着其现有核心服务的稳定性和完整性迈进，而不是不断扩展到新的领域。

您还有什么想补充的吗？

由于本次演讲的主题可能相当广泛，对于那些有兴趣看到我们涵盖特定感兴趣领域的人员，我欢迎提出任何评论或建议。 我也要感谢那些已经使用过这些工具的人提供的指导，您可以在找到我我很乐意将我的演讲作为观众希望看到的内容。

此外，这是一个很好的机会，可以提到世界各地还有其他OpenStack活动，对所有无法到达温哥华的人们进行了精彩的演讲，我鼓励所有无法参加的人进行检查仅以示例为例，在峰会之后几乎立即进行了一次出色的EMEA OpenStack Days欧洲之旅。 我专门参与了的组织，这是其中之一，我们将有来自世界各地的优秀演讲者，主要是来自德国电信的Axel Clauberg，我认为领导着迄今为止最雄心勃勃的OpenStack项目之一。

本文是针对的一部分，该 为期5天，面向OpenStack云软件的开发人员，用户和管理员 。

翻译自:

openstack 容器