json – 在Chef中使用属性

刚刚开始使用厨师.我认为属性存储在一个名为node的大型单片哈希中,该哈希可用于您的配方和模板.

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

>直接在食谱本身
>在属性文件下 – 例如属性/ default.rb
>在传递给chef-solo调用的JSON对象中.例如chef-solo -j web.json

鉴于上述3,我很好奇

>那些属性是否可以定义?
>这里的优先顺序是什么?我假设其中一种方法取代了其他方法
>#3(JSON方法)仅对chef-solo有效吗?
>我看到定义了节点和默认哈希值.有什么不同?我最好的猜测是,attributes / default.rb中定义的默认哈希值会合并到节点哈希中吗?

谢谢!

最佳答案 >您的上一个问题可能是最容易回答的问题.在属性文件中,您不必键入“node”,以便在attributes / default.rb中输入:

默认[‘foo’] [‘bar’] [‘baz’] =’qux’

与食谱/ 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时被删除.

在厨师 – 客户端运行中发生的事情是,在运行开始时,客户端发出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,过度使用这通常是气味)
>在角色文件中作为默认值或覆盖优先级(请注意这一点,因为角色没有版本化,如果您经常触摸这些属性,则会导致生产问题)
>在cookbook属性文件中作为默认值或覆盖优先级(这是您应该设置大部分属性的位置)
>在环境文件中作为默认值或覆盖优先级(对于数据中心中的DNS服务器等设置非常有用,尽管您也可以使用角色和/或烹饪书)

您还可以在食谱中设置属性,但是当您这样做时,您总是会在通过Chef Recipes运行的两阶段编译 – 聚合解析器中获得下一课.如果您有需要彼此通信的配方,最好使用node.run_state,它只是一个不会被写为节点属性的哈希.您可以在一个配方中删除node.run_state [:foo] =’bar’,然后在另一个配方中读取它.你可能会看到设置属性的配方,所以你应该知道这一点.

希望有所帮助.

点赞