J

Why you should be virtualising your development environments

04 Jul 2013

Within my daily workflow I can work on 5-6 projects over the course of the week and the likelihood of anyone remembering the exact dependencies and requirements for each environment is close to impossible. In addition to this, I need a development environment that will replicate the production environment so I spend less time debugging inconsistencies and more time shipping code. The solution? Virtualisation.

There are multiple methods of virtualising environments however I am going to cover using vagrant as it is simple with nil to very minimal performance overhead.

Prerequisites

Vagrant is a CLI tool for interfacing with VirtualBox so be sure to download it prior to trying to use vagrant. I am going to be using my mac however the instructions should be pretty well cross platform.

Installing vagrant

Vagrant is available for download however it is easiest to install via RubyGems.

$ gem install vagrant

Adding a base box

Once that has been installed successfully, you will need to add your box which will house your configuration and OS for the virtual machine. Luckily, there is vagrantbox.es which allows you to get started with a pre-configured base box with an OS already on it. If you are feeling adventerous or need to make your own, there is documentation for creating a custom one! I will be using a default Ubuntu Lenny 32bit base box within the guide so remember to swap it out for your actual box path and name.

To make the box available on your system, you need to add it to vagrant. Easy enough:

$ vagrant box add lucid32 http://files.vagrantup.com/lucid32.box

You should see some output similar to the following. This is Ruby grabbing the box on your behalf so it can be used within your project. Don’t worry where you do this, it will make it available globally.

[vagrant] Downloading with Vagrant::Downloaders::HTTP...
[vagrant] Downloading box: http://files.vagrantup.com/lucid32.box
[vagrant] Extracting box...
[vagrant] Verifying box...
[vagrant] Cleaning up downloaded box...

Creating the Vagrantfile

The Vagrantfile is the source of configuration for the vagrant instance. You can configure anything to do with the box via this single file. Everything from forwarding ports to sharing directories can be achieved and is all backed by solid documentation. To create a Vagrantfile within your project using your newly added box, simply change to the desired directory and run:

$ vagrant init lucid32

Here is an example of a Rails application with just port 3000 forwarding onto the virtual machine.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant::Config.run do |config|
  # All Vagrant configuration is done here. The most common configuration
  # options are documented and commented below. For a complete reference,
  # please see the online documentation at vagrantup.com.

  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "lucid32"

  # The url from where the 'config.vm.box' box will be fetched if it
  # doesn't already exist on the user's system.
  # config.vm.box_url = "http://domain.com/path/to/above.box"

  # Boot with a GUI so you can see the screen. (Default is headless)
  # config.vm.boot_mode = :gui

  # Assign this VM to a host-only network IP, allowing you to access it
  # via the IP. Host-only networks can talk to the host machine as well as
  # any other machines on the same network, but cannot be accessed (through this
  # network interface) by any external networks.
  # config.vm.network :hostonly, "192.168.33.10"

  # Assign this VM to a bridged network, allowing you to connect directly to a
  # network using the host's network device. This makes the VM appear as another
  # physical device on your network.
  # config.vm.network :bridged

  # Forward a port from the guest to the host, which allows for outside
  # computers to access the VM, whereas host only networking does not.
  config.vm.forward_port 3000, 3000

  # Share an additional folder to the guest VM. The first argument is
  # an identifier, the second is the path on the guest to mount the
  # folder, and the third is the path on the host to the actual folder.
  # config.vm.share_folder "v-data", "/vagrant_data", "../data"

  # Enable provisioning with Puppet stand alone.  Puppet manifests
  # are contained in a directory path relative to this Vagrantfile.
  # You will need to create the manifests directory and a manifest in
  # the file base.pp in the manifests_path directory.
  #
  # An example Puppet manifest to provision the message of the day:
  #
  # # group { "puppet":
  # #   ensure => "present",
  # # }
  # #
  # # File { owner => 0, group => 0, mode => 0644 }
  # #
  # # file { '/etc/motd':
  # #   content => "Welcome to your Vagrant-built virtual machine!
  # #               Managed by Puppet.\n"
  # # }
  #
  # config.vm.provision :puppet do |puppet|
  #   puppet.manifests_path = "manifests"
  #   puppet.manifest_file  = "base.pp"
  # end

  # Enable provisioning with chef solo, specifying a cookbooks path, roles
  # path, and data_bags path (all relative to this Vagrantfile), and adding
  # some recipes and/or roles.
  #
  # config.vm.provision :chef_solo do |chef|
  #   chef.cookbooks_path = "../my-recipes/cookbooks"
  #   chef.roles_path = "../my-recipes/roles"
  #   chef.data_bags_path = "../my-recipes/data_bags"
  #   chef.add_recipe "mysql"
  #   chef.add_role "web"
  #
  #   # You may also specify custom JSON attributes:
  #   chef.json = { :mysql_password => "foo" }
  # end

  # Enable provisioning with chef server, specifying the chef server URL,
  # and the path to the validation key (relative to this Vagrantfile).
  #
  # The Opscode Platform uses HTTPS. Substitute your organization for
  # ORGNAME in the URL and validation key.
  #
  # If you have your own Chef Server, use the appropriate URL, which may be
  # HTTP instead of HTTPS depending on your configuration. Also change the
  # validation key to validation.pem.
  #
  # config.vm.provision :chef_client do |chef|
  #   chef.chef_server_url = "https://api.opscode.com/organizations/ORGNAME"
  #   chef.validation_key_path = "ORGNAME-validator.pem"
  # end
  #
  # If you're using the Opscode platform, your validator client is
  # ORGNAME-validator, replacing ORGNAME with your organization name.
  #
  # IF you have your own Chef Server, the default validation client name is
  # chef-validator, unless you changed the configuration.
  #
  #   chef.validation_client_name = "ORGNAME-validator"
end

Getting onto your new machine

Once the Vagrantfile has been generated and you are happy with it, all you need to do is SSH into the machine using vagrant ssh (be sure you’re in the correct directory with your Vagrantfile when trying this).

$ vagrant ssh

Once inside, you can start your services, get new projects rolling, etc. You can also visit your site by visiting http://localhost:3000 (providing the application is running of course :p ). Most people will be fine leaving it at this stage but if you need a solution for multiple developers or other services, you might need to look at integrating puppet or chef into your workflow for provisioning tools.