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

Chronological Thread 
  • From: Torben Knerr < >
  • To:
  • Subject: [chef] Re: Re: Chef in "Pure Infrastructure-As-Code" Mode?
  • Date: Sun, 24 Jun 2012 11:04:48 +0200

Hi Dan,

On Sun, Jun 24, 2012 at 10:09 AM, Dan Adams < " target="_blank"> > wrote:
On 23.06.2012 15:34, Torben Knerr wrote:
I was just wondering if someone is running Chef in "pure
infrastructure-as-code" mode (couldn't find a better term), i.e. all
changes to your infrastructure are done via git only, so that you can
trace whatever has been done in 'git log'.

The thing that stops people being able to do this is generally twofold - firstly that Chef covers off configuration via git, but not runbook changes (eg an apache restart across all servers). Whilst you can use "knife ssh" as your runbook automation tool, you can't do that through git, so you have no visibility through git log.

Actually I didn't think of an apache restart across all servers, but probably you could do that using a one-shot recipe [1] if you really want that.
The second factor is that Chef cookbooks are mainly in the application space and don't extend right down to kernel tweaks etc (that I've seen yet anyway) or even if the cookbooks are available the discussion and setups I've seen, people are mostly managing apps/daemons/services/configs using Chef, not the lower level routing, kernel tweaks etc (though I'm sure *some* people are).

Those two factors aside, we do use the "knife edit" type flow never or very rarely and everything is created or edited via our git repo, so very close to your ideal.

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?

The exception would be for client PEM files. I've sure it would be possible to generate these not using knife, then add them to the git repo, then import them to Chef via knife? But I'm not sure this would give you anything over creating the client PEM files and then adding them to the repo. I have been meaning to ask how other people manage this flow actually, since currently for us it is the most clunky and cumbersome to get a client both registered in the couch via knife, and also created as PEM files within the repo. How is everyone else managing this? Thoughts?

May be a noob question, but why do you need the client's PEM files in your chef repo?

As for the after-commit hook, I'm not sure whether 'rake install' in
the chef repo (or the backend side) would be smart enough to not
introduce lots of artificial changes (guess it would re-upload _all_
cookbooks, roles, databags, nodes, etc even if I change only a tiny
bit in a single node json).

I'm afraid I'm not really familiar with rake and can't really understand what you're trying to do here. Our flow involves committing to git, which triggers a commit hook that finds files midified in that commit, figures what knife commands are needed to run based on these changes (not always simple) and then executes them against the chef server. I should really throw this up on github or something because it would probably be useful to others?

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 the parts that 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?



Archive powered by MHonArc 2.6.16.