People sometimes get confused between Vagrant and Docker. Are they the same thing? If not, what are the differences between the two and how can they help you with your testing efforts?
Vagrant Not the Same
In short, they are not the same thing.
PluralSight author Wes Higbee believes that if you understand Vagrant, you’ll understand Docker. It’s more or less automating something else. With Vagrant, the whole idea is to simplify working with Virtual Machines.
It can be a pretty painful process to get a VM up and running. It can take half an hour if you know what you’re doing. It can take hours or days if you don’t.
Using Vagrant makes the VM process easier. With two simple commands — Vagrant init then Vagrant up — you can have a VM up and running on your machine.
One way in which it makes the process faster is that there’s already a pre-built VM image in the Vagrant Cloud. The image gets pulled down in what’s known as a box. For example, if you want CentOS, Ubuntu, Windows or any other OS image all you need to do is pull down the existing images.
Once you pull down an image, you can use it to create a new VM, which is usually up and running within a few minutes.
What’s a Vagrant File?
What’s cool is that you can control the configuration of the VM from a Vagrant file, which is a Ruby file that gives you a little programmatic configuration language.
This allows you to have, for instance, two CPUs on a VM, or four gigabytes of memory. Or you might want to set up a bridge network so it can get out to the internet.
You can also use the Vagrant file to configure networking, and can specify what software you want the VM to have when you start it up.
You can more or less automate all the different pieces around creating a VM, and put all your configuration for it onto a Vagrant file. You then move through a series of commands to bring one or more VMs up and down.
There are lots of things you can do. For example, you can spin up three VMs to have a MongoDB replica set up and running within minutes — which is crazy, because it’s pretty hard to do without having a lot of infrastructure already in place. But you can do it in a matter of minutes with Vagrant, and that’s why it’s so powerful. In an agile software testing world it also help QA teams to test software faster.
You can also check-in a Vagrant file into a source control tool. Basically, you can treat your infrastructure just like code.
Vagrant Mini Desktop Cloud
Jeff Sussna describes Vagrant as giving you the ability to have a mini cloud on your desktop. It allows you to easily build and run local environments that are a really good match for production.
It means that everybody can be write testing code — even product managers doing user acceptance testing and prototype review — all on their desktops, all up front. There’s no waiting to get into some big test, acceptance, or production environments.
For example, if I’m the developer and I’m writing code and I’m the tester and I’m writing tests at the beginning of a sprint, we can be doing all of that on environments that are like each other and like production. In theory, this should solve the age-old “it works on my machine” issue we’re probably all familiar with.
So — Now that we’ve Covered Vagrant, what about Docker?
As I mentioned at the beginning of this article, Docker is not the same thing as Vagrant. Where Vagrant is about Virtual Machines, Docker is about containers.
A container in the Linux world — and the notion of a container in general – has been around for a long time now. Docker popularized containers, but it didn’t create containers; instead, it’s the means to create them.
What is a Container?
The best way to look at it is that a container is a process. When we run software on our computer, it runs in a process. That’s a boundary around that piece of software. When you have an executable that you want to execute, it gets loaded into memory. It has its own process associated with it. Whenever that process runs it is assigned a slice of the CPU and memory of the machine.
For example, each program you load (Microsoft Word, Chrome, etc.) has a process. Some may even have many processes that are executing on your machine. Those processes are not isolated from each other at all. Processes can also talk to each other and share each other’s resources.
It’s kind of like a small business. When a small business starts up, its employees share an office, and everyone gets access to everything they want. The employees are kind of like processes. Resources in an office would be things like phones and filing cabinets and printers. Those resources are all available to everybody. There’s no isolation.
When we talk about containers, all we’re talking about is adding some more isolation around a process. But back to our small business analogy. When you move from a small business into a big business teams and divisions are often created. You then have resources that are dedicated to each division. One division has its own office — its own filing cabinets, phone system, printers and other resources. With this setup employees between divisions generally can’t access resources outside of their own department.
That’s essentially what we’re talking about. We’re erecting boundaries around processes so that they can’t share things like a file systems or networking stacks anymore.
How Containers Help with Testing
Michael Sage has seen Docker used on teams that use micro-services, which are discreet business services. In some ways this is a rethinking of SOA. Let’s say we have an online bank and we have an account management service. We also have maybe a mortgage service. These are two separate services and they may be created by separate teams.
One benefit of micro services is that they lend themselves very well to continuous delivery. You have a single team working on a single stack that is focused exclusively on their code. When they have a problem with their account management service, they can fix that problem much more easily than with a monolithic app where there are dozens of services running in one big stack.
Docker affords us the flexibility to manage the continuous delivery process better because we’re focused on a known domain, a business logic and code. And that’s just one of the levels of isolation that Docker containers bring to the picture.
Using Vagrant and Docker
This was just a quick overview that has hopefully given you some ideas on how using Vagrant and Docker can help you with your DevOps and Agile software testing efforts.
Want to Learn More About Docker?
Check out Dima Kovalenko’s Automation Guild session on Using Docker in CI.
Sorry you missed the LIVE event. But due to demand I decided to keep registration open. So you can still get all pre-recorded sessions and recorded Q&A. These recording will be be available forever so register now to get access now.