- From: Dan Adams <
- To: <
- Subject: [chef] Re: Re: Re: Chef in "Pure Infrastructure-As-Code" Mode?
- Date: Sun, 24 Jun 2012 11:23:40 +0100
- Mail-reply-to: <
On 24.06.2012 10:04, Torben Knerr wrote:
Yes, that would be pretty close. I'm basically interested in keeping
track of any recipe / attribute / databag changes on my
nodes. Ideally I want these changes happening only via git commits
and prevent these changes happening via knife / REST API.
Currently I have $CHEF_REPO/nodes/<nodename>.json for each of my
nodes which should reflect the current state of the node in chef
server. Whenever I modify the node's run_list or attributes etc. I
have to make sure to keep it in sync manually by doing the commit AND
the upload via knife.
Btw: do you have any preventative measures to disallow the "knife
edit" type workflow, or is convention enough for you?
So the way we solve this is that everyone works in git and everything
is driven by git. When someone pushes to origin in git, then a git
commit hook on push grabs all the changes and generates the knife
commands (which it then executes automatically) to import the necessary
files into couch/solr. This means that there is an active disincentive
to use knife directly - if you do, your changes will be overwritten the
next time someone commits a change to the same resource. Between that
and convention I really haven't found a need to actively lock out knife
commands - people are used to using git, and the process is so easy and
automated they are actively disincentivised from trying to get around
May be a noob question, but why do you need the client's PEM files
in your chef repo?
Because we try to follow fairly religiously the "rebuild anything from
bare metal and a repo of code" mentality - so if a chef server or chef
client dies I have a copy of its private and public PEM files and can
get it back in the same state as before quickly without having to
regenerate and re-issue keys at one end or the other.
As for the after-commit hook, I'm
ugh to not
introduce lots of artificial changes (guess it would re-upload
cookbooks, roles, databags, nodes, etc even if I change only a tiny
bit in a single node json).
I'm not following you here. It does not do this. Our git commit hook
finds only what has changed, and then calculates what needs to be
updated based on that. So if you edit an environment file, only the
environment file is updated, if you edit a node file, only the node file
is updated. The different here is that we don't store nodes as a single
JSON file, we use the standard chef git repo structure of node, env,
cookbook, client etc files.
The Rakefile inside the chef repo is written in a way so that if you
at have changed.
run `rake install` it would upload _everything_ in the chef repo
(i.e. cookbooks, roles, environments, databags) to chef server. I
guess it is not smart enough to upload only
So your commit hook script would be exactly what I was looking for.
for putting it on github :-)
I'm also wondering if other's haven't had the same requirements and
maybe built something similar already?
Yes, I'm sure this is a common requirement and must be written over and
over in many shops. I'll upload what I have to github and wait for
someone to shoot it down with something far simpler, quicker, more
efficient and more elegant :-)
Archive powered by MHonArc 2.6.16.