In this episode we will review Vagrant. Vagrant makes it easy to create disposable environments for testing scripts and infrastructure changes.
In this episode I wanted to give you a demo of Vagrant. Vagrant is the type of tool, that you will start to use, and then wonder how you lived without it. It allows you to quickly build virtual environments, from canned OS images, with a focus on automation. You can quickly fire up a VM, or a set of VMs, that might mimic your production environment, then you can test your scripts or package installs, changes, tweaks or what have you, and then tare down the environment. This can all happen in minutes. So it makes testing changes easy! Sure you can do all this by hand, but Vagrant makes it much easier, by automating many of the steps.
There is a nice demo on the vagrant website, lets walk through it. If you want to duplicate the steps in this episode you will need to install Virtualbox, Ruby, and Vagrant, I have included links in the show notes below.
We are going to run “vagrant box add”, then the box name, and a url where the box can be found. The Vagrant term for box means virtual machine. So we are saying Vagrant virtual machine add, the name, and where we can pull the image from.
# add the lucid32 box vagrant box add lucid32 http://files.vagrantup.com/lucid32.box
# create project directory mkdir vagrant-lucid32 cd vagrant-lucid32
I generally like to create a work directory, then initialize the vagrant box inside that directory by running “vagrant init lucid32”, where lucid32 is the name of the box or virtual machine we just downloaded. A handy message is output, telling is a file named Vagrantfile was create, and also directs us to the vagrant website for additional documentation. The Vagrantfile file holds the configuration settings for this box.
# initialize the box vagrant init lucid32
Lets take a quick peek at the Vagrantfile. You can change many of settings in this file, we can change things such as network configuration, shared folders, and puppet and chef details. Just be aware a box restart will likely be required before changes take effect.
Before we fire up this vagrant box, I am going to create a test file, this test file will be used to demonstrate how the shared folders work between the vagrant box and your host machine.
Lets go ahead and run, vagrant up. This creates a copy of the lucid32 box, that we downloaded earlier, and boots it, along with any settings defined in the Vagrantfile. What I love about this, is that it creates a copy of the lucid32 box. So each time you run, vagrant up, after a destroy, you get a clean duplicate of the lucid32 box.
# start the box vagrant up
This is especially helpful if you want to test some automated scripts and need a clean environment each time. You are free to test destructive changes, without labour intensive task of recreating the environment, so we are free to test our changes. This is where I find vagrant is really useful!
A neat features of Vagrant is mentioned of the last two lines of output. Vagrant mounts our current directory inside the box as /vagrant. This is useful for sharing files between your host machine and the Vagrant box. A common work flow it to have your editor running on the host machine, sitting in this directory, and then you can manipulate files in the Vagrant box via /vagrant. Listing the directory contents, you can see we have the vagrantfile and our test file that we created earlier.
A helpful command is running, vagrant status, this allows you to see the current box state.
# check the box status vagrant status
Lets go ahead and run, vagrant ssh, this will connect us into the box. As you can see we are greeted with the Ubuntu welcome message. I will run uptime, just so we can verify this is actually a VM and it can been up for a breif period of time, and we are not on our local host machine.
# ssh to the box vagrant ssh
As I mentioned earlier, there is a /vagrant mount, as you can see our Vagrantfile file is here along with our test file. Lets go ahead and logout.
We are going to run, vagrant destroy, that will delete this box, key concept however, is that it only deletes this instance of the lucid32 box, our copy, not the original we downloaded earlier. So, we can run, vagrant up, again, and be presented with a copy of the lucid32 box.
# destroy the box vagrant destroy
This makes it easy to incrementally test changes in a new environment, so whether you are a developer wanting to test some code changes, or and operations engineer wanting to test some package installs or scripts, vagrant can be very useful. At this point you are probably thinking Vagrant is pretty cool, but much like me, you are probably wondering how do you create your own images? You can check out episode #5, where I will give you a demo of veewee, which can be used to create your own Vagrant boxes.