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


Chronological Thread 
  • From: Greg Zapp < >
  • To:
  • Subject: [chef] Re: Re: Re: Chef at Airbnb
  • Date: Thu, 17 Oct 2013 10:41:49 +1300

I really like the idea of separating node attributes, data_bags, etc from the cookbooks "repo".  It's a major shortcoming for open source chef IMO.  We ended up hooking up our application recipes directly to our API server for better isolation. 


On Thu, Oct 17, 2013 at 9:40 AM, John Dewey < " target="_blank"> > wrote:
Rewriting a "chef server" could arguably be yak-shaving -- not picking on your decision, just sayin'.

On Wednesday, October 16, 2013 at 1:33 PM, Igor Serebryany 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/






Archive powered by MHonArc 2.6.16.

§