I need a VM and I need it asap.
Vagrant is designed to be the quickest way to a running VM, and I’m impressed. I have VirtualBox running on my trusty Dell XPS 13 laptop; “Sputnik” (named after the collaboration between Ubuntu and Dell).
Installing Virtualbox and Vagrant on Linux Mint (or any Debian/Ubuntu derivative) is as easy as typing…
sudo apt-get install virtualbox vagrant
vagrant init centos/7 or vagrant init debian/jessie64
or vagrant init hashicorp/precise64 the latter hashicorp Ubuntu LTS build being the one that Vagrant’s own documentation is based upon. For my example here, I’m going to start with a RHEL based Centos 7 offering..
This creates a text file called Vagrantfile in the current directory.
Rather than have this file in the root of my home directory, I’ve relocated it to a subdirectory ~/Vagrant/Centos7. This will allow me to have other Vagrantfiles for other types of VM all stored under ~/Vagrant in their own subdirectory. Probably not a bad idea as I’ll likely want to spin up a few different VM’s over time.
I’m now ready to “up” my VM…
Since I don’t already have a copy of the image downloaded, it goes off to sort all that for you. While it’s doing that, there’s nothing stopping me from spinning up an Ubuntu Precise64 VM in another terminal window…
Since I already had the hashicorp/precise64 “Box” image from a previous deployment, it procured this VM in seconds while it continued to download the Centos Box image in the other terminal.
In my other terminal window, Centos 7 has now also been procured, along with some helpful tips should any issues arise around non-installation of VirtualBox Guest Additions on my host (In my case, I’m running VirtualBox version 5.1.34 at the time of writing).
Flick across to VirtualBox Manager and you can see the two new running VMs based on the downloaded Boxes have been added to the Inventory. Note: Do not rename them.
To connect to them, simply use the command…
Both VM’s allow you to log on instantly over SSH with just this minimalist command run from within the directory containing the Vagrantfile.
So there you have it, a Centos VM and a Ubuntu VM up and running in seconds. Not hours. Not Days. Not Weeks.
It is that simple. From Zero to Virtualbox, Vagrant and logged on to a running VM of your choice in three commands and dare I say it, about three seconds.
To shut them down, or bring them online again, use the following commands, just make sure you run them from within the correct subdirectory or you could shut the wrong VM down…
It’s worth checking out the Vagrantfile and the documentation online as you can copy and re-use the Vagrantfile and make useful modifications to it. Here are some more vagrant box commands to explore.
You can see here that although the vagrant box list command shows all boxes/images downloaded on your host system, if you execute vagrant box outdated, it’ll only check for updated box images for the box image specified in your local Vagrantfile, not all Boxes on the host system at once.
Note that this is not the same thing as performing sudo apt-get update && sudo apt-get dist-upgrade (or redhat equivalent yum update command) on the VM built using the Box image (shown below).
As with any new VM or Server, you will probably want to bring all packages up to date using the VM’s own OS package management system.
Vagrant Boxes and Shared Folders
As already established, Vagrant images for VMWare or VirtualBox can be downloaded from the internet using the vagrant command line or as a quick google search will reveal, from here.
The image files (boxes) are stored in .vagrant.d/boxes
Once an image has been downloaded, a “box” has been “created”. This doesn’t mean a server (VM) has been created. It just means that your local installation of vagrant has a box, ready to be deployed as a VM.
Before this can be done, it is prudent to create a “Project” for your VM, to put a structure in place to allow for some separation, given that you’re likely to want more than one VM. This is very easy to do. Just create some folder e.g. vagrant-project1 in your home directory, or anything you like.
cd into that directory and initialise a new project,
This will create a file called Vagrantfile in your project folder. Edit this file to read as follows…
Vagrant.configure(“2”) do |config|
config.vm.box = “hashicorp/precise64”
config.vm.box_version = “1.1.0”
config.vm.box_url = “https://vagrantcloud.com/hashicorp/precise64”
You don’t have to put all three lines in it, just the first one will do, but why not while you’re in there?
You are not at a point where you have a project, you have a box and you’ve configured your new project to use that box. Now you can bring up a VM in Virtualbox by running the following command from inside your Project folder,
You can log in with no password, by typing
Then create your first user and add him/her to the sudoers file, just as you would with any linux server,
adduser matt && adduser matt sudo
or adduser matt && usermod -aG sudo matt
whatever’s your way of doing it, it doesn’t matter.
You can edit files on your VM locally, you don’t need to ssh to the server in order to access files on it. Vagrant has mounted your Project folder from inside the VM, so if you’re on the VM and you cd into /vagrant, you’ll be in the same folder as if you’re on your host machine and you cd into ~/vagrant-project1. Really cool!
Vagrant can also be configured to automatically provision. For example, the Vagrantfile can be edited as follows to automatically execute a script – in this case, the script installs Apache if it is not already present.
The bootstrap.sh script referenced in the Vagrantfile above, looks as follows.
Since it was created in my project folder, it is automatically also on the VM since that folder is automatically mounted as mentioned previously.
To effect the changes, you can vagrant reload –provision a running VM to quickly restart it, or if you’ve not yet started the VM, vagrant up will automatically do it.
You can see the VM getting restarted by Vagrant (white text shown above) and Apache getting installed (green text) in the console.
The Apache webserver will not be available from your local web browser, but it can be tested on the VM command line with wget -q0- 127.0.0.1
We can forward the webserver port 80 to our local machine on say, port 4567 and test the webserver accordingly using our own web browser.
We can see that due to the tunnel we’ve created from the VM, by browsing local port 4567, we’re seeing what’s being served on port 80 on our VM.