Unifying the Development Process via Vagrant and Puppet – Part 1
“Write once, run anywhere” – Sun Microsystems
In reality, Sun’s high expectations for its Java language usually equates to “Write once, run mostly anywhere,” or “Write once, run nowhere.” Application development is a complicated beast, filled with many moving parts that must all behave in unison in order for your program or website to work smoothly. However, smoothly does not always equate to identically (more on this later).
This post will discuss how to write code once, and through the process of creating standardized environments, have that code run smoothly. Most importantly, that code will run identically throughout your infrastructure.
For businesses, this type of coding brings the following advantages:
· Decreased server setup times
· Ability to quickly onboard additional resources
· More reliable code
· More consistent testing
· Standardized deployment processes
· Team members stick with core compencies
· Saving $$$
In a large-scale project, a team of developers with disparate skills is usually brought together to solve various pieces of the project. Step one in this process is usually the setup of his/her environment on a desktop or laptop (or in some cases on both). Setting up an environment can take from several hours to several days depending on the complexity of the required setup. For the primary architect/lead developer, this is a routine process. But what about the front end developer, the DBA, or any additional resource? Imagine being handed a diagram of a simple LAMP stack and asked to replicate it as depicted in Figure 1. Now add in things like memcache, solr, apc, etc. Is your head spinning yet?
At best, your additional team members have the talent to create their own environments. At worse, this could mean hours or even days of Googling, asking questions, breaking things, etc. Why waste the time and risk error? Meet Vagrant, a virtual development environment based on Oracle’s VirtualBox technology.
The issue of software version discrepancies, platform/server differences, configuration mismatches, and assorted other pains are now a thing of the past.
Figure 1: Example LAMP Stack
Vagrant’s claim is that it “… makes the ‘works on my machine’ excuse a relic of the past.”
Vagrant provides a consistent and portable environment to the team. Best of all, it’s free and it’s fast.
In a nutshell, all you need to do to set it up are to take the following steps:
- Install VirtualBox (one time)
- Install Vagrant (one time)
- Run 3 simple commands
o vagrant box add [YOUR_PERSONALIZED_BOX]
o vagrant init
o vagrant up
And presto! An instant copy of your standardized server is set up. No mess, no fuss. Now, the new developer that you’ve brought in to fix a few minor HTML bugs simply does what he/she does best.
So we’ve talked about Vagrant, but how does Puppet fit into the whole picture? Puppet , from Puppet Labs, handles the server provisioning side of things. This is simply tech jargon for configuring the server. Puppet tells your Vagrant environment what software packages it needs along with configuration and version information. To the seasoned Vagrant user, this is invisible and all part of the magic.
For more on the technical details of how to configure Puppet and create your own Vagrant boxes, stay tuned for the Part 2 of the this post which will discuss the ins/outs of Vagrant and Puppet and provide an example build for a project.
It will also cover deploying the application to its final home, whether it is on a company server or a cloud instance like EC2 or Rackspace.