我正在使用一个大厨实现，有时在过去的属性.set已经使用了attribute.default。为了解开这个问题，我对Chef属性优先范例非常熟悉。我理解＆＃34;普通＆＃34;属性（使用attribute.set []分配）在厨师客户端运行之间保持不变。
这让我想知道使用attribute.set的常见和最佳方法是什么？我不明白在厨师客户端运行之间节点上是否存在属性分配的价值？
答案 0 :(得分：2)
使用地点node.set是指您需要某个州，但无法（轻松）将其存储在系统中。这在自生成数据库密码时很常见。您需要将其存储在某个地方，通常是因为其他节点需要密码，但数据库本身只存储它，因此您无法从那里检索它。使用节点对象作为有状态存储，可以将数据放在过渡期间。
另外，因为我必须这么说，存储这样的密码是非常不安全的，请不要。
答案 1 :(得分：0)
例如，您可以将节点的角色存储在持久属性中，并且如果当前角色从db-slave更改为db-master，则会从之前的db-master拆除单向复制，而不是宣布当前db-master。
例如，您的Redis服务器位于节点A上，现在位于节点B上，您可以将数据从服务器A移至B。
作为另一个示例，在第一次聚合时为每个服务器生成SSH密钥对，并且备份服务器在authorized_keys中具有其指纹。您的备份服务器更改。您可以将authorized_keys移至新服务器并在旧服务器上将其删除。
答案 2 :(得分：0)
历史上首先引入了node.set和“normal”属性。它们只是属性，属性是如何工作的。
它们对于标签，run_list，chef_environment和其他“所需”状态非常有用 - 您在命令行中使用knife设置的东西，并期望节点拾取和使用的配方，但不是自己设定。由于厨师客户需要run_list来执行任何操作，因此必须首先解决此问题，并且正常属性是如何实现的。
随着Chef的发展，创建了默认和覆盖优先级，并且在主厨运行开始时清除了这些优先级，这意味着配方可以更具声明性地使用它们。这就是人们通常希望食谱中的属性表现出来的原因，这就是为什么它以这种方式引入的原因。
'node.set'的使用现在非常令人困惑，因为看起来你想要设置一个你使用'node.set'的节点，但几乎在所有情况下都是用户'node.default'或' node.override'是首选。当从cookbook中删除设置属性的代码时，'node.set / normal'的使用会导致难以调试的行为，但这些属性会持续导致有趣的时间调试，直到它认识到状态持久存在于节点对象中。
虽然它可用于存储密码信息，但@coderanger指出这是完全不安全的。 Chef服务器上的每个节点都可以读取每个其他节点的节点信息，因此您的密码基本上是全局广播的。
除非你做的事情类似于'标记'服务器（在这种情况下为什么不使用我们已经在普通属性的顶部构建的node.tags特性？）然后你真的不想使用正常优先级。
不幸的是，Chef属性系统有机地增长了，现在我们留下了“不要使用node.set来设置节点属性”的规则。
出于这个原因，我们正在开始弃用node.set而不是node.normal，以便减少一些混淆（https://github.com/chef/chef/pull/5029）。< / p>