Building a Lab with VirtualBox and HashiCorp Vagrant
Building a software prototyping environment (aka lab) is far simpler than ever before. No longer do you have to wait to build a physical machine, then wait to download ISO images of the virtualization stuff, operating systems, software packages etc. Simply use Vagrant and VirtualBox together, and you can have a highly functional lab for software development up lickety-split with some added agility for prototyping infrastructure choices too.
What You Get with the Combination of Vagrant and VirtualBox
VirtualBox: This is an open source (GPL v2) virtualization platform that works on almost any base OS. Your virtual machines will be hosted in this on top of your base OS, sharing its resources. For advanced users, it also has some command line, advanced networking capabilities, and integrates nicely with Vagrant. Vagrant: This is a great time-saving open source (MIT) tool from our friends at HashiCorp. It allows for some fundamental integration and automation with platforms like VirtualBox, Microsoft Hyper-V, VMware, etc. In summary, this is a time-saving tool for standing up VMs faster, configuring them, adding packages to VMs, or integrating your virtual platforms with tools like Ansible. This blog post will show you how to get this combination up and running to take the next steps with development, infrastructure automation efforts, etc.
Prerequisites to Build This System
Note: There are a lot of platforms and starting points for this combination of features and software. For the instructions here, I am using a simple Windows 10 machine and the software available today.
• Windows 10/x64 OS • Hyper-V Disabled (it makes some system changes that break VirtualBox in most cases) • 16GB RAM (you won’t be able to do much if you have less than this) • Modern multi-core Intel/AMD CPU (4+ cores @2GHz+ is best) • Internet connection (fun! you get to download a few things) • Basic Powershell understanding (you need to know what it is and how to open it) • Understanding of how to install software on a Windows OS
Build Your Lab, Step-by-Step
1. Grab the bits.
2. Install the software.
This is pretty simple. Nothing special here.
3. Set up a prerequisite directory structure.
Once you have the two packages and any special dependencies installed, (estimated 10 minutes start to finish), you get to have some fun! (I ❤ Open Source Software) See Special Note #2 at the bottom for special settings for Powershell as needed.a. Open up Powershell: Being about speed, I typically hit the Windows key and start typing power… see the little blue icon highlighted then hit Enter.
b. Confirm that things look right: If things installed nicely, you should see the highlighted “dot files” in your HOME directory.
c. Make a directory for your first experiment: I choose vagrant_test as my directory name:
d. Change to that directory:
4. Git ‘er dun.
a. Run the vagrant init command This example initializes for a generic CentOS7 image from the community-curated generic repo.
b. Check that things look right: You should see a new VagrantFile from the init command.
c. Make sure VirtualBox is alive I have another machine visible in the left pane in the screenshot but ignore that.
d. Try to “up” the vagrant box This makes a new VM from the VagrantFile and definitions we just “initialized” with that init command
e. Watch it do some magic:Note: The unique hostname it creates based on the directory we are in (vagrant_test). This command run is the longest part of the process since vagrant is grabbing the image defined (from the internet), building a new VM and getting things all running—but—it is super-fast compared to a normal manual install + setup.
f. Look at the VirtualBox console! Goodness, that sure is speedy and simple! Note: The matching Vagrant VM Name from the previous step. It will create a unique name for each virtual machine you spin up with the VagrantFile.
5. Make sure it all is working for real.
a. Connect to your new VM with vagrant ssh This takes just a moment. Note: This uses the VagrantFile and other items in the directory where you have been doing everything (vagrant_test) to make this happen, so you don’t have to manually deal with SSH keys and external network connections like with Putty, etc.
b. Confirm VM networking is working There are a lot of ways to do this, but I like to run “sudo yum update” to make sure I am current on CentOS box anyway.
6. Complete my favorite step.
I love the final part of this from a command set. After all, the guys at HashiCorp were fun enough to use the word “destroy.” However, keeping the environment clean is important since my laptop equipment is pretty resource constrained in terms of CPU/RAM and storage capacity. So, when you are done experimenting with your VM, “vagrant destroy” makes it super easy to clean up quickly. This deletion process removes the VM and its storage/data but does not delete the VagrantFile that is used to spin up a new machine super-fast (with no data). a. Destroy your VM! Exit your Vagrant VM if you haven’t already, then . . . Note: I execute this command from the same directory where I performed “vagrant up” earlier. The command warns you just in case but know this is going to blow up the VM and all of its data!
7. Save time and do more.
This is just the beginning of using this combination of technologies. The combination of Vagrant and VirtualBox should save you lots of time. Spinning up this CentOS box with Vagrant takes only a couple of minutes because of the automation and other human task elimination. This automated process compares favorably to a typical manual process: 5+ minutes best case to download, 10-15 minutes to install, more time to customize the OS for basic usage (SSH keys, etc.). I expect I save at least 20 minutes per iteration of spinning up Linux machines in VMs on my laptop with this tooling versus manual methods. This can equate to hours of productivity gains per day if you do a lot of prototyping like me. Obviously, this type of automation is a big deal in the world of DevOps also. This gets even more impressive when you layer in fancy stuff like Ansible and Kubernetes. Go fast!
We’re Here If You Need Us
OpenLogic provides everything you need to build and manage your open source solutions, including an open source support team, available 24×7, to assist you with this updates, implementations, and migrations like this! Contact us and learn more. ************************************************************************************************
Note #1: I chose the VirtualBox platform intentionally. All of this is possible with Hyper-V and others as the virtualization platform on a Windows-based OS. However, you will have to make some configuration changes to Vagrant to make other hypervisors the default (instead of VirtualBox with Vagrant), or you will need to modify each of the VagrantFile(s), or you will have to add some flags to the command line for each vagrant task. In addition, Hyper-V (one of the other simple, free options for this component) has a requirement to run the Powershell at an elevated privilege level and this becomes another reason that VirtualBox is a little easier and preferred in my book for this prototyping use case. VirtualBox can run Powershell at a user’s basic level of privilege. Finally, when you start using a lot of the community-curated boxes from the vagrant community, there appear to be many more that “just work” with VirtualBox. I haven’t confirmed this last detail, but in a nutshell, I chose VirtualBox over Hyper-V, etc. for this use-case for the following reasons: simplicity, choice, and straightforward usage. Note #2: For those of us that love the command line, Windows Powershell is a bit of a mixed bag. Color choices, ANSI compliance, and other items are not in the strength’s category of this CLI option, but—using Powershell with this Vagrant + VirtualBox combination opens up the simplest path to “vagrant ssh”. Yeah, Cygwin, other options abound, however, this is the single simplest way to move between your Windows machine and Linux VMs you make with Vagrant. I love to save time, so not having to deal with SSH keys and other details when building machines is a great thing when you use this built-in shell. All of that said, there are some things that you should do with Powershell defaults to avoid the pitfalls in my lesson’s learned: 1. Change the default colors. If you don’t do this, then the default blue background of Powershell makes reading the default ANSI colors when you “vagrant ssh” and then “vim” or “vi” files on your Linux VM nearly impossible. I suggest a light grey background and dark text to make life easier. Here is a screenshot of Powershell Properties>Colors that work for me:
2. Make sure you uncheck the “Use legacy console.” If you don’t then the ANSI text for most Linux SSH sessions will get garbled and you are going to want to chuck your system across the room when you use “vagrant ssh”. Here is a screenshot of Powershell Properties>Options that work for me: