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

时间:2016-03-11 10:58:26

标签: chef chef-recipe

根据docs(强调我的):

  

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

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

  

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

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

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

2 个答案:

答案 0 :(得分:3)

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

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

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

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

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

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

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

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

答案 1 :(得分:0)

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

Using attributes in Chef

在这里复制:

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

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