It’s time to introduce another tool in the Data Guardian Toolbox.

Lightweight containers such as can be provided by Docker are all the rage these days.

But unless your production database runs on containers, you risk having a big discrepancy when testing certain tasks.

In this case it’s best to turn to an old favorite: Virtual Machines.

And to work with Virtual Machines on your local laptop, I highly recommend Vagrant.

Why work with Virtual Machines?

Before I get to Vagrant, let’s talk about why it’s important to work with Virtual Machines.

When a Data Guardian implements tasks like failover and restore testing, it’s best to start in a lab environment that closely mimics the setup of the production environment.

Running Production databases in containers is fairly new, and has a ton of complexities.

So it’s likely your production database environment runs on a Virtual Machine of some fashion.

To keep environment discrepancies to a minimum, you will want to work on a Virtual Machine as well.

If your lab environment is your laptop, Vagrant makes it really easy to configure a VM environment!

What is Vagrant

Vagrant is a configuration wrapper to define the state of one or more Virtual Machines.

Vagrant was my first dip into the paradigm of Infrastructure-as-Code. This paradigm basically means that you can describe a particular environment as a program.

It allows you define the state of the environment, such as how many servers and how big. It also allows you to configure what is installed on those servers.

When infrastructure is defined as code, you can store it in a git repository and track changes. You can also easily distribute it to your team mates. And it mostly behaves the same as it does on your machine!

Vagrant can roughly be divided into two components: Providers and Provisioners.

Providers are the types of infrastructure Vagrant can create. It has native support for VirtualBox, Hyper-V and VMware.

It can even support running Docker containers.

Provisioners are what Vagrant will run once the environment is up and ready. This is the meat of configuring each server or container.

For instance the Provisioners will handle installing MySQL and ProxySQL on your lab environment.

Vagrant supports many Provisioners from simple shell scripts to Ansible and Docker.

With that out of the way, let’s take a look at an example!

Vagrant example

Vagrant’s definition syntax is Ruby, so it’s easy to get started.

You define one or more Providers, telling Vagrant how to handle CPU, Memory and Filesystem space, as well as any Networking.

You can also define how to handle local files getting on the VM.

Finally, you specify what the provisioners will do once the environment is ready.

Once you have that, you run vagrant up and wait for the Provider to create the servers and the provisioning to complete.

Then you run vagrant ssh to log into the server and everything is ready to go!

If you need to modify the configuration state of the servers, simply run vagrant provision.

And to turn it all off, run vagrant halt.

Why not just use Docker?

The time it takes Vagrant to set up the virtual machines will be longer than provisioning Docker containers.

Even if the environment was previously configured, bootup times will be longer.

But Docker environments are difficult to manage multiple processes.

For instance, shutting down MySQL to take a cold backup of the data directory would cause the container to stop completely.

So use a VM when you want to manipulate multiple processes, or otherwise mimic your production database environment.

Conclusion

Vagrant makes working with Virtual Machines extremely easy.

And for that reason, Vagrant has a strong place in the Data Guardian Toolbox!

I’d love for you to leave a comment to let me know your experience with Vagrant.