Fully configured ruby development environment with vagrant - vagrant

Question

I would like to have a fully configured ruby unix development environment using Vagrant configuration and provisioning. Ideally it would refer to a simple base box (e.g., precise32) and build the environment up through provisioning in such a way thait it will easily be repeatable for other team members, can be posted to github, and can be upgraded as new versions of the different technologies are available by just changing the provisioning. I have not found any full examples of this searching the web although [Rails Dev Box][1] has some useful ideas. Most of the dev environment examples (like Rails Dev Box) do not set up the guest dev environment because they assume dev will be done on the host using a shared file strategy - or if they do the configuration by hand and then save the box rather than provisioning it.
This also needs to work both in behind a proxy as well as with no proxy.
Here are the steps I am thinking will be required:
On the host:
install virtualbox, vagrant, vagrant proxyconf
On the guest, via Vagrantfile/provisioning:
use a base unix box (e.g., precise32)
optionally set proxy variables (if proxyconf plugin is installed and http_proxy env var is set)
provision everything else (puppet, chef, or shell script)
install various unix tools (apt-get install git, etc.expo ...)
set up bash environment
set up vim environment (pathogen plugin, ruby plugins, etc.)
install rvm
install ruby 1.9, 2.0, JRuby, Rubinius
installs and configures tmux
Ideally I could push this into github, it could be cloned, then cd to new directoy, and vagrant up to have a fully configured dev environment ...
Does anyone have any examples of doing this?

Answer 1

My preference for doing a task like this would be to use puppet as the provisioning step in your Vagrantfile.
With something like this, you can always get something thrown together quick and dirty by just doing all the steps in a shell provisioner... but I prefer the puppet and modules approach as I've found it easier to maintain, extend and to share with the team.
I've experimented with a couple of different ways of doing the provisioning with Ruby and rvm as you mentioned;
Theres the rvm puppet module by maestrodev which allows you to configure many of rvms core features: ruby versions, gemsets, gems and rvm wrappers. Typically to manage which puppet modules are included with a project I use the librarian-puppet gem which allows you to use a Puppetfile to specify the module and the version you require, much like bundler. This handles dependencies such as the stdlib and concat modules. This scenario requires external internet access to have been configured before provisioning so as to be able to download ruby and rubygems.
Offline installation of rvm - I made the relevant files (rvm itself, ruby and rubygems) accessible to the vagrant machine using a shared folder and turned the offline rvm instructions into a (not very good) puppet module and used that. One particular gotcha to pay attention to here is the naming of the ruby source that gets installed; the extension has to be .tar.bz2, its described in the list.
Additionally for your other provisioning steps you can build up puppet modules yourself for your additional requirements: vim / tmux etc and keep this versioned separately in git. You can get pretty far with modules with just the 'puppet trifecta':
class vim {
package { 'vim':
ensure => installed,
}
file { '.vimrc':
ensure => file,
...
}
}
Additionally check out the puppet forge for modules which might have already been written to do what you want.
So heres an example of what you could check in:
/ Puppetfile
/ README.md
/ Vagrantfile
/ puppet
/manifests
site.pp
And the vagrant provisioner would be
Vagrant.configure("2") do |config|
config.vm.provision "puppet" do |puppet|
puppet.manifests_path = "puppet/manifests"
puppet.module_path = "puppet/modules"
puppet.manifest_file = "site.pp"
end
end
I've used a rake task before to use librarian-puppet to pull in puppet dependencies from git / puppet forge and any additional steps you might need to do before vagranting up. This way the code as configuration is all you check in.
Finally, with puppet you can use the facter and hiera tools which are very useful for keeping data out of your modules and worth having a look at as a means of refactoring once you have your initial setup working.