Using Vagrant and Ansible to deploy virtual machines for web development

Vagrant and Ansible are tools to efficiently provision virtual machines, also called VMs, or in Vagrant terms, the word "boxes" is often used. We begin with a short discussion of why a web developer would invest the time to use these tools, then cover the required software, an overview of how Vagrant works with virtual machine providers, and the use of Ansible to provision a virtual machine.

Background

First, this article builds on our guide to installing and testing eZ Publish 5 in a virtual machine, which may be a useful reference. We'll describe the tools you can use to automate the creation and provisioning of virtual machines. There is much to cover beyond what we talk about here, but for now we will focus on providing a general overview.

Why should you use virtual machines for website development?

The traditional ways that developers work on websites are on remote development machines or locally, directly on their main operating system. There are many advantages to using virtual machines for development, including the following:

• The entire development team can have the same server and configuration, without purchasing additional hardware.
• The local virtual machines can be more representative of the production servers.
• You can bring up the virtual machine when you need to work with it and shut it down when you're done. This is especially helpful if you need different versions of software, such as different version of PHP for different projects.

Vagrant and Ansible help to automate the provisioning of the virtual machines. Vagrant handles the starting and stopping of the machines as well as some configuration, and Ansible breaks down the details of the machines into easy-to-read configuration files and installs and configures the software within the virtual machines.

General approach

We usually keep the site code on the host operating system and share these files from the host operating system to the virtual machines. This way, the virtual machines can be loaded with only the software required to run the site, and each team member can use their favorite local tools for code editing, version control, and more under the operating system they use most often.

Risks

This scheme is not without risk and complexity. A virtual machine is a great tool for your collection, but like any tool, you will need to take some time to learn how to use it.

• When Vagrant, Ansible, and VirtualBox or another virtual machine provider are running well together, they help development to run more efficiently and can improve the quality of your work. However, when things go wrong they can distract from actual web development. They represent additional tools that you need to maintain and troubleshoot, and you need to train and support your development team to use them properly.
• Host operating system: Be sure your host operating system supports the tools you're planning to use. As I mentioned, this blog post focuses on Ansible. Ansible is not officially supported on Windows as the host. That means if you only have a Windows machine to work with, you'll need to consider using Linux as the controller. (There are some tricks to get it to work on Windows.)
• Performance: Remember the intent of these virtual machines is to support development. They will not run as fast as standalone servers. If that is an issue, you will likely need to invest some time in improving the performance.
• An implicit assumption is made that only one instance of the virtual machine will be running on the host at any given time. If you will be using more than one instance of the virtual machine, you'll need to take that into account as you set it up.

Getting started

The first step is to install the required software: Vagrant, Ansible, and VirtualBox. We will focus only on VirtualBox in this post, but you can also use a different provider, including many options which are open source. You may need some VirtualBox extensions and Vagrant plugins as well. Take the time to read the documentation carefully.

Then, you will need a starting point for your virtual server, typically called a "base box." For your first virtual machine, it is easiest to use an existing box. There are many boxes up at HashiCorp's Atlas and at Vagrantbox.es which are suitable for testing, but be sure you use a trusted provider for any box which is used in production.

Once you've chosen your box, these commands should bring it to life:

$ vagrant box add name-of-box url-of-box
$ vagrant init name-of-box
$ vagrant up

Provisioning, customizing, and accessing the virtual machine

Once the box is up and running, you can start adding software to it using Ansible. Plan to spend a lot of time learning Ansible. It is well worth the investment. You'll use Ansible to load the system software, create databases, configure the server, create users, set file ownership and permissions, set up services, and much more—basically, to configure the virtual machine to include everything you need. Once you have the Ansible scripts set up you will be able to re-use them with different virtual machines and also run them against remote servers (which is a topic for another day!).

The easiest way to SSH into the box is:

$ vagrant ssh

You may update your /etc/hosts file to map the virtual machine box IP address to an easy to remember name for SSH and browser access. Once the box is running and serving pages, you can start working on the site.

Development workflow

Using a virtual machine as described here doesn't significantly change normal development workflows when it comes to editing code. The host machine and virtual machine share the application files through the path configured under Vagrant. You can edit the files using your code editor of choice on the host, or make minor adjustments with a text editor on the virtual machine. You can also keep version control tools on the host machine. In other words, all of the code modifications made on the host machine automatically show up on the virtual machine.

You just get to enjoy the convenience of local development, and an environment that mimics the server(s) where your code will be deployed!

This article was originally published at Mugo Web. Republished with permission.