Over a million developers have joined DZone.

Running Play 1 Natively on OpenShift

DZone's Guide to

Running Play 1 Natively on OpenShift

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.


So for a while now, I have been using Heroku for my hosting of Play applications. It is easy, very fast to deploy and therefore first into my mantra for development (be productive). My only issue with Heroku is the database. When I created the Play developer map, I knew that the database size was likely to be an issue, so I worked around the problem, by using a cloud database that I already had an account for.

Recently however, I have been working with some friends and we wanted to build a site which again would likely break the Heroku limit of 10K rows in the database. However, this time I didn’t want to be mixing my personal cloud db account with an application that we may want to scale up at any time. So, I went looking for an alternative solution. The options are actually pretty limited if you don’t want to splash out immediately. So the one that intrigued me the most was OpenShift. It gives you 1Gb, regardless of whether this is used for DB, application files or other.

The downside of OpenShift, is that Play is not supported as a native application server, and I needed the native features (too many potential surprises when using a WAR wrapper around a Play application). OpenShift has the concept of DIY cartridges though, that allow you to install whatever Java process you like, as long as it binds to the correct port number. So it can be done!

I spent a good few days messing around with different configurations, following other’s blog posts and installing VMs (the Play OpenShift module doesn’t work on Windows, so I tried using a Ubuntu VM on VirtualBox to trial that approach!).
Anyway, the good news is that it is relatively straightforward, once you have jumped over the hurdles in your way, so this is intended to save anyone who wants an alternative to Heroku a great deal of time in deploying an OpenShift application natively.

In a nutshell, the steps are

  1. Sign up to OpenShift
  2. Install Ruby and GIT (I deployed from Windows, so used Ruby for Windows and GIT for windows)
  3. Install RHC (red hat console) using the Ruby Gem — gem install rhc
  4. Create an application on OpenShift using a DIY cartridge
  5. Put your application code in the cloned directory
  6. Copy the open-shift hooks (see code below) into the hooks directory, which will install Play on the DIY cartridge, and correctly start/stop Play when needed
  7. Set up the application.conf to work with OpenShift ports/db/etc
  8. GIT Add/Commit/Push, to push the code to OpenShift, and watch the magic happen!

Step 1 – 3 will only ever need doing once. Once configured, each modification simply needs a GIT add/commit/push to see your changes running (Step 8). Step 4 to 7 should be a case of copy/paste. So, hopefully, we can have you up and running in no time.

The Detail

Steps 1, 2 and 3 – SignUp and Install Software
I won’t go into detail on Step 1 to 3, as the OpenShift information does a very good job of doing so. So, follow steps 1, 2 and 3 on the OpenShift Setup page and install the necessary tools for your platform (Ruby, GIT and RHC) plus sign up for an account and set up RHC.

Step 4 – Create an application
Before running the following command, make sure a directory with the same name of the app you want to create doesn’t already exists, otherwise the git clone will fail. Once you are happy, run the following code from the command prompt.
rhc app create #appname# diy-0.1

Replacing #appname# with the name of your application. This will create a DIY cartridge for you. This will automatically call GIT clone, to clone the application on to your local machine. If for some reason you have created an application using the Web site at OpenShift, you can use git clone to clone the repo to you local machine, but in our example, you don’t need to do this.

The output will also tell you the URL where you will be able to access your application, so keep a note of it at this point!

If you want a Database (which was kind of my whole reason for coming to OpenShift), then follow this command with

rhc cartridge add mysql-5.1 -a #appname#

Again, replace #appname# with your application name you set up in the previous command.

Step 5 – Develop your Play application
Store all your play application code inside the cloned repository, in the standard Play structure. If you have already started a play app, and are just looking to deploy it, you can safely just copy all the play code into the cloned repo, so that app, public, conf, lib etc are all at the same level as the .openshift directory. If you are starting a new application, create a new application with a different name (otherwise Play will complain a directory already exists), and copy the contents of the new application into the cloned repo.

You directory structure should look something like
|+ .openshift
|+ app
|+ conf
|+ diy
|+ lib
|+ misc
|+ public

You can still run play run from this structure as you did before.

Step 6 – Get the open_shift hooks!
The open shift hooks are a set of bash scripts that are executed at certain stages of the server’s lifecycle. It has scripts for things such as pre-build, start, stop etc. These are the scripts that will, install Play if it doesn’t already exist (so it will only install it once, unless you specify a new version), start the server and shutdown the server when OpenShift spins up and spins down instances. This is the bulk of the work for an OpenShift DIY cartridge. Fortunately, you can copy the code verbatim.

When you created the app, and the repo was cloned, a set of empty action_hooks were created and downloaded. There should have been 6 in total. These are

  • Build – We can leave this blank
  • Deploy – We can leave this blank
  • Post-Deploy – We can leave this blank
  • Pre-Deploy – This is where we will download and configure Play
  • Start – This will start a Play instance
  • Stop – This will stop a Play instance

So, we have 3 scripts we need to populate, and to make things easier, we will also create a shared script to help set up the configuration variables which will allow us to get data from our Play application.conf as well. These scripts were written by opensas, but I have updated them as there have been a few platform changes since his version was published.

Copy the following code into the action_hooks directory, and we are almost good to go!

Go to https://github.com/codemwnci/play-openshift, and copy the files into your action hooks directory.

NOTE: In the start script, I have configured the timezone to be for London (as OpenShift is US based, and most of my web apps are for UK based). If you don’t care about the default timezone, just delete the
in the start script, or if you want a different timezone, update the value before you deploy your application.

Step 7 – Set up the application conf
Inside the scripts above, Play is configured to start with the ID of openshift. This means that we can keep our openshift config and local config completely separated. So, inside of your application.conf, place the following pieces of config.

# Openshift id configuration
# ~~~~~

# openshift mysql database
# ~~~~~

Replace #appname# with the name of your application (the same name as you set up in step 4). This allows Play to use the short db configuration, rather than the 4 individual parameters.

Step 8 – Commit and Deploy

Finally, we are ready to deploy our app. So quite simply we run three simple GIT commands.
cd #appname#
git add .
git commit -m "deploy to OpenShift"
git push

If you want to see the log files for your app running, you can tail the logs by running
rhc tail #appname#

Again, replace #appname# with the application name set up in step 4.

Now, all you need to do is to browser to the URL that you noted in Step 4, and you are done!


I hope this saves you hours of effort. The time it has taken me to type this up hopefully will be less than the time it would take you to figure all this out through trial and error, like I did. Enjoy.

And for those following the Yalp progress. I will create a Quick starter guide for Yalp as well, when it gets closer to a release candidate.

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}