我是 Chef 新手（使用托管 Chef 服务器），还算熟练，基本了解如何配置单个服务器。我遇到的麻烦是弄清楚如何将各种配置的服务器集成到一个功能集群中。
在我当前的用例中，我使用的是 Amazon EC2。我使用带有几个 varnish 服务器的负载均衡器，这些服务器将请求传递给连接到 RDS 服务器的几个前端应用程序服务器。我还有一个后端实用程序服务器，它必须偶尔将一些文件同步到 FE 应用服务器。
您将如何将所有这些粘合在一起？FE 服务器需要了解 rds 实例和 redis 服务器，但后端实用程序服务器和 varnish 节点必须了解 FE 应用服务器。理想情况下，应用服务器将实现某种自动扩展，根据需要配置更多节点。
最后，还需要有开发和阶段环境，其中 varnish 服务器通常与应用服务器位于同一虚拟机上。
您是否使用标记来注册 FE 节点，然后在最后在 varnish 和 BE 服务器上运行配方时查询这些值？
我只是在寻找一些我认为相当常见的 n 层 Web 集群用例的最佳实践。
答案1
您的问题没有说明您使用的是 chef-client 还是 chef-solo，因此我假设使用前者。
由于 Chef 服务器正在索引您节点的所有已知属性，因此您可以使用搜索功能根据任何属性（例如，其运行列表的内容或您已分配给节点的任何标签）来定位节点。假设您有一个设置 redis 服务器的配方（或角色），则配置您描述的 FE 应用服务器的配方可以搜索运行列表中具有 redis 配方的节点，并使用该节点的属性填充应用的配置文件。同样，配置 Varnish 服务器的配方可以搜索您的应用服务器并使用其地址填充 Varnish 配置文件。
环境可以看作是一种特殊的标签，当您只想了解属于同一逻辑集的节点时，可以使用它来限制搜索查询的范围。除了充当标签之外，Chef 环境还可用于覆盖节点属性并强制实施食谱版本锁定。
这两种结构都不能直接用于发现你的基础设施中不能直接运行 Chef 的部分，比如 RDS，但是你可以在你的配方中使用“原始”ruby，所以多雾路段或者right_aws将允许您查询 AWS API 以获取已配置资源的详细信息（例如，存在哪些 RDS 实例以及它们的地址是什么），并且您可以使用已应用的任何标签过滤结果。
通过将 fog 之类的库与 Chef 的搜索功能相结合，您应该能够找到通往云集成自动化天堂的道路。直到下一次美国东部发生重大中断。