================================

So you just want to get down to business and deploy your Play apps with native support on Openshift? Ok, just follow these simple steps for Play framework 1 or Play framework 2

In this article we'll show you what you can do with the new "do-it-yourself" application type on Openshift. As an example, we'll see how to implement native support for Play framework application, version 1 and 2, on Red Hat's PaaS.

Openshift PaaS gives you lots of choices for developing and deploying applications on the cloud. You can pick among Php, Ruby, Perl, Python or Java, and on the databse side, you get to choose between mysql, postgresql and mongodb.

But in today's web development quickly evolving landscape, you just can't provide every possible option. It's becoming everyday more common to work with custom-made http servers built for enhanced responsiveness and greater scalability. In the Java landscape, what used to be the omnipresent servlet container, is no longer the only option available...

So, what can we do to support all these heterogeneous and constantly evolving technologies? Well, Red Hat engineers came out with a simple, yet powerful, solution.

=====================================

These are the application types current supported by openshift:

jbossas-7, python-2.6, jenkins-1.4, ruby-1.8, diy-0.1, php-5.3, perl-5.10

They are all pretty sef-explanatory, except one of them that looks rather suspicious: diy-0.1

A "diy" application is just a barebones app, with no server preloaded, ready to be tailored to your needs. With this new offering, Openshift is begining to blur the line between an IaaS and a PaaS, providing you with a controlled and scalable environment, and at the same time giving you the freedom to implement the technology that best suits your needs.

=============================================================================

To show you the power that this new application type puts in your hands, we'll implement a long awaited feature on openshift: Play framework native support.

Play is a framework that makes it easier to build web applications with Java and Scala, allowing Java developers to achieve productivity levels only known to people working with frameworks like rails or django. Play is also one of those frameworks that abandoned the servlet container mantra and instead decided to take a different path. Play implements it's own, lightweight and highly optimized, asynchronous http server based on Netty, a network framework which happens to be part of JBoss.

You can distribute a Play app as a war package and deploy it to any servlet container (and indeed it's very easy, have a look at this article), but you would be wasting resources and missing advanced features, like asynchronous request handling.

To see what we are trying to achieve you can have a look at the github quickstart project we prepared at github. You just have to create a new diy application, pull the quickstart sources from github repository, and then push the app to your openshift repo... and that's it!

rhc app create -a play -t diy-0.1
cd play
git remote add upstream -m master https://github.com/opensas/play-example.git
git pull -s recursive -X theirs upstream master
git push

After that your app will be ready at http://play-yournamespace.rhcloud.com

You also have quickstarts for Play framework 2.

In this article we'll see how we developed these quickstarts, and give you the basis for tweaking Openshift to fit your needs.

=====================

Before attempting to create a diy application on Openshift, you have to familiarize yourself with the technology you are about to use. You should have a clear understanding of the steps needed to set it all up on your workstation and then reproduce it on Openshift.

For a play application we need no JBoss, nor any application sever, no Tomcat, and not even a servlet container at all. We just have to install the framework and start Play's own http server.

Doing this on your own workstation is as easy as downloading Play, unzipping it, and then running:

play new demo
cd demo
play start

To stop the application we issue

play stop

Now we'll have to do the same in our server at Openshift.

=============================

Let's create a new application named 'raw'

rhc app create -a raw -t diy-0.1

Now let's see what we created

rhc app show -a raw

Application Info
================
raw
    Framework: diy-0.1
     Creation: 2012-03-19T01:18:31-04:00
         UUID: youruuid
      Git URL: ssh://[email protected]/~/git/raw.git/
   Public URL: http://raw-yourdomain.rhcloud.com/

You can browse to http://raw-yourdomain.rhcloud.com/ to see the following page

It's just the same static page you can find at raw/index.html

Now let's see what we have in our repo:

cd raw
ls -a

.git                      # our local git repo
misc                      # empty dir, you can just deleted it, no one will miss it
.openshift/action_hooks   # this is where our hook scripts are located
raw                       # it holds the static page
README                    # some info

Pretty barebone app, but there's a folder that's quite interesting for us:

ls .openshift/actions_hooks
build  deploy  post_deploy  pre_build  start  stop

These are the scripts that Openshift uses for building, deploying, starting and stopping our app. These scripts are executed on the remote Openshift server, so now we'll have a look at it to better know our environment.

Take the output from rhc app show and issue the following

ssh [email protected]

You'll be at your HOME directory on your Openshift server. You have the following structure:

git
    .env            # Contains the definition of your environment variables

    <your app>.git  # That's your git repo at ssh://[email protected]/~/git/raw.git/

<your app>

    repo            # $OPENSHIFT_DATA_DIR - Here you'll find the content of you app folder.
                    # everytime you push changes the data is saved here.

    data            # $OPENSHIFT_DATA_DIR - This is a persitent directory, 
                    # the info in there will survive the server restarts. 

    logs            # $OPENSHIFT_LOG_DIR - This is where you should save the logs of your app. 
                    # It's the folder that's scanned by the 'rhc app tail' command

/tmp/             # $OPENSHIFT_TMP_DIR - Temporary folder, you have write permissions in there

These are basically the folders that we are interested in.

====================

Now we'll take a simplified version of the play 1.x quickstart project to see how to do it. We added links to the real script for you to have a look at them.

First we'll have to prepare the .openshift/action_hooks/pre_build script to check if the framework is installed, and if it's not it should download it and install it.

You could issue something as simple as this:

.openshift/action_hooks/pre_build (script at github)

if [[ ! -d ${OPENSHIFT_DATA_DIR}play-1.2.4 ]]; then
  curl -u ${OPENSHIFT_DATA_DIR}play-1.2.4.zip http://download.playframework.org/releases/play-1.2.4.zip
  unzip ${OPENSHIFT_DATA_DIR}play-1.2.4.zip
  rm ${OPENSHIFT_DATA_DIR}play-1.2.4.zip
fi

Then to start the application

.openshift/action_hooks/start (script at github)

cd ${OPENSHIFT_REPO_DIR}

.openshift/action_hooks/stop

#tell play to save log files in openshift log dir
export PLAY_LOG_PATH=${OPENSHIFT_LOG_DIR}

#run with openshift id
${OPENSHIFT_DATA_DIR}play-1.2.4/play start --%openshift

Don't forget to configure your server to listen to port ${OPENSHIFT_INTERNAL_PORT} on address ${OPENSHIFT_INTERNAL_IP}

In our case we just add the following lines to our application.conf file:

%openshift.http.port=${OPENSHIFT_INTERNAL_PORT}
%openshift.http.address=${OPENSHIFT_INTERNAL_IP}

And now all we have to do is the stop script

.openshift/action_hooks/stop (script at github)

cd ${OPENSHIFT_REPO_DIR}

if [[ -f "server.pid" ]]; then
  ${OPENSHIFT_DATA_DIR}play-1.2.4/play stop
fi

And that's it. Remember that this is a simplified version, with no error checks and no logging. For a more complete example have a look at the real quickstart scripts in openshift

In the next article we'll see how we applied this very same technique to natively deploy a play framework 2 application on openshift.

Conclusion

From it's very beginning Openshift has provided support for a wide range of standard technologies. With this new option, it also gives you the tools to completely customize it to your needs. You just need to get familiar with Openshift environment and start hacking away some simple bash scripts.

I just can't wait to see what the community will create with this new Do-It-Yourself thing at Openshift.