CoverMyMeds sat in an odd technology intersection when I started here. We were a Red Hat Enterprise Linux customer, greatly valuing the long life of the platform. But we were also a web development shop writing applications primarily in Ruby, a language that evolves quickly. Red Hat Enterprise Linux 6, released at the end of 2010, shipped with Ruby 1.8.
In order to enjoy newer Ruby versions on our RHEL 6 servers, we had been using RVM, the Ruby Version Manager. RVM is a fine solution for managing multiple versions of Ruby. However, I had two major complaints against it on our production servers. First, we had very little need for multiple versions of Ruby on our production servers. Second, RVM compiles the target Ruby version(s) from source, which requires a full build environment on our production servers. Having a full build environment wasn’t really that bad (and, indeed, some Gems required it anyway to build native extensions). But the repeated process of building the same version of Ruby on every new server was time consuming and wasteful.
Enter Red Hat Software Collections!
As previously mentioned, we’re pretty gung-ho about Software Collections. We appreciate the long life of Red Hat Enterprise Linux, but having access to more current releases of our primary languages is a real benefit. Consuming Ruby from Software Collections means that we can install from binary RPMs, easily obtain and install patches from Red Hat, audit our installations with Red Hat Satellite, and benefit from the expertise of the Red Hat security team for reviewing and resolving security flaws with the packages.
Prior to Software Collections, we’d been using the maestrodev rvm Puppet module to install Ruby (via RVM) and various gems. This module worked extremely well for us. So while we were eager to start using Software Collections for Ruby, we had to develop new automation to support it.
Today, I’m happy to share that automation with the world: the CoverMyMeds puppet-ruby module!
Our transition from RVM to Software Collections was pretty straightforward. Thanks to the ease with which we can build new servers, it was actually quite easy for us to provision new servers running SCL Ruby, deploy code, and update our load balancer configurations. We had zero downtime for any of our applications during the transition. And we upgraded from Ruby 1.9.3 to Ruby 2.0.0 in the process!