Using Perl on Red Hat’s OpenShift Cloud

Here at All Around The World, we like to pay attention to new technology trends, but do so with a bit of healthy skepticism. We’ve seen many new programming languages come and go. We’ve seen “exciting” new technologies fade to nothingness. In short, we’re not keen on hype. There are some relatively new technologies that we’re very positive about, however. Today we’re going to talk about OpenShift, Red Hat’s Platform as a Service (PaaS), and walk you through creating a small Perl/PostgreSQL application on it.

Red Hat’s OpenShift service is a cloud service built on top of Amazon Web Services (AWS) and offers Platform as a Service. Unlike Infrastructure as a Service (IaaS) such as AWS, which only offers bare bones hardware configurations on demand, and Software as a Service (SaaS) which offers you fully functioning applications (such as Gmail) but no flexibility, PaaS offers you  a middle ground: it provides the full operating system and handles the system administration for you. The operating system will be kept up to date for you, your tools will be patched for you, your DNS will be managed for you, and so on. Your job, as a developer, is just to develop and deliver applications without worrying about about managing your hardware or software infrastructure.

Interestingly, OpenShift is designed to be automatically scalable, which in theory (color us skeptical) should also free you from the drudgery of managing multiple servers to handle different tiers of your application. While it remains to be seen what the future is, we think PaaS is very exciting.

We’ve already heard complaints that as a developer, you still need to know how to handle system administration tasks (or hire someone to do it for you), but we think of this as a similar, though more important, argument to what we say in the early days of Java. People complained that garbage collection could never be as good as explicit memory management, but even a decade ago we saw signs that this was not true (pdf). PaaS is a larger problem space, but the developer benefits may be enough to outweigh the risks and in the future, those risks will be minimized.

So we’ll explain how we wrote a small application on Red Hat’s OpenShift service. It’s called the InsultApp (try it out!) and it generates “Shakespearean” insults based on the Python code presented in O’Reilly’s free OpenShift ebook. Download that ebook and it will help you follow along. Fortunately, it’s a short, easy read.

When your author tweeted about the ebook, a Red Hat employee (and one of the book authors) replied that your author should port the Python to Perl (which he subsequently did and Red Hat added Perl app to the ebook github code download page).

Truth be told, your author wasn’t sure he had the time to do this and assumed there would be all sorts of fiddly problems with OpenShift and spare time is a luxury for him. Interestingly, it only took about two hours to port the app, using Dancer and PostgreSQL, and that was taking a couple of breaks for other tasks. Note that doing all of this is free of charge using their free tier.

First, we signed up for a free OpenShift account. Next, we installed the command line tools. There are Eclipse plugins and a Web interface, but we prefer the power of the command line.

We ran rhc setup and followed the prompts. One prompt required a unique domain name and we chose “veure” (long story). We called the app insultapp, after the one in the book, and ran the following:

$ rhc app create insultapp perl-5.10

Yes, they only support the long, long, out-of-date perl-5.10. We understand that there’s a new cartridge of Perl that will be available soon, but for now, this is enough.

Note that when you create your app, it will dump a lot of useful information for you,
including your application URL. Don’t forget this URL! Also, you probably want to add -s to the command above. That switch says “make my application scalable”. At the present time, there is no procedure for making a non-scalable app scalable.

When you create your app, it will place it in ~/$appname/ as a git repo. Move that directory wherever you want and cd into it.

Now as it turns out, there’s a “quickstart” OpenShift Dancer application available on github. It’s Dancer and not Dancer 2, but that’s OK for this small example. Using another Web framework should be simple. We merged that into the insultapp project:

$ git remote add upstream -m master git://
$ git pull -s recursive -X theirs upstream master
$ git push # installs dependencies and builds the app

The push will take a long time as it downloads and installs all of the Perl modules you need. When it’s done, you can open your browser and navigate to your URL (you remembered to save it, didn’t you?)

OK, now that we have a shell of a Dancer application running on OpenShift, we need to go into dangerous territory and install the PostgreSQL cartridge (think “package manger”). We always find that very fiddly, but we ran the command:

$ rhc cartridge add postgresql-9.2

Adding postgresql-9.2 to application 'insultapp' ... done

postgresql-9.2 (PostgreSQL 9.2)
 Gears: Located with perl-5.10
 Database Name: insultapp
 Password: *
 Username: *

OK, that worked. We were also pleasantly surprised to discover that DBD::Pg had also been built and configured for us.

Assuming you installed the command line tools and you’re inside of your application directory, you can do this:

$ rhc ssh

You have now sshd into your ‘gear’, your server in the cloud. From there, you need to launch the PostgreSQL client and create your database (\e in PostgreSQL is used to edit your SQL directly in an editor):

[ ...]\> psql
psql (9.2.7)
Type "help" for help.


Then paste contents of the insultapp import.sql into the editor. Exit your editor and your database should be populated.

Type \q to exit Postgresql.

Type exit to exit your cloud instance and return to your box (i.e., end your ssh session).

Inside of your application directory, type cd openshift and you’ll see your normal Dancer application with lib/, t/, bin/ and other directories. Then, you hack, hack, hack to build the code you need. Any Perl dependencies should be added to .openshift/cpan.txt. Then you just:

$ git push

That should build your application and install needed dependencies. It will take a while.

Then navigate to the URL mentioned previously and see your code running on the cloud.

The code is available on github and the instructions there tell you how to upload the code to your OpenShift instance, instead of creating your own.

Note that if you want to test your code both locally and remotely, you’ll need to be a bit more robust than we were. For example, here’s the code to fetch a database handle:

sub get_dbh {
    my $app  = $ENV{OPENSHIFT_APP_NAME};
    return DBI->connect_cached(
        { AutoCommit => 0 }

You will either want to set up those environment variables on your own box or, better yet, creating a configuration package that can figure out where you’re running and encapsulate that information for you.

Of course, as you later wish to release your beautiful creation to the world, you can use DNS to create your own URL rather than using the default one. You can also use SSH, set up cron jobs, use WebSocket’s, or just about anything a typical application will need.


We couldn’t believe how easy this was. Everything just worked. However, only Perl 5.10? While this doesn’t make OpenShift useless for Perl, it’s severely limiting, but this is because RHEL only supports that version of Perl. You can build your own cartridges, but 5.10 support ended almost five years ago and 5.16 is the minimum supported version. We don’t understand why Red Hat won’t upgrade to a supported version of Perl.

That being said, having a PaaS vendor that actually supports Perl is great news for Perl developers.

We think PaaS is probably ready for small and medium size apps and we have the idea of creating a small timekeeping application for All Around The World and hosting it there. Most “free” applications for timekeeping don’t meet our needs. For larger, “enterprise” apps, we wouldn’t go there yet, but people will in the future.

If you would like to hire any of All Around The World’s talented consultants for development, training, or recruiting, drop us a line at

This entry was posted in General. Bookmark the permalink.

4 Responses to Using Perl on Red Hat’s OpenShift Cloud

  1. Han Solo says:

    >We don’t understand why Red Hat won’t upgrade to a supported version of Perl.

    Simple. 5.10 is what is in RHEL6. And its all based on RHEL6.

    When they upgrade to RHEL7 based systems after it is GA, then 5.16 will be the default because that is what is in the RHEL7 release candidate now.

    • Han, I understand that RHEL6 has Perl 5.10 and that’s what OpenShift is based upon, but it does mean that OpenShift is useless for many developers unless they can figure out how to build their own catridges. That being said, RHEL Software Collections provides a modern version of Perl, but they haven’t released that for OpenShift (that I’m aware of).

      RHEL has long used older, out-of-date versions of various languages/tools, but they do that in the name of stability. However, when it gets to the point where they’re deliberately providing unsupported versions of major programming languages, that becomes problematic. Major bug or security hole frustrating you and you desperately need a patch? Too bad. That “Enterprise” OS is now a problem instead of a solution.

  2. I think we are rolling out the new SCL version either this sprint or next, so you won’t have to wait for the RHEL7 release. Watch for it. I will try to get a link to a trello card or something more concrete to give you a heads up.

    Thanks for not only responding to said author (who may bear a resemblance to me) but for porting the code sample AND writing such a great blog post. You coming to OSCON?

    • Hi Steven,

      You’re welcome :)

      I’m very much looking forward to the SCL release of newer versions of Perl. That’s going to be great news. How long are your sprints?

      Not only will I be at OSCON, I’m presenting twice. One presentation will be How to Fake a Database Design. I show how to (roughly) normalize a database, I give a real-world example, but I skip a lot of the jargon.

      The other talk is Testing with Test::Class::Moose. That’s aimed at a Perl audience and shows an advanced xUnit testing framework for Perl that includes built-in reporting, fine-grained customization and “out of the box” parallelization.

      Hope to see you at OSCON!

Comments are closed.