As a general rule, I try to minimize the number of programs installed and configured on the host OS of my laptop. I use the host mostly for email, office, and web browsing. It’s much faster to create isolated development environments inside of virtual machines. If a project requires some third-party applications or modifying system-wide settings, I don’t need to worry about it corrupting my host OS or affecting other projects.
As a software consultancy, we often perform additional or maintenance development on a previous project. It’s great to be able to maintain positive customer relationships and provide good value to them, but I admit I often dread returning to an old project. The main reason for my fear and trembling is trying to get the development environment up and running again. In the interim since the last time I (or someone else) touched the project, any number of things can go wrong. Just recently I encountered the following nightmare dependency change:
One of the traditional problems in software development is the delivery of a finished project. Atomic Object writes custom software, but we ultimately need to deliver it to our customers, which usually implies deploying it to an existing infrastructure environment, or handing it off to an operations team.
Unfortunately, this hand-off process often introduces a variety of glitches and bugs due to differences between the environment that the software was developed in (the development environment), and the environment it will actually run in (the production environment).
Vagrant is a tool for creating and configuring virtual machines. It provides an interface to easily bootstrap and manage virtual machines using a variety of different virtualization platforms and configuration management tools, both open source and commercial. By using Vagrant, developers can easily write and test applications in environments similar to which they will actually be deployed. This reduces the likelihood of glitches and bugs when handing off a finished project to customers. Read more on Why Vagrant? – Preventing Deployment Issues from Day One with a Virtual Machine…
Often, I want to develop a Chef configuration that can be applied to a whole cluster of systems. During development, I may not have access to the final virtual (or physical) machines that will make up the cluster. To resolve this problem, I construct a Vagrant cluster that allows me to develop locally.
Instead of using a single Vagrant, the Vagrant cluster contains at least one Vagrant for each role I am developing for. I tweak my Vagrantfile so that it will construct the cluster based on the contents of the standard JSON files used to define Chef nodes. This integrates everything nicely into the Chef server environment and allows me to easily work with a representation of the final production systems. Read more on Constructing a Vagrant Cluster for Chef Development…
We were recently faced with the problem of how to ship and support a complicated piece of server software. We needed the software to be installed on a customer’s existing infrastructure and were nervous about depending on them to have experts in house.
We decided to build a virtual machine “appliance” style packaging and to ship a fully-configured Linux installation. This greatly simplified the process of installing at a customer’s site, but building such an appliance repeatably is not trivial.
Vagrant 1.1 was recently released, adding support for virtualization providers other than VirtualBox. Among the providers now available is one for AWS. In switching my Vagrant workflow from VirtualBox to AWS, I ran into a problem; and in solving it, I discovered a better way to integrate Vagrant with Capistrano.
1. Vagrant Setup
Vagrant 1.1 was released recently. This release adds support for provider plugins, including a new, freely available provider for AWS. Rather than using VirtualBox on your local machine as the virtualization provider, you can now provision Vagrant-managed VMs in the cloud. This makes it much easier to try out things that require more resources like multi-VM environments and VMs requiring lots of RAM.
Teaching a workshop involves a lot of thought and preparation. There’s research to do, content prep, slides to tweak — and you have to figure out some way of getting all the attendees started with the same setup. If you’re lucky, you’ll be presenting in a lab with machines that can be set up ahead of time. Puppet, Vagrant, and VirtualBox are fantastic tools to help you get your workshop setup. Using them saved me time and kept me from having to deal with issues on the day of the workshop.
I recently did an “Intro to Rails” workshop at Hope College. Their lab was set up with powerful laptops that were already equipped with VirtualBox. I just needed to provide them with an image to use. If your attendees are bringing their own equipment, think about having them install VirtualBox ahead of time.
After my impromptu presentation about configuration management with Puppet at BarCampGR a few weeks ago, several people mentioned that they had tried to use Puppet before, but couldn’t figure out how to make it do anything in the first place.