Developing with local tools (IDE, Sublime/Coda/etc) but testing code on a remote machine or local VM can be painful because of the effort required to push the updates to the machine running the application. Vagrant solves this problem with the concept of Synced Folders. For me, this is easy to relate to VMware’s Shared Folders feature of Fusion/Workstation. And as it turns out, this is exactly what’s happening – the Shared Folders feature of the provider is what enables this functionality. This feature allows a local folder to be mirrored with a folder in the guest OS of a virtual machine. What this accomplishes is that very little effort is required to make updates using local tools, but have the changes reflected in the development environment.

Setting up Vagrant Synced Folders

Synced folders are actually enabled by default; the project directory (the one your Vagrantfile lives in) will be shared with the guest OS at /vagrant. That’s handy enough for getting files back and forth. But the real power of this feature can be shown with a simple example. Let’s say the running Vagrant machine is an Apache server. By sharing the DocumentRoot folder with the host OS, development can be done on the same files that are serving the web page. This means no pushing and pulling to see the changes you’ve made reflected live. Setting up Synced Folders for a given objective is simple: just add the config.vm.synced_foldermethod to the project’s Vagrantfile, specifying the path on the host machine and then the path on the guest machine.

As an example, on my machine I’m using a Vagrant box to do WordPress development for this site. I’m able to play with CSS and make changes to the site’s appearance without tinkering with the live version. Testing new plugins offline is also something I do with this. In the Vagrantfile for my testing box, the following configuration shares the website files:

config.vm.synced_folder "www/", "/srv/www/", :owner => "www-data", :mount_options => [ "dmode=775", "fmode=774" ]

The extra options at the end set permissions on the directory, and specify options to pass to the mount command. This allows me to use Sublime Text 3 and other tools on my MacBook Pro to manipulate the files actively being served from the web server I have spun up. In a more complex environment, you may want to enable/disable the Synced Folder based on conditionals during project setup. Disabling the share can be accomplished by appending disabled: trueto the line.

Alternatives

Depending on the environment, a Shared Folders feature for the provider may not be available. But not to fear! A Synced Folder configuration can also be set up to use NFS for Linux machines (or RSync when nfsd is not available on either the host or guest) and SMB for Windows machines. This means that with few exceptions, Synced Folders can be configured in every environment.

See the full official documentation on Synced Folders here, and don’t forget that the project root is already synced to /vagrant! Next up, a brief look at Vagrant networking.

Your use case for Vagrant will determine what sort of networking setup is appropriate. The good news is that there are plenty of options. Vagrant defines three high-level options for networking that are then implemented in a specific way by the provider. The three options – which are a generic description of a type of access – are:

• Port Forwarding
• Private Network
• Public Network

All networking configuration is specified with the method config.vm.network.The identifiers for each type of network are :forwarded_port, :private_network, and :public_network. Following this is a set of options which change based on the provider and the type of network being specified. An example Vagrantfile line for a port forward to port 80 which the host can access on 8080 would be as follows:

config.vm.network "forwarded_port", guest: 80, host: 8080

Multiple networks can be configured simply by adding multiple lines of this same sort of specification. After updating networking in a Vagrantfile, a vagrant reload will make the settings take effect.

Vagrant Networking Options

Port Forwarding

Port forwarding may be the simplest option if only local development is taking place and other local environments don’t need to interact with the one in question. It’s probably less confusing to use a private network in a multi-machine configuration, but in a single machine environment, port forwarding is a simple way to access the guest machine. Do take care to specify whether the forward needs to be TCP or UDP. The forward uses TCP by default, so it will need to be changed if UDP is required. Also, if the port forward needs TCP AND UDP both, you must specify two separate port forwards – one for each. The full list of configuration options for a port forward (as taken directly from the documentation) is as follows:

• guest (int) – The port on the guest that you want to be exposed on the host. This can be any port.
• guest_ip (string) – The guest IP to bind the forwarded port to. If this is not set, the port will go to the every interface. By default, this is empty.
• host (int) – The port on the host that you want to use to access the port on the guest. This must be greater than port 1024 unless Vagrant is running as root (which is not recommended).
• host_ip (string) – The IP on the host you want to bind the forwarded port to. If not specified, it will be bound to every IP. By default, this is empty.
• protocol (string) – Either “udp” or “tcp”. This specifies the protocol that will be allowed through the forwarded port. By default this is “tcp”.

Vagrant is intelligent enough to not let you spin up two machines with port forwards using the same host port (8080, for example). By default, this will simply not be allowed. But you can also specify :auto_correct to have Vagrant resolve the conflict on its own.

Private Network

A private network configuration will allow the machine (or multiple machines) to be assigned an IP address in private address space accessible only from the host machine. How this is accomplished depends on the provider; for instance, VMware Fusion would create vmnet? and install a virtual adapter on the host machine connected to this network. This may be less confusing to use in a multi-machine deployment. It does, however, require that at setup time the user has permissions on the host machine to install a virtual network adapter. The private networking mechanism of the provider should have the ability to hand out addresses via DHCP, and that’s likely the easiest way to use this configuration. A static IP can be set if necessary, though.

Public Network

A public network configuration is much the same as a private network, with the exception that the network adapter of the guest machine is actually bridged to an adapter that is connected to the upstream network. You can either specify the adapter to bridge to in the Vagrantfile like this:

config.vm.network "public_network", bridge: "en1: Wi-Fi (AirPort)"

Or, you can leave it unspecified, and when you do a vagrant up, a wizard will prompt you for the adapter to bridge to, like this:

==> default: Available bridged network interfaces:
1) en0: Wi-Fi (AirPort)
2) en1: Thunderbolt 1
3) en2: Thunderbolt 2
4) bridge0
5) p2p0
6) awdl0
==> default: When choosing an interface, it is usually the one that is
==> default: being used to connect to the internet.
    default: Which interface should the network bridge to?

One word of wisdom when using this wizard – @vmcutlip and I found out after fiddling with it a bit that the wizard is asking for the menu number, not the interface name. So specifying ‘en0’ will bomb, and not be very specific about why. If you want en0, just type ‘1.’

As mentioned, the implementation of these three options will differ depending on the underlying provider. So be sure to do some research into the exact provider in use for your case. Next up in the series, Teardown!

I’ve been hearing about Vagrant for well over a year now, but until this point I haven’t had a requirement to dig in. Vagrant seems to come up in the same conversations as configuration management tools like Puppet, Chef, Ansible, and so forth. Those are tools I’m also only vaguely familiar with. I created a few Puppet manifests a while back just to get the idea, but maybe Puppet should be the next series! But in the short term, we’ll use a bit of Puppet in this series to configure Vagrant boxes. At any rate, this series is going to walk through the concept and implications of Vagrant, the initial setup and use, and then branch out into some more interesting stuff. Let’s start at the beginning.

What is Vagrant?

Vagrant is a tool developed by HasiCorp (named after founder Mitchell Hashimoto) to facilitate the rapid and accurate deployment of development environments. Historically, there have been many hours spent on-boarding new employees, setting up contractors or consultants, and recreating production environments on development systems. The aim of Vagrant is to eliminate that overhead by automating the deployment of development systems, the configuration of which is stored in a version control system like Git. This ensures not only efficiency, but unity between team members and environments.

Vagrant is the configuration engine, but workloads are still provisioned in virtual machines or containers on the platforms you know and love like VirtualBox, VMware Fusion/Workstation, Docker, or AWS. There’s a growing list of providers, and if none of those fit the bill, you could also roll your own.

Why Would I Want Vagrant?

As mentioned, a few of the main benefits of leveraging Vagrant are the rapid provisioning time of new environments, as well as the ability to reproduce environments with 100% accuracy. That may mean mirroring the production environment to be sure development is taking place on a matching system, or it may mean ensuring that all developers on a team are using the exact same development environment as they create and test code. The granularity of dependencies in some systems can make manually replicating a development environment extremely challenging; but this is actually quite simple with Vagrant. And because Vagrant is doing the configuration, the system can be deployed on Windows, Mac, or Linux with exactly the same result.

Now, I’m the farthest thing from a developer, which begs the question: “Why do I care about Vagrant, and what use could it have for me?” Well, first and foremost, my job as an infrastructure architect is to design a platform that makes developers productive and helps them to deliver their product efficiently and with as few bugs as possible. Understanding how Vagrant can make them more efficient will help me design a better infrastructure for them. Secondly, however, there are certainly applications for infrastructure/operations folks. Imagine I’m creating a shell script to configure production systems in mass. It would take a matter of minutes to spin up a similar system local to my machine that I can test my script on as I create it.

How Do I Get Started?

Thankfully, since I’m so far behind, the installation of Vagrant is super easy at this point. The next post in this series will document the initial setup and instantiating my first Vagrant box. As a very brief preview of how complicated Vagrant is, the steps to get up and running follow.

• Install VirtualBox
• Install Vagrant
• Download and initialize a “box” (a Vagrant environment package)
• Run ‘vagrant up’

At the end of that whole 10-15 minute span, you’ll have a running machine configured exactly as specified and ready for consumption!

I think this is going to be a great learning experience, and I hope that by learning how to make the best use of Vagrant, I’ll also get a good head start on some other tools like Puppet/Chef. I also hope to wrap my head around the day-to-day life of a developer a bit better. As DevOps culture becomes increasingly popular, the infrastructure engineer / developer hybrid role is quite valuable. And I’m all about being valuable. 🙂

Installing Vagrant came with a decision for me: use the free VirtualBox integration (which is probably sufficient, but feels a bit disloyal to me!) or pay $80 for the VMware plugin that would allow Vagrant to build machines in Fusion (or Workstation, if that’s your thing). If this were something I planned to use every day, I would definitely pony up for the Fusion plugin, but since I’m only learning, I went the free route.

Vagrant Installation

This installation process couldn’t be simpler. Simply download VirtualBox beforehand, and then download the latest version of Vagrant.

• Download VirtualBox – https://www.virtualbox.org/wiki/Downloads
• Download Vagrant – https://www.vagrantup.com/downloads.html

Both applications are a Next > Next > Finish sort of installation. Just download the installer and run it.

To test initial functionality after the install, we’ll run vagrant init hashicorp/precise32 and then vagrant up. That’s literally all it takes to get a fully functional Ubuntu machine running on Vagrant! I can’t get a decent Internet connection where I live, but even with my itty-bitty bandwidth, this process was fast. The time from when I decided I wanted to play with Vagrant to the time I was running an Ubuntu VM (which included downloading VirtualBox, Vagrant, and the Ubuntu box) was about 15 minutes! Also, provisioning this box from scratch if everything was previously downloaded takes about 60 seconds on my machine. And if it was already provisioned and just halted, starting it again takes <10 seconds. Imagine how useful this is for quick testing!

[Read more…] about Vagrant Series » Installation and First Vagrant Up (Part 2)