Sooo……

Last week I was starting to Play with chef and as part of that I was convinced by Tom (one of our Sysadmins) to stop building servers in Amazon and using them as development boxes. Traditionally I like to build things from the ground up and in stages, get the OS right, get the App right, get the tools right roughly in that order. By building the box from scratch, making a few changes in puppet and then re-running the scripts and continuing to iterate over the deployment you gradually build up to something that works. The down side with this can be that if you don’t re-deploy you never know for sure if it will work from scratch incase a step was missed, it can be costly and you are dependant on the network be it local or internet to be available.

So over the last few months on and off there had been various attempts to get Vagrant to work with virtual box on my Mac (10.6.8) now for what ever reason it never quite worked and therefore was pointless. However a swift reset of the laptop and an upgrade to Lion (10.7.5) seems to have resolved my issues, now being unblocked on a Vagrant front it was worth giving it a go.

Set up

It’s really quite straight forward, Firstly you need VirtualBox Secondly you need Vagrant Then you need a well constructed getting started guide like This

That’s pretty much it to get up and running, You may want to get a few more Boxes for centos or something else but other than that getting a simple box up and working is easy, and to login you just type “vagrant ssh” Simple.

But what about making it useful? So with the help of Tom we were able to hook Vagrant into chef, to do this we set a number of chef type options that define where various cook books or roles are that enables the virtual guest to access the files and there fore you can run them locally, try following This

I was using this with Roles, but just defining a list of recipes also works well. Best of all you can now open up 3 terminals, One logged in to the Vagrant box, one in the vagrant boxes directory and one in your chef repo. I found this worked well as I was able to make changes to my recipes in the chef repo, run “vagrant provision” or “vagrant reload” as needed in the other and tail any logs or watch any starts in the vagrant image. All in all it works quite well you have a disposable box if it all goes wrong you just start again and easy way to update / test the configuration before committing it or pushing it anywhere near production.

Gotcha

So overall after set up all is good. Unless for example your role file has something in it that works perfectly locally and not remotely, I’m not talking about recipes not working I’m talking about the role file having slight differences which was annoying, particularly when you’re new to it.

In particular I had

"json_class": "Chef::Role",

in my role file and this worked fine locally and then failed remotely, not sure what was causing this to be an issue but at least it is easy to resolve by just removing it.

According to This it’s needed (as below)

json_class
This should always be set to Chef::Role.
This is used internally by Chef to auto-inflate this type of object. It should be ignored if you are re-building objects outside of Ruby, and its value may change in the future.

But it id cause me probs, but in some ways much less annoying than the other issue I had. I had run chef, but it seemed to fail to update my yum repos, they already existed before hand and it just ignored them, I kept re-provisioning and nothing, was very confused by all of this. So I stopped playing around and went for a vagrant reload, Nothing still, Turns out chef has a stupid setting in its provider for yum repos. In short for file sin yum.repos.d it will not replace it if it exists which for a configuration management tool is pretty poor, every other type of file seems fine but they are “protecting” yum repo files for an unknown reason, I can only assume to stop people nuking their box, but That’s not opscodes’ call.

You can see a bit more detail Here

That was annoying, an annoying chefism, but at least it is possible to easily disable it as mentioned in the link above or simple to just remove the file first

Summary

All in all quite pleased with the local development, I hit some issues when I deployed to an actual box which is to be expected, but other than that it’s all been quite good. Going forward I’m going to carry on and I will also see how I get on trying vagrant with Puppet as well seing as it can do it, so it should help a lot with development. Unfortunately because of the laptop re-build I am yet to reap the rewards of this new efficiency but I can definitely see it helping in the longer term, particularly when I’m without Internet access. I’d recommend everyone at least spends an hour or two having a play with this as it could simplify your life, especially if you are not able to build servers in 5 mins, or if you just want to work “off grid”