[chef] Re: On Chef patterns - ways to organize a Chef kitchen

[Mat Schaffer < >]

"It depends" ;)

When I was doing client work I generally kept one kitchen per client just to make the final delivery as clean as possible. For myself I tend to keep kitchens logically separate by project.

If you need to share stuff between kitchens I recommend pushing all that stuff into cookbooks so that you can use berkshelf or librarian-chef to load in the shared cookbooks from their own dedicated git repositories. This also helps avoid loading too much info into roles which is another good practice.

Finally, you should try to get into the practice of using chef to provision as well as manage the servers since it's where configuration "management" really starts to shine. Of course there are other options but if you're on a lamp stack, generating configuration files and/or data from chef will probably be the easiest to set up.

Hope that helps some. I think this is one of those things that varies a bit from project to project.

Feel free to open a knife-solo issue if you run into trouble there.

-Mat

about.me/matschaffer

On Sun, Feb 2, 2014 at 12:00 AM, Marcelo Serpa < " target="_blank"> > wrote:

Hi list,

I’m wondering Chef kitchen patterns. Right now, I use knife-solo, and I have a general-purpose kitchen. I add nodes as needed (not necessarily for the same app). Since I don’t really deal with a project that requires a more than one (or two) server(s), yet, it’s easy to just do something like:

➜  mykitchenv2 git:(master) ✗ ls

Berksfile      Berksfile.lock Gemfile        Gemfile.lock   Vagrantfile    cookbooks      data_bags      environments   nodes          roles          site-cookbooks

➜  roles git:(master) ✗ ls

lamp.json      rack.json

➜  nodes git:(master) ✗ ls

127.0.0.1.json       anotherhost.json …

So, it’s basically a general-purpose kitchen. It’s not really geared towards a specific application. My workflow looks like this:

1) New project, hack, app ready to be deployed

2) Create new VM @ digital ocean, grab the IP, create a new node json in the kitchen

4) It’s probably a Rails app. Add the rack role[lamp] to the run_list for this node. The rack role basically setups a new rack box using the rackbox cookbook (https://github.com/teohm/rackbox-cookbook)

3) knife solo prepare

4) knife solo cook

5) Use capistrano to deploy the app.

Then, I do the same thing if I need a staging server.

It works pretty well. However, most of the apps I develop right now are apps with a quite simple infrastructure. They don’t require more than 2 servers (prod,staging). I did work with more elaborated apps before with up to 10 different servers (but without using Chef at the time, go figure). 

The problem with this approach is that I end up having several unrelated nodes, and in the end, I don’t really describe the infrastructure of a single app/system, but of several ones, which can become clunky. Basically, for now, I’m just using Chef to get the sever ready, but not really using it to *manage* the server afterwards.

That being said, I’d like some insights on Chef patterns related to this, for example,  when is it time to create a kitchen solely for an app? 

Thanks in advance,

-- 

Marcelo