Vagrant and Docker are two technologies the CPT uses heavily for building, testing, and deploying services and software. Each of these tools play a different role, and some of the major differences are summed up very nicely in these two comments from the respective projects’ authors.

Vagrant

Vagrant builds VMs. The sole purpose of Vagrant is to help you deploy (known as “provisioning”) a complete, virtualised OS in a repeatable way. It provides numerous methods to do the provisioning (Chef, Puppet, Bash, Ansible, CFEngine), and provides numerous providers to do the provisioning on (VirtualBox, AWS, VMWare, OpenStack)

With Vagrant, you develop your Vagrant file and associated scripts to build a VM, and then you can rebuild that VM as often as needed, and deploy to whatever architecture is appropriate for your organization

Docker.io

Docker is a relative newcomer in the world of virtualisation, building on the formidable LinuX Containers (LXC) project. Docker is incredibly lightweight in comparison to VirtualBox and focuses on running a single process, rather than running an entire OS.

With Docker, you develop a Dockerfile which builds up an OS in layers of filesystems, each layer consisting of a RUN command or an ENV setting (for example). At runtime, using AUFS (another union filesystem), these layers become invisible to a single process running in a highly specific environment.

Virtualisation at the CPT

So with these two great technologies, how do we make use of them?

Vagrant

Vagrant with the Virtualbox provider is an invaluable tool in our Galaxy development contributions. By using a Vagrant environment for Galaxy development, we can ensure that our testing environment is identical every time we provision a VM. We can then do all of our development with the knowledge that our environment and deployment procedure will be identical every single time. Furthermore, we know that changes we make during one development cycle will not influence testing during a different development cycle.

The Vagrant build/use cycle is very friendly for software development purposes, especially when you’re developing system services.

$ vagrant up

This bring up your VM and provisions it according to your specified rules

$ vagrant ssh

This command SSHs into the VM and then you can start your development work, restarting services, running commands with passwordless sudo, all the nice things you’d want in a development environment without affecting anyone else on your system. The host directory where your Vagrantfile is, is exposed in /vagrant/ allowing you to attach a Vagrantfile to existing projects/repositories to allow users to easily build and play with your software

$ vagrant halt # or destroy

When you’ve completed your work, you can bring down the VM to release those resources.

Docker.io

Docker is quickly becoming one of my new favourite tools. Docker at the CPT is mostly used for deploying services and building services in a repeatable fashion. Here’s an example Dockerfile which covers a couple aspects of Docker that make it really lovely to use.

At the head of the dockerfile, we see

FROM bgruening/galaxy-stable:latest_2014.08.11

This statement says “take this other container image as a starting point, our commands will be applied on top of that”. When building a container based off another container, Docker will fetch all of the components that make up the parent, before building your container. This really lends itself to repeatable builds and a great community of images.

In the linked Dockerfile, there are plenty of

RUN <some command>

Statements like these run commands in a docker image, and are used to build up the container in layers. Often these will consist of installing dependencies, setting up environment variables, provisioning your service, and so on. Finally, we see

EXPOSE :80

Autostart script that is invoked during container start

CMD [“/usr/bin/startup”]

which sets the default command to run, and exposes a port. When the container is run

docker run image/name

That service is then available to you, running in a tiny, lightweight container. These containers are easily shareable and can provide an easy way to deploy a service without requiring a lot of work from a user. No dependency/environment management is needed, as you’ve already done that in your container.

At the CPT we’re currently working on a few different Docker images:

• Interactive Environments, a part of Galaxy that make use of Docker for running isolated services on a one-off basis.
• Chado
• WebApollo

Resources

• Vagrant Boxes
• Some more Vagrant Boxes
• Docker Registry
• Galaxy running in Docker
• The first Galaxy Interactive Environment, one of the amazing uses of Docker
• Online docker tutorial
• Vagrant tutorial