我们有一个特定于应用程序的食谱，有三个食谱
配方1.在服务器上创建存储
配方2.安装ngnix
配方3.安装JBOSS
配方1，需要属性来告诉它应该为ngnix和Jboss创建多少逻辑卷以及大小。
我们还有三个角色，分别是web-server，app-server和standalone。独立角色将所有3个配方聚合在同一个VM上。但我们希望在Production中使用Web服务器和app-server角色。
现在的问题是如何分割存储属性，因为我们不希望为Web服务器角色配置Jboss FS。
我们希望将存储属性放在角色中，但这显然是一种反模式。
将属性放在食谱中意味着我们必须在食谱2和3中包含食谱1，因为Jboss食谱只是安装Jboss而不用担心存储，对吧？
有没有很好的方法来实现这个目标？
答案 0 :(得分：1)
假设web-server，app-server和standalone都是单独的食谱，只需将数据放入web-server和app-server的属性文件中。
在web-server中你会有类似的东西：
# attributes/default.rb
default['mystorage']['nginxdata'] = 2 # Some size
# recipes/default.rb
include_recipe 'myapp::storage'
include_recipe 'myapp:nginx'
并且在app-server中你可能有类似的内容：
# attributes/default.rb
default['mystorage']['jboss1'] = 2 # Some size
default['mystorage']['jboss2'] = 2 # Some size
# recipes/default.rb
include_recipe 'myapp::storage'
include_recipe 'myapp:jboss'
在您的存储配方中，只需迭代数据即可创建卷：
node['mystorage'].each do |volume_name, size|
# Something ...
end
答案 1 :(得分：1)
将此作为答案，因为评论在格式化方面不够清晰。
我非常怀疑nginx或jboss安装方法因您的应用程序而异，因此您只需要覆盖应用程序菜谱中的属性。
所以你最终得到了coderanger的答案：每个基础设施工作1个烹饪书（nginx，jboss，存储）
然后1个应用程序食谱 - 将此应用程序的属性值提供给基础结构烹饪书。 - 取决于特定版本的基础架构烹饪书 - 有3个食谱： - 1包括存储和nginx - 1包括存储和jboss - 1包括前两个（不要打扰，2 include_recipe为同一个不会有问题，厨师足够聪明，只包括一次）
在您的节点上，您将使用其中一个配方设置运行列表。 您可以控制在特定时间使用您的应用程序实际设置的jboss或nginx版本（您不能使用角色）
属性加载和配方编译的工作方式将使您的应用程序cookbook属性覆盖nginx cookbook中的属性（例如），然后将编译nginx的配方。
确保include_recipe nginx / jboss在您的应用程序部署代码之前，因此您确定在尝试部署之前已经设置了nginx / jboss。
揭露我的情况（我认为不是你的情况）：
我们有53个内部应用程序，53个cookbook设置属性（例如jvm选项）。 我们有20个应用服务器对，因此大约有60个烹饪书（1个用于群集，1个用于群集中的每个实例）
每个实例cookbook都设置服务器名称和部署目录。 每个群集菜谱都依赖于应用程序烹饪书，并包含他们的食谱（使用预先提到的部署目录）
有一些像berkshelf这样的工具可以帮助你用版本约束来维护整个链。
起初听起来很复杂，但随着时间的推移，它可以帮助您避免生产中的无意更改，因为您对分段进行了更改并忘记了它将被传播（带有角色）。