Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Moe has some good points about maintaining these instances, keeping things up-to-date, and launching more sophisticated infrastructure beyond your vanilla Rails/MySQL stack apps.

In my experience, Chef is really not that difficult to get setup, especially for the benefits it gives you: idempotent recipes with a great deal of control over the configuration, setup, and control of your infrastructure.

In the blog post, it mentions having to comment out migrations that will fail. That's bad: when bootstrapping machines, a db:schema:load is far more appropriate and less brittle.

Rubber seems like a half-solution for maintaining infrastructure. The blog post mentions that it was picked to prevent having to manually configure boxes, but it sounds like they chose a tool that only half solves their problem and then leaves them to do manual maintenance.

Now, with some experience, I can get a Rails machine booted and running an app in 20 minutes total with Chef. It's really pretty easy, and having tons of resources, lots of recipes, excellent support, and a sane system makes it super flexible.



The thing that annoyed me about Chef was the need for a Chef server (or their Opscode service). Rubber may turn out to not be ideal so we'll see, but so far it seems to be pretty logical and not that difficult to maintain.

The part about commenting out a failing migration is a bug that shouldn't exist in that particular process, not relevant to Rubber.

I don't mean to sound like I'm vigorously defending Rubber because we just started playing with it but, so far, the criticism seems a little overblown.


> The thing that annoyed me about Chef was the need for a Chef server

You may not have heard of Chef-solo? I've been managing 8 EC2 servers for a project with it and Capistrano, relatively painlessly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: