Optimising local development

• Michael Kudenko's blog

Using virtual machines (VMs) is the first step to optimising the development process. That allows us all to work in the exact same environment which replicates our production server settings. Regardless of which OS is running on our computers, OS X or Linux Mint, we all spin up a VM which has Ubuntu 12.04 at its core with Nginx, PHP 5.3 and MySQL. That way we eliminate any software compatibility issues that might occur during deployment to the live server. The popular expression "works on my machine" no longer exists in our vocabularies.

It all starts with VirtualBox, which allows us to run multiple operating systems simultaneously. There’s not much to it really, you just spin up a VM, install all the required software, or provision the VM, and you are ready to go. And if you need to replicate your VM, you can create an image of the current state of the VM.

However, there some major downsides to that approach:

• manual provisioning takes a long time
• hard to keep track of what has been installed
• VM images can’t be version controlled

That’s where Vagrant and Ansible come in. Vagrant takes care creating and taking down the VMs and Ansible handles their provisioning.

Let’s start with Ansible. It is an automated deployment tool. It allows you to install and configure software on any computer - can be your laptop or a remote server. All the actions are performed via SSH.

There are 2 major alternatives to Ansible - Puppet and Chef. All 3 tools were built with the same goal in mind - to make it easier to maintain remote servers. Puppet and Chef are highly popular, but their downside is that they are not that user friendly and have a steeper learning curve. We needed a tool that we could start using right away with minimal effort.

In Ansible, server configurations are called playbooks. They are a set of yaml files, which are super easy to read and maintain.

Here's an example of installing Nginx.

---
- name: Nginx | install nginx
  apt: pkg=nginx state=installed
  sudo: true
 
- name: Nginx | nginx settings
  template: src=nginx.conf.j2
            dest=/etc/nginx/nginx.conf
  sudo: true
 
- name: Nginx | start nginx
  service: name=nginx state=started
  sudo: true

Of course, the setup can be of any complexity. Anything that can be done in the terminal, can be automated with Ansible playbooks. As you can see, it is a much cleaner compared to bash scripts. Another benefit of Ansible compared to bash scripts is that playbooks can be run again and again, ensuring that your system is in the desired state. Bash scripts, on the other hand, can be dangerous to run more than once.

Our playbooks are quite extensive, and it takes about 15 minutes to fully provision the VM. But it only needs to happen once, when you set up the VM for the first time.

Now let's talk about Vagrant. You can think of it as a wrapper around VirtualBox and Ansible, it makes them work together out of the box.

Spinning up a new VM is a 3 step process:

• Vagrant builds a VM from a pre-build image (called "box"). See https://vagrantcloud.com/boxes/search
• Vagrant sets VM specific settings (IP address, hostnames, port forwarding, memory, etc.)
• Vagrant launches provisioning script (executed by Ansible)

The beauty of Vagrant is that all that configuration is stored in a single text file called Vagrantfile, and all these steps are launched with only one command:

vagrant up

Using Vagrant and Ansible allows us to keep full control of how our development environment is configured. Needless to say that it's version controlled. And if we decide to modify the setup, we just update our Ansible playbooks. After that everybody on the team pulls the latest changes and updates their VMs with a single command:

vagrant provision

We understand that this is a pretty high level description here, and you'd probably like a bit more detailed explaining how to actually use the tools. In one of the next posts we will walk you through the process. Stay tuned.