In this post we will cover moving from a simple Vagrant / VirtualBox / Ansible development environment to a one based on Docker.
In this talk, he demonstrated the performance benefits and functionality to be had by using this lightweight container project over a traditional virtual machine. I was really impressed with how quickly machines could be provisioned and the performance seen inside the Docker containers. (I was also happy to see that Jérôme is an awesomewm user!)
Now for a little context - ever since I started working on multi-service applications, I’ve been excited about the possibility of developing inside a virtual machine. I wanted to know that the same provisioning code I was writing (using Chef at the time) was also used on the system I was working with. This would help me discover things like missing dependencies locally, before the build broke on the continuous integration server (or worse, during deployment!).
I’m now lucky enough to work in an environment where the developers use Vagrant in their local development. This is a god send for keeping down the complexity of managing dependencies, database migrations, and a host of other issues. The tradeoff, unfortunately, is the painfully terrible performance of these virtual machines. Even when provisioned with a generous amount of resources, the performance was still terrible! This led me to a habit of locally compiling and running unit tests, but using the virtual machine to run the application or perform integration tests. This is not ideal. Here’s an example of the performance difference (athas is my machine, precise64 is the virtual machine):
That’s 49% longer on the virtual machine - JUST TO CLEAN. It’s far worse when doing actual work, such as running the application.
You can see why I was excited when I first saw Docker!
To demonstrate how this migration path goes, I’ve prepared a sample project for you to follow along at home. You’ll find the relevant files here. In this project, we use the Grails Petclinic sample. This demonstrates a machine that uses the JDK, grails, and provides a web server on port 8080.
The Vagrant Version
Let’s take a look at the vagrant-based project in action. To get the application up and running, follow these steps:
run-app will likely take a long time - possibly as long as a few minutes. This is
the delay that we hope to drastically reduce by switching to Docker. Once the application is
running, you’ll find the cute Petclinic available at http://localhost:8080/petclinic.
You can make changes locally, watch the grails app automatically reload, and develop as you please.
This is functional, but the performance is pretty poor.
Vagrant version, in detail
Let’s take a look at the contents of the Vagrant directory in detail. Here we have the Vagrantfile, which is used to specify the virtual machine:
This is a pretty standard Vagrantfile with some notable changes:
- We pass port 8080 through to the host machine so we can view the grails app locally
config.vm.network "forwarded_port", guest: 8080, host: 8080 # web app
- We use ansible to configure new machines
config.vm.provision "ansible" ...
Note that this provision block specifies the playbook and inventory path. The inventory simple points to our vagrant host, and the playbook file specifies what needs to be done to a new machine.
Here’s the playbook, in its entirety:
The high level goals of this playbook are simple, install OpenJDK 7, install git, clone the petclinic
repository, and make sure
$JAVA_HOME is set correctly (required for the grails wrapper to work).
These are pretty simple goals - let’s see how we can do this in Docker!
Before moving on to the Docker version, make sure that you stop the vagrant VM. It binds to the same port we will be using for our Docker version, so we need to free up that port.
$ vagrant halt
This will save the VM’s state and halt execution.
The Docker Version
Let’s get the docker version running! First, make sure that the docker daemon is running. To do
this on Arch (assuming you installed via
pacman like a good user):
sudo systemctl start docker
Now let’s create an image from the provided Dockerfile and run it:
$ git clone https://github.com/influenza/blog-snippets.git $ cd blog-snippets/VagrantToDocker/Docker $ sudo docker build -t petclinic . $ sudo docker run -i -p 8080:8080 petclinic /opt/petclinic/app/grailsw grails> run-app
This command will have the same affect as
./grailsw run-app did when used above.
To exit the image:
Let’s take a look at the Dockerfile that is defining the behavior we see here:
You can see that the Dockerfile is a series of steps needed to take the image from the
base image (specified with
FROM) to a ready-to-use image. This doesn’t map 1:1 with Ansible’s
way of doing things, which means that the conversion process is not linear.
A major piece missing from this setup is the sharing of our application directory. The Docker image has its own filesystem, so local edits will have no affect on the image itself.
Luckily, we can change some things to work around this. Let’s make a local copy of the petclinic application.
$ mkdir ~/tmp/docker_petclinic $ git clone https://github.com/grails-samples/grails-petclinic.git ~/tmp/docker_petclinic
Now we can run the image and mount a host directory as a container volume:
$ sudo docker run -i -p 8080:8080 -v ~/tmp/docker_petclinic:/opt/petclinic/app petclinic grails> run-app
You’ll notice when you ‘run-app’ this time, the dependencies will be downloaded again. This is downloading them to the shared volume on the host machine. Once everything stabilizes and the application is running, let’s try making a change locally and seeing if the image will pick it up.
$ vim ~/tmp/docker_petclinic/grails-app/views/clinic/index.gsp
Update the text ‘Display all veterinarians’ to say ‘Display (nearly) all veterinarians’. This is more honest since our petclinic application isn’t tracking all veterinarians in practice. Upon saving the file, reload http://localhost:8080/petclinic and you’ll see your change!
There we have it, a basic functional grails development setup using Docker!
A Final Comparison
To compare apples to apples, let’s see how long it takes to run the petclinic tests on each of our environments.
That’s a difference of 75 seconds - over a minute!
In the next post, we will look at a more complex use case requiring a Postgres database. This will show how to set up an environment requiring multiple docker containers.