This post is a loose introduction to Vagrant using my own workflow as an example. It is intended as a high level read for anyone who has heard of Vagrant and needs to figure out where and how it fits in the world of developing software.
Who is Vagrant?
Actually the right question is "What" is Vagrant.
It's a software tool. And for those who've never heard of this tool, Vagrant is an open source tool that lets you easily create and manage virtual environments. It's natural to initially confuse it as a replacement for virtual machine apps like Virtualbox, VMWare etc. I am assuming here that you know what a virtual machine (VM) is.
In reality, it sits on top of these very tools (and others) to coordinate the producing what it calls as "reproducible environments".
In reality, it sits on top of these very tools (and others) to coordinate the producing what it calls as "reproducible environments".
Where does it fit in to my work?
That's the main point of this post.
Say, you are a developer who writes code on a Windows PC/ laptop or a Mac. And your code is expected to end up being deployed on a Linux machine. How many times have you experienced a "Oh! But works on my machine!" moment? Is it really that unexpected given that you have to imagine how your code would behave in a production environment?
Say, you are a developer who writes code on a Windows PC/ laptop or a Mac. And your code is expected to end up being deployed on a Linux machine. How many times have you experienced a "Oh! But works on my machine!" moment? Is it really that unexpected given that you have to imagine how your code would behave in a production environment?
In the recent past developers (and testers, etc) have taken to using virtual machines to try and solve this problem. They create a near production environment to test both the running and the deployment of your code. This has it's own challenges.
- The time and effort has to be spent setting up these VMs.
- This has to be done every time some one joins the team.
- And also when you've just made a mistake and have had to trash the VM you were using.
- Keeping up with changes to your production environment
Vagrant is one of the tools designed to solve this particular vein of problems.
For starters, It provides a command line interface for managing the life cycle of a VM. This means you can write scripts to automate repeat tasks.
It comes with it's own collection of ready-made combinations (E.g. a pre-configured Puppet box running Ubuntu - provided by the puppet team or a basic Ubuntu box running the latest OS version). This provides a starting point that is far ahead of where I would have normally begun - finding an ISO of Ubuntu. And this happens at the steep cost of a two command lines. That alone will save you an hour or two.
It works with popular softwares like Chef, Puppet, Docker and more. Which means if you have existing scripts, they can be hooked straight in to the VM creation process.
And given that the configuration of your VM is in a file, it can be version controlled - and changed using scripts.
For starters, It provides a command line interface for managing the life cycle of a VM. This means you can write scripts to automate repeat tasks.
It comes with it's own collection of ready-made combinations (E.g. a pre-configured Puppet box running Ubuntu - provided by the puppet team or a basic Ubuntu box running the latest OS version). This provides a starting point that is far ahead of where I would have normally begun - finding an ISO of Ubuntu. And this happens at the steep cost of a two command lines. That alone will save you an hour or two.
It works with popular softwares like Chef, Puppet, Docker and more. Which means if you have existing scripts, they can be hooked straight in to the VM creation process.
And given that the configuration of your VM is in a file, it can be version controlled - and changed using scripts.
Beginning - The Set up
The tool set up is fairly straight forward process.
- Download and install a supported virtualization software. Or check here to see if the one you already have is supported. I use and would recommend Virtualbox on Windows - it's free.
- Download and install Vagrant (duh!)
- Look through the getting started guide to get acquainted with the tool.
- Learn about and install vagrant plugins. My recommended ones are
- vagrant-vbguest - to keep your VirtualBox guest additions up to date
- vagrant-proxyconf - if you are behind a corporate network and need to use a proxy
- vagrant-multi-putty - to make using Putty a breeze with vagrant.
- Bookmark the documentation link. Unsurprisingly, it will be initially needed - a lot.
The First Time I Need A New Environment
- md c:\project\folder
- cd c:\project\folder
- vagrant init puphpet/centos65-x64
- [View/ edit your box settings file - Vagrantfile].
- vagrant up
- [Convert your private keys to Putty compatible format]
- Connect to your shiny new box via SSH. I use Putty, which is why the previous step is necessary.
- vagrant halt
We start by creating creating a home for your "project".
Line 3 defines that the "base template" (the image that my VM will be based on) will be puphpet/centos65-x64 (i.e. Centos 6.5 64-bit). This is one of the many that can be viewed here (another link for bookmarking).
Line 3 defines that the "base template" (the image that my VM will be based on) will be puphpet/centos65-x64 (i.e. Centos 6.5 64-bit). This is one of the many that can be viewed here (another link for bookmarking).
Line 4 is looking at and editing the configuration of your to-be environment as necessary. A script would download a copy for the version control software.
Line 5 is the interesting part - booting up. This step is where vagrant is as its busiest. It reads the configuration file, downs the necessary software and executes the configuration like networks, shares port forwards, etc. Once done, you should end up with a brand new virtual environment and a private keys for use with SSH.
Line 5 is the interesting part - booting up. This step is where vagrant is as its busiest. It reads the configuration file, downs the necessary software and executes the configuration like networks, shares port forwards, etc. Once done, you should end up with a brand new virtual environment and a private keys for use with SSH.
Line 6 is a windows-specific step for converting the auto-created vagrant private keys so they can be used with Putty. Again a script can pull this from version control or perform the conversion.
Step 7 is (finally!) connecting to your new environment using Putty. And then have a look around, so some stuff. My usual first step is to run an update (sudo yum update) - though this can be set up to happen as part of the new machine creation.
Step 7 is (finally!) connecting to your new environment using Putty. And then have a look around, so some stuff. My usual first step is to run an update (sudo yum update) - though this can be set up to happen as part of the new machine creation.
When executing the above steps manually - at the first time. I usually finish with a "vagrant package" to create a local snapshot. My scripted version simply creates copies of this snapshot and we save vagrant time downloading the stuff.
And finally when you are ready, shut down your new environment with step 8.
And finally when you are ready, shut down your new environment with step 8.
That's it! The hard work is done.
When I Need A Fresh Copy (for Me or A New Team Member)
This is simply done by
- Download and install Vagrant and Virtualbox
- Run my script
The new machine is ready in under 15 minutes. How's that for speed?
Pros and Cons
- Pro - Save time and effort. The command line interface makes it possible to write a re-usable batch file.
- Pro - More production-like. The Provisioning feature makes it possible to run (and test) production deploy scripts locally.
- Pro - Reduced risk. Ability to run prod deploy scripts locally is an added guarantee that what I do won't break deploy. Plus, I can repair my mistakes in seconds.
- Pro - Infrastructure as Code! The settings file has settings for everything from RAM, Network to certificates. It can be easily controlled by provisioner like Salt, Ansible, Docker etc.
- Pro - 2nd/3rd Line support is now easily since you can re-create problems a lot better on your local box.
- Con - Easy to get carried away and forget I don't have infinite disk space and RAM :)
Conclusion
Investing a couple of hours getting to Vagrant has significantly speeded up my ability to spin up environments. I have come to realize that this ability is just the start. From a developers perspective, it helps narrow the gap between his environment and production. Isn't that what DevOps is all about - an overlap between the development and operations function?
Watch this space for more specific articles on the topic.