为什么Chef需要这么多属性类型？

Question

根据docs（强调我的）：

  

chef-client使用六种属性来确定   在chef-client运行期间应用于节点的值。

我有一些厨师经验，但几年后，我从未遇到过需要不同属性类型的用例。 现在，一位同事在我提出的改变中留下了这条评论：

  

您确定此default会覆盖食谱的default吗？   对于这种情况，normal会不会更好？

我当然不确定。我很困惑。

哪些用例证明存在这种复杂性？为什么Chef需要这么多属性类型？

Answer 1

总而言之，Chef不需要它，它允许它方便。

我建议不要使用normal，因为此类型的属性会永久存储在节点对象中，default和overrides始终在编译时计算。优先顺序对此非常重要，override将覆盖normal，default将覆盖listen_port。您链接到的doc中提供了此方案。

由于有很多不同类型的原因，它允许人们在食谱中定义默认值，然后在包装食谱，角色，环境或食谱中取代它们。不得不改变食谱本身。

示例案例：我希望在3个盒子上设置一个Apache服务器，我将开始使用一个最小安装apache2的菜谱，其默认listen_port属性为80。

对于我的一般情况（3个节点上的2个节点）我希望Apache监听端口800而不是默认80，并添加一些额外的配置。我将围绕apache安装执行通用包装，将override属性更改为800并执行额外配置。

对于第三个节点，我希望具有相同的配置，但是让它在端口2053上侦听。为了解决这个问题，我可以在节点上，角色中或在另一个包装器中设置属性。

如果我希望确保我设置的参数不会被包装器或角色取代，我可以使用default而不是default获得一个级别。在包装食谱的属性文件中明确表示我愿意覆盖此值，并且在包含发生时不会取代它。

在一天结束时，对于99％的情况，坚持NULL级别应该足够了，但其他级别在需要时可用，以便快速修复或调试等。

Answer 2

请参阅我之前提出的问题的答案的最后一部分：

Using attributes in Chef

在这里复制：

Chef Attributes的问题在于它们已经有机地发展并且萌发了许多选项，以帮助那些将自己画成角落的用户。通常，您永远不需要触摸自动，正常，force_default或force_override属性级别。您还应该避免在配方代码中设置属性。您应该将配方中的设置属性移动到属性文件。这留下的是这些地方设置属性：

在最初的-j参数中（设置正常属性，你应该限制使用它来设置run_state，过度使用这通常是气味） 在角色文件中作为默认值或覆盖优先级（请注意这一点，因为角色没有版本化，如果您经常触摸这些属性，则会导致生产问题） 在cookbook属性文件中作为默认值或覆盖优先级（这是您应该设置大部分属性的位置） 在环境文件中作为默认值或覆盖优先级（对于数据中心中的DNS服务器等设置非常有用，尽管您也可以使用角色和/或烹饪书） 您还可以在食谱中设置属性，但是当您这样做时，您总是会在通过Chef Recipes运行的两阶段编译 - 聚合解析器中获得下一课。如果您有需要相互通信的配方，最好使用node.run_state，它只是一个不会被写为节点属性的哈希。你可以删除node.run_state [：foo] =＆＃39; bar＆＃39;在一个食谱中，在另一个食谱中阅读。你可能会看到设置属性的配方，所以你应该知道这一点。