OpenShift is a Rails friendly PaaS – Part 1

Even though setting up Rails is simple on OpenShift, sometimes I get questions like “do I have to do X” or “why do I have to do Y”. I am going to explain how you can create a Rails instant app and also how to bring your existing application into OpenShift with a focus and why the various steps are needed.

Instant application

Recently OpenShift announced what we call Instant applications – one-click solutions to set up a particular framework/product. Among Spring, WordPress or Drupal, OpenShift offers Ruby on Rails. If you are starting a new project, this is your path to getting going quickly.

What actually happen when you create an instant app is as follows:
1. OpenShift creates a new ruby based gear for your application with a MySQL cartridge embedded in it.
2. Then it pulls this repository into your gear repository.
3. Checks out the source and spins up the servers.
4. Done – Ruby on Rails running on OpenShift.
You can then clone the git repository from the gear locally and start developing your application. Very simple, very effective.

However, you don’t want to start with a clean application every time, right? Let’s take a look on how to configure your existing application to run on OpenShift.

Setting up basic application

Let’s create a Ruby gear and embed MySQL in that

rhc app create rails ruby-1.9 
rhc cartridge add mysql-5.1 -a rails 

Now move or copy your rails source into the local rails repository/directory that was created as part of the app creation command. Now just git add and commit.

Configuring a database

In OpenShift you are supposed to configure the database yourself, we do not make any assumptions on applications that are running which gives maximal flexibility on what can be deployed. But as it is said, with great power comes great responsibility.

To enable your database, add the required gem to Gemfile (located in the root of your application). For MySQL mysql2

gem 'mysql2'

and pg gem for PostgreSQL

gem 'pg'

Mongo is more specific and I will cover that in the next part, stay tuned!

Now edit the connection information in config/database.yml to reflect the OpenShift connection parameters. You should not hardcode this information into the configuration file, but should utilize our environment variables that OpenShift creates to provide the applications with runtime information.

Change the production part of that file to look like

  adapter: mysql2
  encoding: utf8
  reconnect: false
  pool: 5
  database: <%=ENV['OPENSHIFT_APP_NAME']%>

or look like this for PostgreSQL

  adapter: postgresql
  encoding: utf8
  reconnect: false
  pool: 5
  database: <%=ENV['OPENSHIFT_APP_NAME']%>

If you change the Gemfile, bundle your gems

bundle install

then git add and git commit.

When you run bundle install Bundle will analyze the dependencies you have in the Gemfile and will create a file Gemfile.lock, that will list all gems required to run the application, their versions and location where to install them from. OpenShift then uses this Gemfile.lock to install those dependencies for you.

Enabling migrations

OpenShift by default does not run migrations. But it is very simple to allow them. Edit the .openshift/action_hooks/deploy in your repo and uncomment the three lines

pushd ${OPENSHIFT_REPO_DIR} > /dev/null
bundle exec rake db:migrate RAILS_ENV="production"
popd > /dev/null

git add and commit.

Your application should now be ready, so you can finally git push.


You should be ready now. If you do not have any special dependencies in your code, there should be no problem with getting your application running. I plan on writing two more parts of this -series. The second one will discuss MongoDB support and third one will focus on horizontal scaling in Rails. If there are other Rail topics that you would like to see covered, let me know and I will incorporate those into this mini series.

Comments are closed.