How To: Execute in a Bundler context

I’m writing a small* sinatra-based tool for running tedious command line tools in a nicer environment, and I came across this problem. I wanted to be able to run a tool, say RSpec, in the context of a particular Gemfile. This is the same behaviour as the `bundle exec rspec` command. I’ve spent the last couple of nights figuring it out, and I finally got it going with a little help from StackOverflow, so I thought I’d share it here.

To run a piece of code in a Bundler context, you first need to load up Bundler and the Bundler CLI:

require 'bundler/setup'
require 'bundler/cli'

You then need to set a special environment variable that Bundler reads when performing any actions. This is what gives Bundler its context:

ENV['BUNDLE_GEMFILE'] = "/path/to/Gemfile"

Once this is set, we’re in that particular Gemfile’s context. We can now execute code using that Gemfile’s gems, or we can run the internal Bundler exec method to execute a command:

Bundler::CLI.new.exec('rspec')

This will do the same thing as if we were on the command line, in the Gemfile’s directory, using the “bundle exec” command.

Pretty nifty, eh?

*I say small, it gets bigger every day.

Advertisements

Install and run RVM and Ruby 1.9.x on Red Hat OpenShift

UPDATE (03-08-12): This post is now largely obsolete as we now have a Ruby 1.9 cartridge available on OpenShift! While this is awesome, I’ll still be working on other little hacks including the Unicorn/Nginx cartridge, a specialised Ruby version manager for DIY cartridges and a little set of tools to quickly interact with your app above and beyond what rhc-tools let’s you do. You can still refer to this post however if you want to use the abilities of RVM on a DIY cartridge. Hope it helped!

When I first started investigating Red Hat’s new Platform-as-a-Service – OpenShift – for deploying my CRM app on, I discovered that they’ve only officially launched a Ruby 1.8.7 environment. I discovered I wasn’t the only person wishing for Ruby 1.9.x support on the forums, so I decided to see if I could install and use RVM on the system. Thankfully, Red Hat give you the ability to SSH into a restricted bash shell to manage your apps and this proved key to getting it to work.

After 3 long nights, I’ve managed to successfully install my own custom version of RVM designed for the OpenShift servers, and built and run Ruby 1.9.3-p125 and Rails 3.2.3, so here I explain how:

1. Create a DIY cartridge and configure SSH Access

Before you start, you need to create a “DIY” cartridge, or app. This is a blank slate where you configure the system yourself. This is just so we don’t get any version conflicts or config errors:

rhc-create-app -a [appname] -t diy-0.1 -l [email] -p [password]

You can also create the app through the new web console, but using the rhc tools will create your repository and perform some other setup (such as SSH public keys), which you’ll have to do manually otherwise.

To get your SSH details, run the following:

rhc-domain-info -l [email] -p [password] --apps

This will print out all the apps in your namespace and their corresponding information. The ‘UUID’ is your SSH username and the ‘Public URL’ (minus the “http://”) is the SSH server. You should then be able to connect like so:

ssh 9a4c7dbdc3@rvm-pyramidthoughts.rhcloud.com

2. Download and Install RVM for OpenShift

Once connected to your app instance, use the following command to download and run the automated installation script I’ve written.

UPDATE (03-05-12): If you were getting an error from curl like in the comments below, its because GitHub altered the  path!  – The curl command should now work properly.

cd $OPENSHIFT_DATA_DIR
curl -L https://raw.github.com/xiy/rvm-openshift/master/binscripts/install-rvm-openshift.sh | bash -s

In short, it will download a working copy of the libyaml-0.1.4 source and compile it, and then dowload and install my version of RVM, as well as installing the latest stable version of Ruby (1.9.3-p125). During my testing, the copy of libyaml that RVM fetched was configured wrongly and failed to build on the servers, hence the custom build.

NOTE: You may also want to build readline if you require it (for irb etc.) and configure with ‘–prefix=$OPENSHIFT_DATA_DIR/.rvm/usr’ to ensure that it’s linked with Ruby when it compiles. This has to be done BEFORE Ruby is compiled.

3. Install and configure a Rails app

Once Ruby and RVM are completely installed, test that it works:

$ source $OPENSHIFT_DATA_DIR/.rvm/scripts/rvm
$ rvm use 1.9.3-p125@global
$ ruby -e 'puts "Hello OpenShift!"'
=> Hello OpenShift!

All going well it should say hello. You should now be able to create your Rails app and code away locally. Make sure you have a ‘.rvmrc’ file in the root of your Rails app that lets RVM know what version of Ruby to use and the name of the gem set.

Update (23-05-2012): You can create AND initialise your project .rvmrc with one command, thanks to @wayneseguin

# NOTE: These commands should be performed INSIDE your Rails app dir.
$ rvm --create --rvmrc 1.9.3-p125@[appname]
$ rvm use --create 1.9.3-p125@[appname];
$ touch .rvmrc && echo 'rvm 1.9.3-p125@[appname]' >> .rvmrc

Also make sure that you edit the action_hook scripts to perform the necessary housekeeping. At this point, I would also suggest using a server such as Thin in place of the clunky WEBrick. You can run it via the rails builtin script or like I’ve done here:

.openshift/action_hooks/post_deploy:

# this will spawn a sub-shell, so make sure we can use rvm
source $OPENSHIFT_DATA_DIR/.rvm/scripts/rvm

# make sure our bundle is up to date
cd $OPENSHIFT_REPO_DIR/[appname]
bundle

.openshift/action_hooks/start:

# this will spawn a sub-shell, so make sure we can use rvm
source $OPENSHIFT_DATA_DIR/.rvm/scripts/rvm

# make sure we're in the app-dir so we use the right gemset
cd $OPENSHIFT_REPO_DIR/[appname]

# start the thin server on the internal ip and port
bundle exec thin start -d -a $OPENSHIFT_INTERNAL_IP -p $OPENSHIFT_INTERNAL_PORT -l $OPENSHIFT_LOG_DIR/thin.log

NOTE: You may also want to symlink the environment logs in the rails app logs directory to the $OPENSHIFT_LOG_DIR to make sure you capture everything from your app, as in testing I’ve found that the Thin process doesn’t seem to log everything.

.openshift/action_hooks/stop:

# kill the server through the pidfile
kill `cat -- $OPENSHIFT_REPO_DIR/[appname]/tmp/pids/thin.pid`

Unicorn is another great alternative thanks to it’s performance and worker threads, which is ideal for a restricted resource environment like OpenShift. I would also pair it with Foreman and dump the stdout of Foreman into ~/app/logs so that it can be tailed locally with the ‘rhc-tail-files’ command. You can also hook into a service like Travis-CI in your ‘.openshift/action_hooks/pre_build’ script to run your integration tests. I may have to write a blog post about action_hooks soon that can show all this in action.

At this point you should be good to go and code away and push your Rails 3.2+ app up to the OpenShift servers on MRI Ruby 1.9.x. If you want to see a Rails 3.2.3 app running on Ruby 1.9.3-p125 to prove it works, go here.

Enjoy!

p.s If you’d like to improve my hacky edits to RVM or if there are any bugs, you can browse the repo on my GitHub: http://github.com/xiy/rvm-openshift.

NCBI BLAST+ Sequence Server

Stretching my legs with some Ruby + Bioinformatics work on the excellent new open-source, Sinatra based web frontend to NCBI BLAST+ called SequenceServer (http://github.com/yannickwurm/sequenceserver).

I needed to get out of the stuffy C# room I’ve been in for months for a bit, but I’ll be working on my testing framework again when I’ve cleaned out ma’ brain.

My fork is at http://github.com/xiy/sequenceserver if you’re an academic interested in using a nice clean interface to your local BLAST databases.

Stay classy, San Diago (which of course means “A Whale’s Vagina”)