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.

Advertisements

shoulda, woulda, coulda

I hate Testing Frameworks. Actually, let me be specific…I hate .NET Testing Frameworks. They make me angry and sad; so I’ve decided that because I have nothing better to do, I’ll write my own. But first, a little comparison…

VS2010 Testing Framework (MSTest?)

Microsoft’s built in testing system isn’t too bad. It’s integration is done well, but it’s so bloody overly complicated and slow, and messy. Every test you perform dumps a shit-load of messy files everywhere on your filesystem and inside your solution folder. It then has the CHEEK to complain that you should delete some when it gets “full”?

Poor effort Bill (or is it Steve now?)

NUnit

As far as I’ve ever been able to tell, this is simply a big, even more bloated version of the above. Some of the testing functionality is simpler and easier to understand, and it does have more assertions…that’s where the good things end. Like a lot of software, it’s probably the most used? Weird that.

xUnit

Made by the same blokes as the above, but apparently it’s better and easier to use. I went over their comparison table they’ve got up on their Codeplex site….yeah, no. If anything, it’s a massive excercise in how to complicate a piece of supposedly useful software even further. I mean…test methods are called “Facts”? Not only that, the method to actually get testing is beyond annoying.

Getting there…but not quite.

Should…

I’m tired. I like ruby, I like libraries like “shoulda” and “cucumber”. You just want to test whether that function does what you want it to; does it fulfil the requirements? Does it do what you expected it to do? I got tired of fumbling around the above libraries. I wanted a simple, easy to use, easy to understand testing framework so that I could test Nucleo quickly and effectively, so I created “Should”. At least that’s what It’s called at the moment.

Creating a test involves (at the moment) two things:

  1. ShouldTestContext<T> object. Think of it as the manager for all your tests. The generic type parameter <T> is the object you want to perform tests on, or the “context”.
  2. One or more Expectation objects. An expectation test is exactly that; it tests an expectation of something else.
  3. Once you’ve set up all your expectation tests, you make a call to theShouldTestContext<T>.RealiseExpectations() method and shazzam, it tests away!

Expectation Test Syntax

I wanted to make writing the actual tests as easy as possible; plain english if i could. Turns out I could:

Expectation ex = new Expectation(() = { return true; }, "should return true"); 

Here, I’ve created a new expectation test and fed it a lambda expression as a delegate that simply returns true (for demo purposes) and my expectation (logically) is that it “should return true”. Using a simple parser, an Expectation is then created by analysing the logic of the expectation string. The parser determines the type of test by what kind of type is passed to it (method, property, field etc.) and then runs a test against the object based on the given expectation. The kind of tests you can run are all your usual suspects, and I may add a few more in the future. Here are some examples of some expectation test strings:

"should contain 'Hello'" (test a collection, array or string) "shouldalways return true" (test a constant) "shouldnot have length > 10" (test a property or field) 

The important thing to note is that, underlying all of this is the same basic usage of assertions. It’s the way in which those assertions are performed which is the cool thing. I am also making it completely programmatic too, so if you want to write your tests in the standard way, you still can, and they’ll still be beautiful:

Should.BeEqual(1, 1); Should.ReturnTrue(() => { return true; }); Etc. etc. - more to come..