Generally you would try to use an existing grouping like a chef environment, role, or policy (if you are using any of those). For single node edits you would do it directly via `knife node edit`. For things that are between the scope of a role and environment, https://github.com/poise/poise-appenv can be a solution.
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.
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.
Generally you would try to use an existing grouping like a chef environment, role, or policy (if you are using any of those). For single node edits you would do it directly via `knife node edit`. For things that are between the scope of a role and environment, https://github.com/poise/poise-appenv can be a solution.
On Oct 6, 2015, at 1:18 PM, 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
--Noah
Archive powered by MHonArc 2.6.16.