Economy Size Geek

Иконописиконографиямека мебелИкониI was driving in my car and catching up on some podcasts. I switched on the Change Log. The episode was all about DevOps. I love it when I find out that there is a term for something I’ve been doing for a while.

In the broadest sense, DevOps is about bringing development practices into the system administration universe. Most of the time I end up playing the system administrator on the team (until we get large enough that we can hire an actual system administrator). I always felt like the practices would be improved by adding in a more developer way of looking at things.

For a while I used something called cfengine. It was a HUGE improvement over no configuration control whatsoever. It is the grandfather of this whole movement in a lot of ways. Just as a word of warning, unless things have significantly changed since I used it – please don’t use cfengine. It is very exciting at the beginning when you start to get stuff to work, but as change occurs it gets harder and harder to keep up.

After seeing the potential of cfengine, I started looking for an alternative. I found Puppet It is written in Ruby (which is great since I’m ruby fluent). It also seemed to be able to address a lot of the problems and frustrations I had with cfengine. There weren’t a lot of alternatives. I spent some time trying to get everything to work. My dream was to be able to build a complete virtual environment in kvm that would let me model the entire deployment of our applications. Not too long after I started down this path, someone announced that Puppet sucked and that they were starting a new tool – Chef. Chef had a more bare metal approach to configuration management. I ended up avoiding it because at the time there was no way to tell if they were going to build a community and survive.

In the end, I ended up dumping all of them. Not because they weren’t good, but because instead I started launching apps at Heroku. Since it takes care of so much of the deployment stuff, I just quick worrying about DevOps all together. It takes me about 5 minutes to get a Rails/Javascript app working on my workstation and it seems a little silly to bother with Chef or Puppet for that.

From the sounds of the discussion on the podcast, Chef has come a long way since there. There is both a community and a company behind it. Which is good to hear. About ten minutes in they started to discuss something that is having a profound impact on my relationship with my brother – Cinderella

It only takes me a few minutes to get my development environment up and running. My brother is my designer. As you might expect he runs a mac. Actually, he runs a lot of macs. He has a mini at home, a macbook in his bag, and a mac pro at the office. It is not bad enough that getting all the open source stuff onto his box is a pain, but keeping all three boxes working is a special form of hell for me. It turns out I’m not the only dev out there who hates having to support a designer on a mac.

That’s where Cinderella comes it. It is built up on homebrew and chef. Officially, to get running you just do the following on a mac:

curl https://github.com/atmos/cinderella/raw/master/bootstrap.sh \
-o - | sh

You wait for it to complete (about an hour) and then you are off to the races.

We ended up doing a lot of experimentation with this so let me help avoid some serious pitfalls:

1. Update X-Code!. The first time we installed Cinderella was on a box we had just installed Snow Leopard on. It turns out that there is an X-Code update you need before Cinderella will work.
2. Update Rubygems. Apple is trying to be helpful by shipping macs with a bunch of gems pre-installed. They are all out of date. The most important one to fix is RubyGems itself.
   sudo gem update --system before you start the Cinderalla process or you will run into problems installing bundler later.
3. You can do this on a mac that isn’t freshly installed. We did it once on a freshly installed macs and then switched over to installing in on his macs that already had other software installed. The key is to get rid of fink/macport, /usr/local, rvm, and any other open source software that you installed in the mac in some other way. You could probably keep them around, but it will end up being a lot more confusing so clean out before you start installing
4. I put in a bug about this – but if you are using .rvmrc files in your project – add .rvmrc file to the person’s home directory with:

   export rvm_install_on_use_flag=1
export rvm_gemset_create_on_use_flag=1

   That will allow rvm to automatically install stuff and will be a lot less confusing for the mac user.

It takes a while for everything to come down, but there is something truly amazing about the fact that you get all of this stuff just installed and working for you. As a bonus, the script can be re-run again to update things. Also, everything it put into ~/Developer so getting rid of it is a lot easier if you decide to bail out.

The only thing I need to figure out now is how to choose which version the software installs (since it chose Postgres 9.0 but to mirror Heroku it needs to be 8.4). That’s a pretty small problem compared to how much effort it saved me.

So if you have a designer and you’re stuck supporting things like ruby,git, mysql, postgres, or node.js – give this a try.

• General
• |
• HeadGeek
• |
• trackback