Chef infra Chef-用于设置角色特定属性的模式

我们有一本特定于应用程序的食谱，其中包括三种食谱

• 配方一。在服务器上创建存储

• 配方二。安装ngnix

• 配方三。安装JBOSS

配方1需要属性来告诉它应该为ngnix和Jboss创建多少逻辑卷以及大小

我们还有三个角色，分别是web服务器、appserver和standalone。独立角色将所有3个配方聚合到同一个VM上。但我们希望在生产中使用web服务器和应用程序服务器角色

现在的问题是如何分割存储属性，因为我们不想为web服务器角色配置Jboss FSs

我们希望将存储属性放在角色中，但这显然是一种反模式

将属性放在recipes中意味着我们必须在recipes 2和3中包含Recipe 1，这并不优雅，因为Jboss Recipe应该只安装Jboss而不必担心存储，对吗

---

有什么好方法可以实现这一点吗？

假设

web服务器

，

应用服务器

和

独立

都是单独的食谱，只需将数据放在

web服务器

和

应用服务器

的属性文件中即可

在

web服务器中

您将有如下内容：

# attributes/default.rb
default['mystorage']['nginxdata'] = 2 # Some size

# recipes/default.rb
include_recipe 'myapp::storage'
include_recipe 'myapp:nginx'

# 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'

在

appserver

中，您可能会遇到以下情况：

# attributes/default.rb
default['mystorage']['nginxdata'] = 2 # Some size

# recipes/default.rb
include_recipe 'myapp::storage'
include_recipe 'myapp:nginx'

# 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

---

将此作为注释的答案写在格式上不够清晰

我非常怀疑nginx或jboss的安装方法在你们的应用程序之间会有所不同，所以你们只需要覆盖你们的应用程序手册中的属性

因此，您最终得到了coderanger的答案：每个基础架构工作（nginx、jboss、存储）一本食谱

然后是一本应用程序烹饪书 -将此应用程序的属性值提供给基础结构手册。 -取决于特定版本的基础架构手册 -有3个食谱： -1包括存储和nginx -1包括存储和jboss -1包括前两个（不用麻烦，2包括同一个的食谱不会有问题，厨师很聪明，只包括一次）

在您的节点上，您将使用以下方法之一设置运行列表。 您可以控制在特定时间使用您的应用程序实际设置了哪个版本的jboss或nginx（您无法通过角色设置）

属性加载和配方编译的工作方式将使应用程序cookbook属性覆盖nginx cookbook（例如）中的属性，然后为nginx编译配方

只需确保include_配方nginx/jboss在应用程序部署代码之前，这样您就可以确保nginx/jboss在尝试部署到它之前已经安装好

揭露我的案子（我想离你不远）：

我们有53个内部应用程序，53个烹饪书设置属性（例如jvm选项）。 我们有20个应用服务器对，大约60本食谱（1本用于集群，1本用于集群中的每个实例）

每个实例cookbook都设置了服务器名称和部署目录。 每个集群cookbook都依赖于应用程序cookbook，并包括它们的食谱（使用前面提到的部署目录）

有些工具（如Berkself）可以帮助您维护具有版本约束的整个链

---

一开始听起来很复杂，但随着时间的推移，它可以避免生产中的意外更改，因为您对登台进行了更改，但忘记了它将被传播（使用角色）。

谢谢。web服务器、app server和standalone是角色，而不是烹饪书。也许我应该澄清一下，每个角色在运行列表中都有一个子集或所有的食谱。我将对该问题添加注释。@dvlpr将cookbook示例作为您将在节点上设置的角色cookbook。您将获得一个额外的好处，那就是您将能够以版本连接的方式更新属性，这样您的暂存可以有新的值，而不是您不能使用角色属性的产品。@Tensibai谢谢。但每个应用程序有3本食谱对我来说是不可行的。所以我必须让我的应用程序ngnix、我的应用程序jboss等乘以应用程序的数量（x20或30），这将成为维护的噩梦。每个应用程序都是一个独特的雪花：（如果它们是角色，则以完全相同的方式设置，但在角色数据中，没有发现问题。@dvlpr，正如您发现的，每个“角色”没有一本食谱这也是一场噩梦。角色烹饪书正在迅速成为厨师界的标准做法，如果你使用像Berkself这样的系统，那么维护起来相对容易。如果你更喜欢每个应用程序一个（不受版本控制）角色，每个应用程序一个烹饪书（每个应用程序仍然有两个工件，而不是三个），那么我祝你一切顺利。但我强烈建议你采纳Tensibai这样的人的建议。如果你查看他的个人资料，你会发现他知道自己在说什么。角色web服务器的运行列表中将包含配方1和配方2，应用服务器将仅包含配方1和配方3。独立角色将包含所有三个。