[chef] Re: Re: Re: Re: Re: Chef at Airbnb

["steve ." < >]

So far we've found that the filter-branch results in the same refs in the generated target repo each time, so we can safely run the cookbook-splitter as part of our regular CI-driven release process.  However, we're about to switch over to the one-cookbook-per-repo model for future releases, which means this won't really be an issue past the end of this month.

(And!  We'll finally be free of scheduled releases!)

On Thu, Oct 17, 2013 at 4:17 PM, Igor Serebryany < " target="_blank"> > wrote:

the hard part is not splitting out a cookbook, the hard part is maintaining the code in two separate repos. i think you can do this with git patch and git apply, but it's not a familiar workflow.

On Thu, Oct 17, 2013 at 4:15 PM, steve . < " target="_blank"> > wrote:

It's actually not that hard to split out a unified repository into individual cookbook repos as long as you're not afraid of git filter-branch ... the company technically owns the shell script I wrote to do it so I can't just post it here.  I remember thinking it was going to be a lot harder than it actually was...

On Wed, Oct 16, 2013 at 5:49 PM, Torben Knerr < " target="_blank"> > wrote:

+1 for using Chef Solo :-)

I guess we have the same motivation: avoid the additional complexity of Chef Server 

unless you really need it!

For myself I have found a sweet spot using Chef Solo, Vagrant and Berkshelf, which,

apart from the Chef Solo bit, is quite different from your approach, but probably worth

sharing as well.

The key points to make it play nicely together are:

 * use single-repo-per-cookbook rather than a monolithic chef-repo [0]

 * pull in cookbook dependencies via Berkshelf / Berksfile [1]

 * use application cookbooks [2] rather than roles

 * differentiate between cookbook repositories [3] vs. infrastructure repositories [4] 

A Vagrant-based infrastructure repository yields some really nice properties:

 * different providers: deploy your infrastructure on virtualbox, lxc, aws, rackspace, anywhere...

 * use the same configuration mechanism (Vagrantfile) no matter where you deploy

 * use the same CLI (vagrant up) no matter where you deploy

 * use the same plugin ecosystem (vagrant-omnibus, vagrant-berkshelf, vagrant-cachier, etc..) no matter where you deploy

 * define the infrastructure-specific environments, data_bags and node configuration where they belong to

This approach works really well if you have a static environment where you can still name

all of your machines (i.e. no elasticity / autoscaling). In this case Chef Solo + Vagrant 

seem to be a perfect fit.

If you have something more dynamic with autoscaling etc. you probably need Chef Server 

and search. There's some overhead involved in running an additional piece of infrastructure,

but also the workflow gets slightly more complicated when using Chef Server.

Happy to hear what others think about it!

Refs:

[0] http://www.opscode.com/blog/2012/03/20/cookbooks-migrated-to-new-github-organization/

[1] http://berkshelf.com/#the_berksfile

[2] http://devopsanywhere.blogspot.de/2012/11/how-to-write-reusable-chef-cookbooks.html

[3] https://github.com/tknerr/sample-application-cookbook

[4] https://github.com/tknerr/sample-infrastructure-repo/blob/master/Vagrantfile

On Wed, Oct 16, 2013 at 10:33 PM, Igor Serebryany < " target="_blank"> > wrote:

Sander, at the time, we googled around and learned about additional tooling which might have been able to help. but both figuring out the tooling AND getting it going on CI AND teaching it to the rest of our team was yak-shaving. our task was to get our chaotic legacy infrastructure on chef, as quickly as possible, and what we ended up doing was extremely light-weight.

even today, i'm not convinced that the berkshelf way has any advantages over our approach. i think that what we're doing is still much easier to operate, and much easier to teach. for developing and testing cookbooks, our approach involves no additional tooling beyond just git. and as far as ops work,stemcell and optica neatly replace knife and chef-server, and arguably do a better job. (stemcell, because of how it keeps instance metadata in the role files, and optica because of how flexible and easy to use it is).

actually, i think the biggest drawback to what we're doing is in community integration; i have a few cookbooks i'd like to share, but (a) i'd have to break them out into separate repos to do so and (b) i'd have to start doing all that manual versioning i've been lucky to get to ignore. also, our approach invites people to just edit upstream cookbooks because they're in our repo. once or twice so far, we've had to back-port our changes to newer versions of, say, the runit cookbook (this was complicated when that cookbook was basically completely rewritten as resource/provider libraries).

--igor

On Wed, Oct 16, 2013 at 11:31 AM, Sander van Zoest < " target="_blank"> > wrote:

Hi Igor,

When you say that the chef server approach was not scaling, did you consider using "the berkshelf way" approach and having the cookbook build and uploaded via CI server? If so, what issue did you run into that the berkshelf way did not solve?

Best,

-- Sander

On Tue, Oct 15, 2013 at 3:55 PM, Igor Serebryany < " target="_blank"> > wrote:

Hi Chefs!

We just put up a blog post which details our tooling and workflow around Chef Solo at Airbnb. I thought I'd let the list know, it's here: http://nerds.airbnb.com/making-breakfast-chef-airbnb/

Along with the post, we open-sourced several tools, including stemcell (https://github.com/airbnb/stemcell) which we use to launch and bootstrap instances and optica (https://github.com/airbnb/optica) which we use to keep track of our instances and their last converge state.

I'm happy to answer questions about our approach here if anyone is interested.

--Igor

--
Sander van Zoest                                          " target="_blank">
San Diego, CA, USA                                http://Sander.vanZoest.com/