[chef] Re: Re: Re: Chef in "Pure Infrastructure-As-Code" Mode?

Chronological Thread 
  • 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 it.

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
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
at have changed.

So your commit hook script would be exactly what I was looking for. +1
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.