I've been hearing great things about puppet, chef, vagrant, and friends for a while now, but since I work on my own I tend to either develop straight onto my ubuntu machine or grab an appropriate existing VM and use that. So I read about this brave new world of virtualisation but (as with most tools) they can be hard to introduce on your own, and I didn't.
Then I went to WhiskyWeb, which had a hackathon. I'm unclear on exactly what happened because my attention was elsewhere but it seems like @JayTaph showed off puppet and vagrant to @deizel*, who immediately built a vagrant setup for joind.in, which is an open source project that I'm currently leading. With the shiny new technology all packaged for me, I decided it was time to take a look!
Starting the VM
The goal is that a user can simply grab the code base and type a single command:
When you do this the first time, then a "base box" is downloaded and puppet installs the various packages that will be used to run your platform. Once you have the base box, you can use it again with a different configuration; very handy for anyone working with similar-but-not-quite-identical projects. The setup process goes beyond the platform and also sets up the application with appropriate configuration files, databases created and so on. This is fabulous because if you break something, change platforms, or otherwise get into a tangle of any kind - you can just recreate your platform!
If you've run the virtual machine before, this command just starts the VM again so that you can use it.
Pausing Between Sessions
You probably don't want to leave the VM running all the time (I have a shiny new machine with enough RAM that I can if I want to, which is nice!), and just like any other virtual machine you can shut it off and restart it at the same point later on, using:
What I like about this is that it's so simple :)
Throw it All Away
If for any reason, either you broke something, or you have new puppet config perhaps, you want to throw away your VM and start again, that's easy to do:
We keep the base box, but throw away the actual VM instance when we do the above. This means that you get an entirely clean installation when you run
vagrant up the next time, with everything reset to the way that it was. All the settings are very configurable so if you do end up making any changes on the VM, you can also make them in the configuration so that the next time you create the VM anew, those changes will be included.
Something I really liked about this setup, in comparison to the way that I usually do virtual machines, is that the VM shares files with the host machine. Joind.in is hosted on github, so I grab a copy of the repo, type
vagrant up, and then just edit the files in the current directory as I normally would. I'm a vim user, so editing files on virtual machines has never really bothered me, but if you use a desktop IDE then this feature will make a big difference to the way that you work with it - and even for vim users, this eliminates the need for copying of .vimrc files and swearing at distros that install one leg of vi and call it good!
The vagrant box also knows how to connect to itself, so to get shell access you simply need to ask for it:
I think especially if you have a bunch of machines running, or potentially running, because all your development uses these platforms, this approach becomes increasingly valuable as you don't have to keep tabs on hostnames or IP addresses. When you are in the directory for this project, the command gives you access to this VM ... simple!
Shiny New Tools
It's always easiest to learn something new by looking over someone's shoulder (which is why I teach a tools course) and while I'm sure I'll be diving into configuring the virtual machines in detail over time, just having this setup to try has been a great way to get started and see how it could work, tweak a few things on my own copy and so on. Personally I'm delighted to have come across vagrant in such an approachable way - if you want to have a play yourself, then feel free to clone the joind.in repo on github to take a look at what we have there. Thanks again to all the fabulous contributors who make this project what it is and continue to educate me every day!
* I haven't figured out if it makes more sense to link to twitter or github when citing people who have done cool code-related things