- 您的最后一个问题可能是最容易回答的。在属性文件中，您不必键入“节点”，以便在 attributes/default.rb 中：
default['foo']['bar']['baz'] = 'qux'
和recipes/whatever.rb中的这个完全一样：
node.default['foo']['bar']['baz'] = 'qux'
回想起来，食谱和属性的不同语法令人困惑，但这种设计选择可以追溯到非常古老的 Chef 版本。
- -j 选项对 chef-client 或 chef-solo 可用，并且都将设置属性。请注意，这些将是在节点对象中持久存在的“普通”属性，通常不建议使用。但是，服务器上的“run_list”、“chef_environment”和“tags”都是以这种方式实现的。通常不建议使用其他“正常”属性，并避免在配方（或属性）文件中使用
node.normal['foo'] = 'bar' 或node.set['foo'] = 'bar'。不同之处在于，如果您从配方中删除 node.normal 行，则节点上的旧设置将保留，而如果您从配方中删除 node.default 设置，那么当您在节点上运行 chef-client 时，该设置将被删除。
为了实现这一点，在 chef-client 运行中发生的情况是，在运行开始时，客户端发出 GET 以从服务器获取其旧节点文档。然后它会擦除默认、覆盖和自动（ohai）属性，同时保留“正常”属性。默认、覆盖和自动属性的行为最有意义——您在运行开始时重新开始，然后构造所有状态，如果它不在配方中，那么您看不到那里的值。但是，通常在节点上设置 run_list，并且节点不（通常）管理自己的 run_list。为了使 run_list 持久化，它是一个普通属性。
选择“正常”这个词是不幸的，选择“node.set”设置“正常”属性也是如此。虽然这些看起来像是用于设置属性的明显选择，但用户应该避免使用它们。问题再次是它们首先出现，并且是 run_list 所必需和必需的。通常只坚持默认和覆盖属性。通常，您可以使用默认属性完成大部分工作，这些应该是首选。
- 这里有一张很大的优先级图片：
https://docs.chef.io/attributes.html#attribute-precedence
这是属性优先级的最终真相来源。
- 该图描述了定义属性的所有不同方式。
Chef Attributes 的问题在于，它们已经有机地发展并产生了许多选择来帮助那些把自己逼入绝境的用户。通常，您永远不需要触及属性的自动、正常、force_default 或 force_override 级别。您还应该避免在配方代码中设置属性。您应该将配方中的设置属性移动到属性文件中。剩下的就是这些设置属性的地方：
- 在初始的-j参数中（设置正常属性，你应该限制使用它来设置run_state，过度使用通常是有味道的）
- 在角色文件中作为默认值或覆盖优先级（但请注意这一点，因为角色没有版本控制，如果您经常接触这些属性，则会导致生产问题）
- 在食谱属性文件中作为默认或覆盖优先级（这是您应该设置大部分属性的地方）
- 在环境文件中作为默认或覆盖优先级（对于数据中心中的 DNS 服务器等设置很有用，尽管您也可以为此使用角色和/或说明书）
您也可以在食谱中设置属性，但是当您这样做时，您总是会在运行 Chef Recipes 的两阶段 compile-converge 解析器中获得下一课。如果您有需要相互通信的配方，最好使用 node.run_state ，它只是一个不会被写入节点属性的哈希。您可以将 node.run_state[:foo] = 'bar' 放在一个配方中并在另一个配方中阅读。不过，您可能会看到设置属性的食谱，因此您应该注意这一点。
希望有帮助。