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.
Good to know about knife node edit. Wouldn’t any change be overridden at
the next chef-client run, though?
I guess I ought to look into policies, too. I’ve never used them but I’m
not finding much documentation about them. Are we talking about the new-ish
Policyfile feature? That I can find documentation about.
Does this help?
https://docs.chef.io/dsl_recipe.html#tag-tagged-untag
It’ll get me started at least, thanks!
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.
I was including that when I mentioned “editing the run list” – of course
that works but if I have multiple nodes that use the same set of
roles/recipes and I edit one of those roles or recipes, all of them will be
affected, which I may not want.
knife node edit does seem like it might help, but I’m concerned that the
change wouldn’t persist past a chef-client run.
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.
So that makes sense if you have a recipe that’s designed to look for that
attribute, but that still seems like it wouldn’t accomplish what one might
do with Puppet’s Hiera.
To use a concrete example, again with attaching YourKit to a JVM process –
like I mentioned, Hiera can aggregate multiple hashes or arrays spread
between multiple sources into a single attribute.
For example, in one YAML file I could have:
foo::java_opts: "-Xms2g -Xmx2g"
And in another:
foo::java_opts: "-agentpath:/opt/yjp/bin/linux-x86-64/libyjpagent.so"
Then I could invoke this foo::java_opts in a recipe or a template (e.g. for
an init script) and Hiera would combine them into one so it produces an
init script might read: java -Xms2g -Xmx2g -agentpath:
/opt/yjp/bin/linux-x86-64/libyjpagent.so
When I’m done with YourKit, I can just delete the YAML file that contains
those bits and I never have to touch the nodes or the recipe since it only
looks for what’s in that java_opts attribute and spits it back out.
While so far it doesn’t seem like this would be possible in Chef, it does
seem like tags would help, if accounted for within a recipe, e.g.:
node.default[‘foo’][‘bar’] = false
if tagged?(‘bar’)
ruby_block ‘enable_bar’ do
block do
node[‘foo’][‘bar’] = true
end
end
end
if node[‘foo’][‘bar’] == true
(do unspeakable things)
end
On Tue, Oct 6, 2015 at 10:23 PM, Noah Kantrowitz noah@coderanger.net
wrote:
On Oct 6, 2015, at 1:18 PM, Fabien Delpierre fabien.delpierre@gmail.com
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
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.
–Noah