多节点 SOA 应用程序的配置管理答案

【问题标题】：Configuration management for multi-node SOA applications多节点 SOA 应用程序的配置管理
【发布时间】：2014-08-14 15:31:14
【问题描述】：

所以这似乎是当今软件中的一个常见问题。许多公司似乎使用 AWS、Azure 或 Heroku 等云平台来解决这个问题。然而，对于需要私有云的数据安全来说，这些选项似乎不太成熟。

详细地说，我的具体需求是管理一个独立于节点（物理/虚拟服务器）的应用程序。目前我们使用 Chef，这似乎不太适合这项任务。在 Chef 中，我需要在环境中的每个单独节点上都有一个运行列表。当我有一个依赖于许多不同服务的 SOA 应用程序时，出于显而易见的原因，我不想将其安装在同一节点上，Chef 无法将其提供给我。我必须手动完成。我必须在内部记录所有依赖项，并且在为每个节点创建运行列表时，必须有人做出决定。没有多节点类型配置选项（环境变量之外）或跨多个节点安装我的服务的自动方式。

这似乎是一个常见的问题，我不得不相信我只是错过了一些东西。肯定有一个工具可以让我比 Chef 更轻松地管理私有云上的 SOA 应用程序。

有人知道这样的工具吗？对我来说，Chef 如此受欢迎并且没有此功能似乎很疯狂。我想假设 Puppet 或其他一些工具可以，但与 Chef 不同，我想在深入尝试使用它之前先了解一下。

用 Chef 术语浓缩我想要的内容：

我想要映射到封装应用程序的环境的角色。我想在 THE ENVIRONMENT 上运行安装，而不是在单个节点上运行。在内部，配置管理软件会对实际安装服务的节点做出某种明智的决定，并相应地更新服务依赖项（例如，通过环境变量）。

换句话说，我希望 CD 成为托管在私有云上的 SOA 应用程序的 CD；不是我对 Chef 的半手动、主要是非连续交付的技巧。

如果那里有来自 opscode 的人（或其他厨师迷），我很乐意承认我可能没有使用 Chef 提供的所有功能，在这种情况下，我想知道目前使用它的人是如何处理我的具体问题。

另外，我所有的服务器都是 Windows 2008 R2 或 Windows 2012，如果这很重要的话。

【问题讨论】：

标签： chef-infra puppet continuous-deployment continuous-delivery

【解决方案1】：

这确实是一个常见问题，小道消息似乎表明 Opscode（我猜现在称为 Chef）已经意识到这一点并正在研究解决方案。希望这是我们将在 Chef 12 中看到的内容。

问题在于 Chef 是一个配置管理系统。它不是严格意义上的供应或编排产品。 Knife 试图解决这个问题，但规模非常初级。其他产品，如 Ansible 和 Puppet，更有能力解决这个问题。但同样，即使它们也不是严格的编排产品，仍然不足。

我自己没有机会使用它，但你应该看看http://deis.io/。它是一个开源、轻量级的平台即服务，似乎可以解决编排问题。它可能是您正在寻找的。p>

另一种选择是使用https://github.com/coreos/etcd 之类的东西进行库存管理。它允许您拥有一个非常灵活的集中式系统库存 API，并且提供的不仅仅是 Chef 自己的搜索数据。有了它，您可以编写说明书来查找其他系统和服务并采取措施连接到它们。它开始变得笨拙，但是您始终可以让 Chef 执行 ssh 命令，该命令在远程实例上执行命令。

无论如何，只是一些建议。希望有帮助。

【讨论】：

我将此标记为答案，因为我认为这是我将得到的最接近答案的东西。在这里的回答和独立研究之间，似乎还没有解决这个问题的灵丹妙药。我会调查你在周末链接的那些产品。谢谢！
+1 令我惊讶的是 opscode（现在是 chef）不接受 Deis 作为推荐的应用程序部署平台。它巧妙地利用了厨师和码头工人。那里有“应用程序”食谱，但关于如何使用它们的示例几乎为零:-(
@Mark：同意。我希望他们尽快解决这些问题。应用程序说明书有点儿笑话：非常复杂，没有很好的文档记录，上周，application_ruby 说明书中有一个错误，完全破坏了它，花了几天时间才得到一个接受的拉取请求。

【解决方案2】：

我想在 THE ENVIRONMENT 上运行安装，而不是在单个节点上运行。在内部，配置管理软件会对实际安装服务的节点做出某种明智的决定，并相应地更新服务依赖项

您正在寻找一种 PAAS 解决方案（平台即服务）。厨师和木偶都不会给你这个。它们是主要为自动化基础设施部署而设计的工具。但是，它们可用于安装应用程序，因为您注意到它们采用了非常基于“节点”的方法。

我不知道任何适用于 Windows 的开源 PAAS 解决方案，因此我建议研究托管解决方案（如 Microsoft Azure）的商业替代方案。

【讨论】：

【解决方案3】：

我没有在 Windows 中使用 Puppet，但 Puppet 与 Facter 捆绑在一起，它提供了对自定义事实的支持 - http://puppetlabs.com/blog/facter-part-1-facter-101

facter 的所有变量都可用于 puppet 清单，因此您可以创建在不同环境中执行不同操作的运行列表。

此外，您提到了应用程序而不是节点的配置——这就是 Puppet 模块的用途，您可以轻松地创建自己的模块。这将允许不同的节点应用某些模块，忽略其他模块，甚至确保该模块不存在。

【讨论】：

非常有趣的博客。 Cheers For balance Chef 允许环境特定的角色或角色及其相关运行列表之间的环境差异。环境配置也可以配置。

【解决方案4】：

我很惊讶没有提到 RightScale、Scalr 或 enStratus。这些解决方案中的大多数填补了 SOA 交付的空白，并具有根据需要灵活调整 SOA 部分的额外好处。

【讨论】：

【解决方案5】：

我知道这不是 100% 的胜利，但如果我正确理解您的问题，它会有所帮助。我们使用定制的食谱（显然），但具有角色意识。我的意思是如果我们启动一个新的应用程序服务器，我们的负载均衡器会自动更新新的服务器信息。您可以使用

来实现它

appservers = search(:node, "role:applicationServer")

并对其进行自定义以使其适合。

就自动缩放而言，我们有自己的 python 脚本来处理它。

【讨论】：