My Vagrant Setup

I’ve seen and heard how Vagrant is powerful tool for development environments. Vagrant is a tool from Hashicorp for managing virtual environments. I’ve had it installed for a while, but never really dug in far enough to understand the value. Well, like most things, I didn’t understand the value because I didn’t have a particular use case. Well now I do…

I was having issues running multiple VMs on my MacBook Pro via Fusion. Namely, that if I want to run a CSR router, I don’t have the horsepower to also run other VMs at the same time. A coworker of mine had mentioned on an internal forum that he recommended using Vagrant for testing Ansible. I am just scratching the surface I believe, but this did solve my particular problem. I can spin up a VM using Vagrant to test my Ansible playbooks against the aforementioned CSR–all on my laptop.

I won’t cover the basic installation of Vagrant itself, but that information is available at the Vagrant website, as well as much more documentation:

OK. So here is where I start customizing. When you install Vagrant, a file named vagrantfile gets installed and contains all the information about your vagrant environment.

If you want to customize the different ansible machines you can spin up, copy the vagrant file into different directory per project.

For mine, I copied the vagrantfile into /vagrant-ansible-example/.

I can now edit the vagrantfile to customize this instance.

I can set which OS to spin up. = "ubuntu/trusty64"

I can create a synced folder. I can have my Ansible files, or python files on my desktop and mount that directory from within the vagrant machine. This is useful to have access to playbooks or scripts that I am editing that I want to run from within a VM.

config.vm.synced_folder "/Users/bob/Documents/Github", "/Github"

I can then customize my vagrant machine by calling a bash startup script to install ansible, pip, and xlrd. (These are just examples, could be any packages you need to install.)

  config.vm.provision "shell" do |s|
    s.path = "./"

Here is a snippet of what my setup script looks like.

<br />#!/bin/bash

echo "setting up environment"
echo "installing ansible"
sudo apt-get install ansible -y
echo "installing pip"
sudo apt-get install python-pip -y
echo "installing xlrd"
sudo pip install xlrd

We spin up or machine from within the Vagrant-ansible-example directory.

vagrant up

It boots up our OS and runs our startup script, then we can ssh to our machine and start testing.

The nice thing about Vagrant, I have found, is I can easily reset my machine back to this first known-good state, or change my startup parameters and spin up a new VM anytime.

I can do this by issuing a vagrant destroy command, which will wipe out any state configuration on my VM. Then I just issue vagrant up again and it spins up my VM like it was a brand new install.


DevOps is People (Or it’s not)

Google what is devops and you’ll be deluged by a lot of definitions that loosely land on some sort of collaboration between development groups and IT operations groups. These definitions rarely delve into what exactly those groups definitions are. Because it is all nebulous. I have taken an interest in this little slice of the IT industry and I had the chance to attend the recent devopsdays MSP here in Minneapolis.

As an old infrastructure guy, I definitely felt out of my element around this crew. I don’t have a dev background, I have done sysadmin work (ops), and only recently have I gotten back into some “dev” work around infrastructure automation. I put that dev in quotes because what I am doing is nothing like real application development, but I am familiarizing myself with the languages and tools used in their world, I just don’t live in that world every day. My main focus over the past 15 years has been around network engineering.

It really clicked for me at this conference that this devops scene is not really about tools, but processes. It’s about people in the sense that people make up a community and that community defines a culture. This community is in IT shops within organizations. A broader community of support and education is evolving around this culture. This conference was part of it.

There were many excellent talks, and as I said, not necessarily about tools, but about the culture of devops. The two that stood out to me were from Brian Liles and Pete Cheslock.

Brian gave a good overview of the state of “devops” for whatever that term means to anybody. One of the themes that he touched on was human element of working in IT. The concept of empathy as a tool is a realization that the longer you work in IT, the more closely you associate with success. Especially as a consultant like me, you need to attempt to understand the circumstances that the person sitting across the desk from you is coming from. Many of the speakers and conversations in the open group sessions kept coming back to empathy. I think this underlines what was most impressed upon me by this conference–people. The devops movement is about people. The community. Teams. The tools are almost secondary, it really is about culture.

Brian stressed “diversity of thought” in the enterprise as a valuable tool. He did give a list of high-level areas that any one working anywhere near the devops space should be familiar with.

  1. Linux – “scripting isn’t necessarily automation.” Automation is “throw this thing over there and it just works, it complains when it doesn’t”
  2. Know networking
  3. Know how sys services works – Systemd, docker
  4. Know tools of space
  5. Most important piece is empathy. Live through how your customer is seeing it…
  6. Continuous integration
  7. Monitoring (point in time and long-term trends) – alerts only go out when they are actionable (reduce noise)
  8. Logging

The second speaker that stood out to me was Pete Cheslock. Mostly because it was a very compelling story that he told. Even as a non-dev, I could relate with projects gone sideways due to changing requirements and unclear direction. Definitely worth your time.


I look forward to my continued immersion into this world. This event was a good way to jumpstart that journey.