[chef] Re: Re: Re: Re: Re: Puppet+Hiera vs. Chef, or handling the occasional special snowflake server


Chronological Thread 
  • From: Yoshi Spendiff < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Puppet+Hiera vs. Chef, or handling the occasional special snowflake server
  • Date: Tue, 6 Oct 2015 23:33:18 -0700

"And if you have n nodes that share the same run list and environment, you can only alter one of those n nodes by altering its run list or environment -- otherwise, the change would apply to all n nodes, no?"

No. Nodes can receive attributes by having a role with attributes in a run list, in which case attributes are used from the role and/or by specifying an environment when Chef is run, in which case attributes are used from the environment. You can also set them in a recipe, which applies the attributes to the node object itself. Finally you can just set attributes directly against a node object by editing the node object directly in Chef server, using something like knife node edit.

As an example I have a recipe which installs a Newrelic agent if a certain attribute is set to true. In the production Chef environment I set the attribute so that all production nodes have this. If I want to use newrelic for a machine outside of production I can set that attribute on the individual node object instead, which could be in any environment.

In your case you would put the same data from the YAML you need in a specific attribute for the node you are altering (in JSON), and it would change that node only.

On 6 October 2015 at 20:27, Julian C. Dunn < " target="_blank"> > wrote:
Does this help?

https://docs.chef.io/dsl_recipe.html#tag-tagged-untag

- Julian

On Tue, Oct 6, 2015 at 10:13 PM, Fabien Delpierre
< "> > wrote:
> Lamont,
> Your mention of tags is interesting. I'd actually never heard of them and it
> seems like there's little documentation on the topic.
> Could you share some examples?
>
> On Tue, Oct 6, 2015 at 6:15 PM, Lamont Granquist < "> > wrote:
>>
>>
>> you can use tags (or normal attribute precedence level, which is how tags
>> are implemented) to assign attributes directly to nodes for one-off use
>> cases.
>>
>>
>> On 10/06/2015 01:22 PM, Yoshi Spendiff wrote:
>>
>> But in Chef you have an object which represents each node, so why not just
>> edit that if you want to alter individual nodes?
>>
>> Perhaps I'm not understanding
>>
>> On 6 October 2015 at 13:18, Fabien Delpierre < "> >
>> wrote:
>>>
>>> Hello folks,
>>> I'm a user of both Puppet and Chef, I'm more familiar with and prefer the
>>> latter overall, but am required to use the former at work. Recently I was
>>> toying with the idea of moving to Chef, although it's probably not a
>>> realistic option, but it raised a few interesting questions.
>>> While Puppet and Chef do roughly the same thing, they do it in slightly
>>> different ways, and Puppet has something in particular that Chef doesn't
>>> have, which is Hiera.
>>>
>>> If you're not familiar with Hiera, it's a simple way to apply settings to
>>> any number of your servers (from a single node to an entire infrastructure
>>> of thousands), you define the hierarchy of settings yourself -- in a sense,
>>> it's kind of like being able to customize Chef's attribute precedence and
>>> having a single environment attached to all your nodes. The link above
>>> explains it a lot better than I can.
>>>
>>> Anyway, I was wondering how one might deal with losing Hiera when moving
>>> from Puppet to Chef. It seems that you could achieve similar results with a
>>> mix of cookbooks, roles and environments, like everything else, but at the
>>> cost of ending up with a lot more of them than you'd normally have.
>>>
>>> I guess a different way I might ask this is:
>>> Imagine I have a group of servers, all configured the same way (same run
>>> list, same environment), and I need to change something on just one of them.
>>> A common scenario in my environment is having to attach YourKit to a JVM
>>> process.
>>> With Puppet/Hiera, I'd just add a two-line YAML file with the same name
>>> as that one server's FQDN, and when I run Puppet, that YAML file would be
>>> read at compile time and the config change applied without affecting the
>>> other nodes.
>>> With Chef, I'd have to modify the node's run list or take its environment
>>> file, make a copy of it, modify the copy and assign that copied environment
>>> to the node instead of the normal env file, lest I affect the other servers
>>> in the same group.
>>>
>>> Hiera is also capable of aggregating data from multiple sources into a
>>> single hash or array to be applied to a node during a Puppet agent run.
>>>
>>> Those are things that I never missed for as long as I used Chef, but now
>>> that I know they're out there, I'm wondering how I would handle things
>>> without Hiera.
>>>
>>> So in short, I was wondering if anybody has thoughts on the matter.
>>> Obviously it helps if you have some experience with both tools. I'm far from
>>> being a Chef expert so it's possible I'm missing something. Any input is
>>> appreciated. Thanks!
>>> Fabien
>>
>>
>>
>



--
[ Julian C. Dunn < "> >          * Sorry, I'm    ]
[ WWW: http://www.aquezada.com/staff/julian    * only Web 1.0  ]
[ gopher://sdf.org/1/users/keymaker/           * compliant!    ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9       ]




Archive powered by MHonArc 2.6.16.

§