在厨师中使用属性 [英] Using attributes in Chef

问题描述

刚开始使用厨师<​​/ code>最近。我收集到的是，属性存储在一个名为 node 的大型整体哈希中，可用于您的食谱和模板。

似乎有多种方式来定义属性

1. 直接在配方本身中


2. 属性文件 - 例如 attributes / default.rb


3. 传递给 chef-solo 呼叫。例如 chef-solo -j web.json



鉴于上述3， '很好奇



1. 是否可以定义所有的方式属性？


2. 优先权在这里？我假设其中一种方法取代了其他方法


3. ＃3（ JSON 方法）仅适用于 chef-solo ？


4. 我看到定义了节点和默认散列。有什么不同？我最好的猜测是在 attributes / default.rb 中定义的默认哈希合并到 node hash？

谢谢！

解决方案

4. 最后一个问题可能是最简单的答案。在属性文件中，您不必键入'node'，以便在属性/ default.rb中输入：

$ b

完全相同这在食谱/ whatever.rb：

node.default ['foo'] ['bar'] ['baz'] ='qux现在回想起来，食谱和属性的语法不尽相同，但这种设计选择可以追溯到厨师的老版本。

p>

3. -j选项可用于chef-client或chef-solo，并将同时设置属性。请注意，这些将是正常属性，它们在节点对象中是持久的，通常不推荐使用。然而，服务器上的'run_list'，'chef_environment'和'tags'是以这种方式实现的。通常不推荐使用其他'正常'属性并避免 node.normal ['foo'] ='bar'或 node.set配方（或属性）文件中的['foo'] ='bar'。区别在于，如果从配方中删除 node.normal 行，则节点上的旧设置将保留，而如果删除节点。默认设置一个配方，然后当您运行在该节点设置的厨师客户端将被删除。

<为了实现这一点，在大厨客户端运行会发生什么情况是，在运行开始时，客户端发出一个GET来从服务器获取旧的节点文档。然后擦除默认，覆盖和自动（ohai）属性，同时保持正常属性。默认值，覆盖和自动属性的行为是最有意义的 - 在运行开始时重新开始，然后构建所有状态，如果它不在配方中，那么您在那里看不到值。但是，通常run_list在节点上设置，节点不（通常）管理自己的run_list。为了使run_list持久化，它是一个普通的属性。

'normal'这个词的选择是不幸的，'node.set'设置的选择也是不幸的'正常'属性。虽然这些看起来像用于设置属性的明显选择，但用户应避免使用这些属性。问题再一次出现在run_list中，并且是必需的。通常只使用默认和覆盖属性。通常您可以使用默认属性完成大部分工作，这些应该是首选。

2. 有很大的优先级这里是一级图片：

https://docs.chef.io/attributes.html#attribute-precedence

这是属性事实的最终来源优先。

1. 该图描述了可以定义属性的所有不同方式。

厨师属性的问题在于，他们已经有机地发展并且发起了很多选择，试图帮助那些将自己涂在角落的用户。一般情况下，您不需要触摸自动，正常，force_default或force_override属性级别。您还应该避免在配方代码中设置属性。您应该将食谱中的设置属性移至属性文件。这些留下的是这些地方设置属性：在初始-j参数中设置属性

• （设置普通属性，您应该限制使用它来设置run_state，使用这个通常是嗅觉）


• 作为默认的角色文件或覆盖优先级别（尽管这是一个小心，因为角色没有版本控制，并且如果你触摸这些属性很多您将导致生产问题）


• 作为默认菜单属性文件或覆盖优先级别（这是您应该设置大部分属性的位置）


• 在环境文件中作为缺省值或覆盖优先级别（对于像数据中心中的DNS服务器这样的设置可能很有用，尽管您也可以使用角色和/或烹饪书籍）
  

您也可以在食谱中设置属性，但是当您这样做时，您总会在通过Chef Recipes运行的两阶段编译 - 融合解析器中获得下一课。如果你有需要相互沟通的食谱，最好使用node.run_state，它只是一个没有写成节点属性的散列。您可以在一个配方中放置node.run_state [：foo] ='bar'，并在另一个配方中读取它。你可能会看到设置属性的食谱，所以你应该知道这一点。

希望有帮助。

Just getting started with using chef recently. I gather that attributes are stored in one large monolithic hash named node that's available for use in your recipes and templates.

There seem to be multiple ways of defining attributes

1. Directly in the recipe itself
2. Under an attributes file - e.g. attributes/default.rb
3. In a JSON object that's passed to the chef-solo call. e.g. chef-solo -j web.json

Given the above 3, I'm curious

1. Are those all the ways attributes can be defined?
2. What's the order of precedence here? I'm assuming one of these methods supercedes the others
3. Is #3 (the JSON method) only valid for chef-solo ?
4. I see both node and default hashes defined. What's the difference? My best guess is that the default hash defined in attributes/default.rb gets merged into the node hash?

Thanks!

解决方案

4. Your last question is probably the easiest to answer. In an attributes file you don't have to type 'node' so that this in attributes/default.rb:

default['foo']['bar']['baz'] = 'qux'

Is exactly the same as this in recipes/whatever.rb:

node.default['foo']['bar']['baz'] = 'qux'

In retrospect having different syntaxes for recipes and attributes is confusing, but this design choice dates back to extremely old versions of Chef.

3. The -j option is available to chef-client or chef-solo and will both set attributes. Note that these will be 'normal' attributes which are persistent in the node object and are generally not recommended to use. However, the 'run_list', 'chef_environment' and 'tags' on servers are implemented this way. It is generally not recommended to use other 'normal' attributes and to avoid node.normal['foo'] = 'bar' or node.set['foo'] = 'bar' in recipe (or attribute) files. The difference is that if you delete the node.normal line from the recipe the old setting on a node will persist, while if you delete a node.default setting out of a recipe then when your run chef-client on the node that setting will get deleted.

What happens in a chef-client run to make this happen is that at the start of the run the client issues a GET to get its old node document from the server. It then wipes the default, override and automatic(ohai) attributes while keeping the 'normal' attributes. The behavior of the default, override and automatic attributes makes the most sense -- you start over at the start of the run and then construct all the state, if its not in the recipe then you don't see a value there. However, normally the run_list is set on the node and nodes do not (often) manage their own run_list. In order to make the run_list persist it is a normal attribute.

The choice of the word 'normal' is unfortunate, as is the choice of 'node.set' setting 'normal' attributes. While those look like obvious choices to use to set attributes users should avoid using those. Again the problem is that they came first and were and are necessary and required for the run_list. Generally stick with default and override attributes only. And typically you can get most of your work done with default attributes, those should be preferred.

2. There's a big precedence level picture here:

https://docs.chef.io/attributes.html#attribute-precedence

That's the ultimate source of truth for attribute precedence.

1. That graph describes all the different ways that attributes can be defined.

The problem with Chef Attributes is that they've grown organically and sprouted many options to try to help out users who painted themselves into a corner. In general you should never need to touch automatic, normal, force_default or force_override levels of attributes. You should also avoid setting attributes in recipe code. You should move setting attributes in recipes to attribute files. What this leaves is these places to set attributes:

• in the initial -j argument (sets normal attributes, you should limit using this to setting the run_state, over using this is generally smell)
• in the role file as default or override precedence levels (careful with this one though because roles are not versioned and if you touch these attributes a lot you will cause production issues)
• in the cookbook attributes file as default or override precedence levels (this is where you should set most of your attributes)
• in environment files as default or override precedence levels (can be useful for settings like DNS servers in a datacenter, although you can use roles and/or cookbooks for this as well)

You also can set attributes in recipes, but when you do that you invariably wind up getting your next lesson in the two-phase compile-converge parser that runs through the Chef Recipes. If you have recipes that need to communicate with each other its better to use the node.run_state which is just a hash that doesn't get written as node attributes. You can drop node.run_state[:foo] = 'bar' in one recipe and read it in another. You probably will see recipes that set attributes though so you should be aware of that.

Hope That Helps.

这篇关于在厨师中使用属性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！