我正在做一个厨师实现，在过去，attribute.set 有时会在 attribute.default 会做的地方使用。为了解决这个问题，我已经对 Chef 属性优先范式感到非常满意。我了解“普通”属性（使用 attribute.set[] 分配）在厨师客户端运行之间持续存在。
这让我想知道使用 attribute.set 的常用和最佳方法是什么？我不明白在厨师客户端运行之间的节点上保留属性分配的价值？
【问题讨论】：
标签： attributes persistence chef-infra persistent-storage
使用node.set 的地方是当您需要一些状态但不能（轻松）将其存储在系统中时。这在自生成数据库密码中很常见。您需要将其存储在某个地方，通常是因为其他节点需要密码，但数据库本身只存储它的哈希值，因此您无法从那里检索它。使用节点对象作为有状态存储可以让您在中间放置数据。
也因为我不得不说，这样存储密码是非常不安全的，请不要。
【讨论】：
历史上首先引入了 node.set 和“正常”属性。它们只是属性，也是属性的工作方式。
它们对于标签、run_list、chef_environment 和其他“所需”状态位很有用——您在命令行上用刀设置并期望节点拾取并让食谱消耗的东西，但不是设置自己。由于厨师客户需要一个 run_list 来做任何事情，所以这个问题必须首先得到解决，并且正常的属性是它是如何实现的。
随着 Chef 的发展，创建了默认和覆盖优先级，并在 Chef 运行开始时将其清除，这意味着食谱可以更加声明性地使用它们。这就是人们通常希望食谱中的属性的行为方式，这就是它以这种方式引入的原因。
'node.set' 的使用现在非常令人困惑，因为看起来如果你想设置一个你会使用 'node.set' 但在几乎所有情况下对于用户'node.default' 或' node.override' 是首选。当从说明书中删除设置属性的代码时，使用“node.set/normal”会导致难以调试行为，但属性会持续存在，从而导致有趣的调试，直到它识别出状态持续存在于节点对象中。
虽然它可用于存储密码信息，但正如@coderanger 指出的那样，这是完全不安全的。 Chef服务器上的每个节点都可以读取其他每个节点的节点信息，因此您的密码本质上是全球广播的。
除非你正在做类似于“标记”服务器的事情（在这种情况下，为什么不使用我们已经在普通属性之上构建的 node.tags 功能？），那么你真的不想使用正常优先级。
不幸的是，Chef 属性系统有机地增长了，现在我们只剩下“不要使用 node.set 来设置节点属性”的规则了。
出于这个原因，我们将开始弃用 node.set 以支持 node.normal 以减少一些混乱 (https://github.com/chef/chef/pull/5029)。
【讨论】：
例如，您可以将节点的角色存储在持久属性中，并且如果当前角色从db-slave 更改为db-master，则除了提升和宣布当前db-master 之外，从先前的db-master 删除一种方式复制。
例如，您的 Redis 服务器在节点 A 上，现在在节点 B 上，您可以将数据从服务器 A 移动到 B。
作为另一个例子，首先会为每个服务器生成一个 SSH 密钥对，备份服务器的指纹在 authorized_keys。您的备份服务器发生变化。您可以将authorized_keys 移动到新服务器并在旧服务器上删除。
【讨论】：