Just a couple of years ago finding an afordable hosting solution for a java web application was a hard task, and looking for a free one was an impossible mission. Not to mention that even thinking about things like auto-scaling, one-command deploy, continuos integration, and that sort of stuff was plain science fiction.

This last year has witnessed a cloud revolution, and nowdays there’s a really appalling amount of alternatives to choose from. It seemed like every medium-to-large size IT player had to come out with their own Platform as a Service (PaaS) cloud offering.

In this scenario, an offering from Red Hat couldn’t go unnoticed. Red Hat engineers really know a lot about managing servers, and, lucklily for us, they also know a lot about java web applications. Fortunately, they took the challenge, and what they have to offer would certainly not disappoint us.

Isn't that panda bear cute?

So, here comes Openshift. Openshift is Red Hat’s free, auto-scaling, cloud-based platform-as-a-service for Java, Perl, PHP, Python, and Ruby applications. It’s a quickly evolving platform, that managed to shape a vibrant and helpful community supporting it. Moreover, it’s free offering largely surpases anything that the competence has to offer. Just by entering your email and choosing a password, you get five applicacions namespaces, each of them with a git repository and half GB of data (code + database) to use as you like it. Add to that support for mysql (with phpmyadmin), PostgreSQL, MongoDB 2.0 (with MongoRock) and even a fully functional Jenkins instance to have a continuous integration environment.

Deploying a java web application to openshift is really easy, just git add, git commit, git push… and that’s it. But we, play developers, spoiled by our beloved framework as we are, would rather just type something like play rhc:deploy and forget about it.

Every time you want to deploy your changes to openshift, just issue once again play rhc:deploy -o. The -o parameters just tells the module to open your application on a web browser right after deployment.

From zero to the cloud

Just as a reminder to myself, here are the steps required to go from a bare linux installation to deployment on openfhit:

4. Install, git and ruby gems

5. Install openshift client tools

Once you have installed ruby gems, installing red hat cloud tools is as easy as:

$ sudo gem install rhc

6. Create a domain

Your domain namespace is used to help identify your applications and as part of the URLs to your applications. It’s unique to you across all of openshift. For example, let’s say you have the namespace awesome, when you create a new app called wicked, you’ll find it at http://wicked-awesome.rhcloud.com. When you create a new app called freakin, it’ll be at http://freakin-awesome.rhcloud.com.

7. Create and register your SSH keys

Now you’ll have to a SSH key, which in fact means creating a private and a public key, so that openshift can validate that it’s really you the one trying to push something to the remote git repository. Just follow the steps at http://help.github.com/linux-set-up-git/, you just have to open a terminal and then

$ cd ~/.ssh

If you get a No such file or directory error, don’t worry, it means that you didn’t have any SSH key on your system. On the other hand, if you already have a SSH key, it would be a good idea to make a backup.

Now you have to register this key at openshift. Just copy the content of the id_rsa.pub (be careful not to copy the file id_rsa, it’s your private key, and you should keep that to yourself) and add it as a new SSH KEY from your control panel.

On Fedora is pretty annoying having to enter your passphrase on every git operation. To avoid it, just run ssh-add and enter your passphrase for the last time.

and let openshift create a a pair of private and public keys as libra_id_rsa and libra_id_rsa.pub at your .ssh/ directory. I had a couple of conflicts between my own SSH keys and the libra ones created by openshift, so I prefer to handle the ssh keys myself.

Note: You won’t be able to push anything to your git repository unless you have a valid public key registered at openshift. Take into account that you can add as many keys as needed.

After that you should check that you have installed all the prerequisites. Just run:

$ play rhc:chk

It will check for a java 1.6 or 1.5 install, git, ruby, rubygem, and openshift client tools 0.84.15 or higher. It will also check that the application exists on openshift, otherwise it will ask you to create it, and finally it will check that you have a local git repository pointing at the remote repository at openshift.

Then you can deploy your app with:

$ play rhc:deploy -o

The first time it will take quite some time to issue the deploy, because the module has to upload all of the play framework libraries. After that initial deploy, subsequent commits will be much faster, because git is smart enough to send only the changed files. Moreover, the module will ask your permission to create the app on openshift, and also to create a local repo. If you just want the script to create everything withour asking for permission, just add a --bypass or -b parameter to the command.

Your application will now be available at: http://<my app>-<my domain>.rhcloud.com.

If you have already deployed your application to openshift, and you just want to retrieve it from your remote git repository, just issue:

$ play rhc:fetch

Take into account that this is a destructive operation. It will completely remove your local application and replace it with the contents of your remote repository.

To have a look at your server logs, issue:

$ play rhc:logs

Having a look at openshift log files with "play rhc:logs"

To display information about your applications on openshift run:

$ play rhc:info

Which is just a short-hand for the rhc-domain-info command.

You can open your application at openshift anytime issuing:

$ play rhc:open

Which is also a short-hand for opening a web browser at http://<my app>-<my domain>.rhcloud.com.

Finally, if you think you want to remove your application from openshift, just run:

$ play rhc:destroy

Installing the openshift module

There are two ways to install openshift module. One is just to issue play install openshift, which will install the module directly with your framework, at <play install folder>/modules/openshift-0.1.1. That way it will be available to every app you create with

$ play new my-app --with openshift

The other way is to manually configure it as a dependency. Just add the following line to your conf/dependencies.yml file:

# Application dependencies
require:
- play
- play -> openshift 0.1.1

And then issue

play deps

Note: play keeps a cache of fetched dependencies at ~/.ivy2/cache. If you are having troubles with dependencies just clean that directory and try again.

Along with the module there’s a sample application at <openshift module folder>/samples_and_tests/openshift-demo. Just go to that folder and issue play deps and then play run to see it running locally. It just displays play configuration and the host environment variables to let you check that your app is running on openshift.

Openshift module demo application

Then run play rhc:chk to verify that you have installed all the prerequisites. After that issue play rhc:deploy -o to create your remote application at openshift, create a local git repo, package your app as a war file, commit your new app, and deploy to openshift. Thanks to the -o parameter the module will open your openshift app in a web browser after deployment.

Known issues

Unfortunately, right now the openshift module doesn’t work with windows. That’s because the module issues many git commands, and you can’t do that on windows from the standard shell, it requires a special “git bash” prompt.

Further steps

In the next version I’ll be exploring the possibility of building a java only version of the module using openshift’s java api. That way we won’t be needing git, ruby, nor the rhc tools installation. Morevoer, we should be able to use it all from windows as well.

Share this:

Like this:

Related

8 responses to this post.

Thanks for the article; I struggled quite a bit to get my Play! app hosted on Google App Engine and have been timid to take other cloud offerings seriously…but that is about to change after reading your article.