Building a Virtual Appliance – Repeatably

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.

Read more on Building a Virtual Appliance – Repeatably…

Using Vagrant AWS with Capistrano

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.

Read more on Using Vagrant AWS with Capistrano…

Easier Capistrano Deploys from GitHub with ssh-agent

One great option for Capistrano deploys out of git is to use an ssh-agent. The agent will forward your own SSH keys from your development machine and make them available during deploys without ever needing to pollute your production servers with your keys. GitHub has a great getting-started document here.

Read more on Easier Capistrano Deploys from GitHub with ssh-agent…

Chef Solo with Capistrano

Not that long ago, I wrote about a standalone Puppet pattern that Mike English and I use in conjunction with Capistrano to provision and manage our server configurations.

While we still make use of Puppet, we’ve also added Chef to our repertoire. Similar to Puppet, Chef allows for a client/server model in which a Chef server stores and hosts a series of definitions, called recipes, which are packaged as cookbooks. While this works really well, it doesn’t always make sense for us to setup a full Chef Server — particularly if we’re just trying to manage a single server running within a customer’s existing ecosystem.

Fortunately, we can run Chef in a standalone mode referred to as Chef Solo. To facilitate the execution of Chef Solo and get the necessary Chef cookbooks and recipes in place, we utilize Capistrano. (It really is a magnificent utility, even if poorly documented.)

Read more on Chef Solo with Capistrano…

Deploying from Git with Capistrano

Justin and I provide operational support to the SME Toolkit project, an education portal for small to medium sized enterprises in developing countries sponsored by the IFC (which is the private sector development branch of the World Bank Group).

Recently, the source code for the Rails-based web application was migrated from Subversion to Git. This also changed how we deploy the application. Previously, we deployed a snapshot of code from a tarball placed on a bastion server. With a few changes to our Capistrano configuration, we are able to deploy directly from the source code repository. Read more on Deploying from Git with Capistrano…

Standalone Puppet with Capistrano

Mike English and I frequently make use of Puppet to provision servers and manage server configurations. It is very convenient to be able to setup a server (while simultaneously documenting its configuration) by writing Puppet modules and manifests and then simply running the Puppet agent. For larger setups, we have used the Puppet agent/master model (client/server), but for smaller setups (such as for a single server), this doesn’t make much sense — especially if it is a standalone server for a client running privately in the cloud.

However, it feels rather “un-Puppet-like” to SSH into a server directly, make Puppet manifest changes, and then run the Puppet agent in order to make configuration changes to a server; it is not very efficient.
Read more on Standalone Puppet with Capistrano…