Chef: Suck on my chocolate salty balls

Posted by ezmobius Thu, 15 Jan 2009 21:35:00 GMT

Yesterday we announced http://engineyard.com/solo which is our new engine yard on AWS platform. If you haven’t yet watched the screencast then you should check it out:

Engine Yard Solo Screencast

I’m using a really sweet configuration management engine called Chef that is being open sourced today. My good friends at OpsCode are responsible for the project.

If you have ever used or thought about using a system like Puppet then you owe it to your self to give Chef a try. Chef is a state based, declarative configuration management engine. You define recipes of how you want your system to look and then chef makes it so.

The big advantage chef has over puppet is that the codebase is 1/10th the size and it is pure ruby, including the recipe DSL. Puppet’s biggest flaw is its configuration language that is not quite ruby and not quite turing complete. So you end up wrestling with it to get it to do anything.

Chef is just pure ruby so anything you can do in ruby you can do in your recipes. It also uses a simple merb-core/couchdb server for centralized storage of node configs and each server you manage gets an openid for identity.

If you have a hand in building or configuring any servers, you need to learn chef now.

You need two repos to get chef running, chef and ohai:

chef ohai

Ohai is a gem that interrogates your system and gathers facts about it. Chef is the gem that runs your recipes and actually does the work of configuring the system.

Here are the docs to get started with:

Chef Wiki

I believe that chef will play a very important role in the future of building and managing servers in the ruby community as well as anyone else who needs repeatable server build outs.

We will expose a way to have your own custom chef recipes applied via our management app so that anything we haven’t already written recipes for you can write yourself and get applied as part of a server build.

Put em in your mouth and suck em.

Tags , , ,  | 15 comments

Comments

  1. BradfordW said about 2 hours later:
    Man, that's real nice! And with CouchDB, that's ever sweeter! Cool stuff
  2. Dylan said about 3 hours later:
    Best blog title reference award goes to... :)
  3. jason said about 12 hours later:
    what about puppet? its ruby, its been around for a while,and it is easily extended. I do want to check this out and it is on my todo list for the morning. All of the documentation seems to reference items that puppet already has, recipes, providers, facts... Imitation is a great form of flattery but when it all comes down to it, puppet can do chefs job and more.
  4. matt said about 18 hours later:
    Theres also sprinkle (github)
  5. Ezra said about 20 hours later:
    I have used puppet and sprinkle and yes chef is highly inspired by puppet. The guys who started chef have been puppet consultants for years. Chef was written to address puppet's shortcomings and it does a great job there. Puppet and Sprinkle are great tools and puppet has a lot of momentum. But I think if you actually give chef a try you will see that it is infinitely more flexible then puppet is. All the systems i have automated with puppet have ended up with horrible hacks to get around the puppet configuration language. Having your recipes in pure ruby is a huge win, also having recipes run in a deterministic order is a huge win. Also being able to go into the codebase and hack it to your needs is another huge win. Trust me when I say chef wins over all of these other systems on a number of levels.
  6. Adam said about 24 hours later:
    It's not a one tool world - people should use the tool that works best for how they think and view the world. We're working on a blog post about why we built Chef instead of enhancing Puppet. Puppet was very close to that tool for me (and that shows by how close Puppet and Chef are at DSL layer), but it wasn't quite right (for me). Watch blog.opscode.com in the next few days to see this theme expounded upon.
  7. stahnma said 1 day later:
    I don't understand why they couldn't have just contributed to the puppet community. It's barrier to entry is low, and they accept patches and ideas. Having one great tool is better than 2 less great. Forking after conflict is one thing, but just starting something new without even trying to enhance the current product seems like a waste of valuable talent.
  8. Thomas said 1 day later:
    The puppet devs are pretty strongly opinionated about not using ruby for configuration. While I understand their reasoning, I don't agree with it. Fundamental changes in a project like that are not something a patch can do. Usually, they are best left to a new project to try out the idea & prove its merit. I'm sure each system will find its niche. I am *really* impressed with what I'm seeing in Chef so far. I'm going to use it to set up a server this weekend and see how it goes.
  9. Blue Ray said 1 day later:
    Interesting point of view. This puppet thing is funny.
  10. Andrew Clay Shafer said 2 days later:
    There was actually an internal Ruby DSL for Puppet, but no one in the community used it and it hasn't been maintained. Certain members of the community were dead set against an internal DSL. Their arguments are cogent in context, as heretical as they might seem to the Ruby purists. I think the primary difference is the mentality of managing corporate infrastructure vs building web infrastructure. Obviously, you would expect a different bias and Puppet has built plenty of both. Congrats to Adam and Opscode (and thanks for the kick in the ass...) More tools is good, go out and build stuff.
  11. Jesse Robbins said 3 days later:
    It's funny how many people have confused the title of this post as a slam. ;-)
  12. James Turnbull said 3 days later:
    What Andrew said - :) It is very much about different markets. In the enterprise (and by that I very crudely parse as the non-"web" ones) there is a different mentality at work. In that world they want something that everyone - not just the Perl/Ruby/Python/insert systems programming language here - can use quickly and out of the box. Some of that decision/thinking might not be rationale in terms of potentially how easy it is to pick up a Ruby DSL but it's a consequence of introducing meat into automation. A lot of shops also actively resist tools WRITTEN in languages that they don't consider "core" to their operations. For example, heavy Perl shops sometimes (irrationally?) don't want to introduce a Ruby-based tool, etc. The use of an external language versus a Ruby DSL stems from some of that thinking. Only time and customer uptake will tell which holds true but I look forward to seeing the results.
  13. http://www.railsware.com said 16 days later:
    nice. we believe in Chef
  14. Ray said 29 days later:
    Now thats what you call a blog title! lol.
  15. Clay McClure said 74 days later:
    I'm a little late to the party -- I hope somebody saved me some cheese dip.

    While I agree that a Ruby DSL would be superior to Puppet's configuration language in many respects, I understand that it's not an easy selling point in the corporate square. There is a mental hurdle to get over (and this can be a very high hurdle for corporate security engineers, whose default policy, much like their firewalls, is set to DENY) when you think about your configuration files actually being executable code. Propose storing your executable configuration in a database and watch the corporate firewall guy's head explode.

    To James' point about Ruby not selling well with legacy admins in Perl shops: it's unlikely that old-school admins mired in antique Perl scripts indistinguishable from line noise are the kinds of people that will be installing automation software, anyway. Don't design your software around the kind of people you're trying to obsolete. Not to put too fine a point on it, but automation requires a mindset that some sysadmins will never have.

    (Disclaimer: I have written my fair share of crufty Perl scripts. There's nothing necessarily wrong with Perl or sysadmins that use it, but if you're still writing Perl CGI scripts in 2009, for instance, you've probably missed a few time-saving advancements that have occurred over the past fifteen years.)

    While I ultimately think competition in the configuration management space is healthy and will encourage innovation, I don't see why the Opscode peeps couldn't have shared the love a little and sponsored the development of a Puppet configuration engine rewrite. Some of the Opscode principals clearly made bank installing and configuring Puppet, work that would not have been possible had Luke et al not delivered something that mostly works without spending a bunch of time developing and supporting a DSL that nobody was using.

(leave url/email »)

   Preview comment