DevOps

Vagrant:tips and tricks and why you should use it

Virtualbox is awesome. It’s awesome because you can experiment with dummy machines, and clear them once you are done. It’s awesome because it’s cloud neutral – there is no need to select a vendor, and it’s great because you don’t need to pay for usage. You can configure networks if needed, and have multiple machines. The caveat – it’s limited by your hardware. if you are running a 8 or even 16 GB machine, this will probably not work.

What about Docker?

Well Docker is another awesome thing. However, this is not a full system; Docker is fantastic for software deployment, not for system testing. If I want to test a full system, I’ll opt for Virtualbox. Then, a decision can be made on how to distribute a working solution. If you have a flask, node or C# application, then yes, Docker is probably the right way; if you want to test interaction of multiple technologies, including setting them up (more of a devops thing and less of a programming thing) Virtualbox is your solution. BTW: Docker and docker compose are great tools to create a stack without using Kubernetes; But it won’t help you setting up the internal of a system.

The annoying parts about Virtualbox

While it’s pretty awesome, configuring it to work is time consuming. It’s not difficult, it’s just annoying. Setting up a machine, setting up network, and the waiting.. then running the updates, and if you need more than one machine… You’ll have to repeat it.

Vagrant to the rescue

So instead of waiting, you can just write a ruby script (it’s called Vagrantfile, but it’s ruby) that will take care of everything for you. setup memory? No problem! Allocate CPU? sure! Run initialization scripts? You got it! No need to wait and interact. And if you want to do something more complicated, you can always run ansible scripts once your machine is set up.

A sample Vagrantfile with all the trimmings

While this is a simple file, it contains most of the often used options:
we start by telling vagrant that we don’t want to use different keys – this will help up in the future. Then, we’re setting the machine type, in this case, Ubuntu 20. What happens after that is something that is documented less: we’re setting the memory and cpu usage. As far as grouping goes, it’s not always working. Then, we set up multiple machines, installing python and updating them. And guess what – you don’t need to be there when it’s all taking place!
To start (and create): vagrant up.
To stop vagrant halt.
To terminate: vagrant destroy. Note that once created, you shouldn’t change the file, it might prevent you from executing certain vagrant commands.

This sample file can be your base file, and you can setup DB clusters, Kubernetes clusters and anything you can think of.

Why you should limit your Vagrant scripts:

  1. Vagrant scripts are bash scripts. They are more limited and harder to test than others.
  2. It’s a fair assumption that your test configuration will be in the cloud later on. Meaning? you’ll need a better tool, e.g Ansible to configure the instances. While Ansible it a great tool it does require python (hence the python installation). But since we’re referring to vagrant as bare metal setup, you shouldn’t go overboard with it.

Don’t forget to update:

vagrant box update
Code language: Bash (bash)

Leave a Reply

Your email address will not be published. Required fields are marked *