Table of Contents for

Getting Started with OpenShift

Before you get started, you’ll need to do two things:

In the next section, we will explain the rhc setup command.

Once you have installed the client tools, you need to configure them to work with your OpenShift Online account. To do this, use the following command:

$ rhc setup

Executing this command sets up your command-line tools to talk to the OpenShift servers. When you run this command, the following things will happen:

With our RHC setup complete, we are ready to create our first application. For the purposes of this book, we are going to create a Python application. In actuality you could use any of the supported web cartridges to make an application. The list of cartridges grows pretty rapidly, so if you want to see the full list of cartridges on OpenShift, please execute the following command:

$ rhc cartridge list

You can also create your own cartridges. We are not going to cover how to create a cartridge in this book, since we consider that topic to be an advanced use case. Besides, if we talked about it here, how could you write about it when you write your OpenShift book? We cover much more about cartridges in Finding Cartridges and QuickStarts.

Before you make an application, use the command line to create or navigate into the directory where you would like your application code to be created. At the end of application creation, the command-line tools will clone the application’s Git repository to your local machine in the same directory where you executed the command.

Let’s create an app!

Here’s the syntax for creating an OpenShift application:

$ rhc app create app_name web_language

or:

rhc app create app_name web_language other cartridges

And here is how we use this command to create an application named insultapp using the Python 2.7 cartridge:

[me@localhost ~]$ rhc app create insultapp python-2.7
Application Options
--------------------
Domain:     osbeginnerbook
Cartridges: python-2.7
Gear Size:  default
Scaling:    no

Creating application 'insultapp' ... done

Waiting for your DNS name to be available ... done

Cloning into 'insultapp'...
The authenticity of host 'insultapp-osbeginnerbook.rhcloud.com (19.66.2.6)'
can't be established.
RSA key fingerprint is 4e:65:76:72:47:6f:6e:6e:61:47:69:76:65:55:55:70.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'insultapp-osbeginnerbook.rhcloud.com' (RSA) to the
list of known hosts.

Your application 'insultapp' is now available.

  URL:        http://insultapp-osbeginnerbook.rhcloud.com/
  SSH to:     6e7672676e61676976757570@insultapp-osbeginnerbook.rhcloud.com
  Git remote: ssh://6e7672676e61676976757570@insultapp-osbeginnerbook.
  rhcloud.com/~/git/insultapp.git/
  Cloned to:  /home/me/insultapp

Run 'rhc show-app insultapp' for more details about your app.

That’s it! When the command finishes executing you will have an Apache HTTP server with mod_wsgi running in the cloud. It will have a public URL, which will have the form http://insultapp-<namespace>.rhcloud.com. It will also have a private Git repository that has been cloned to your local machine, in a directory with the same name as your application.

We could have made our app a scalable application (meaning each cartridge goes on its own gear) by passing in the -s flag. You would do this if you wanted to make sure your cartridges were not sharing resources or you wanted to enable the application server tier to scale (manually or automatically) from the database tier. We will discuss this further in the next section.

We could also pass in the -g flag to use gear sizes other than the default (small) size. On OpenShift Online’s free tier you only have access to the small gears, but if you move into the paid tiers you can get a medium or large gear, which has more RAM. Please see Reasons to Move to the Paid Tier to understand other reasons to move into the paid tier.

Finally, we could use the --from-code option to point to a publicly accessible Git repository to serve as the template for our application. We could have done that in this example, but we are going to build the example application by hand instead. One caveat with this flag is that when OpenShift tries to create the gear, the application has to download and build the Git repository within a particular time period. If the rhc create command times out before the build and deploy occurs, then OpenShift will roll back the entire application and you will be left with nothing except the bitter taste of disappointment. Use this feature with caution for now.

Go ahead and look at your web page. What you should see is the template page created for all OpenShift applications (Figure 2-1). This page is pretty generic. In the next chapter, we will modify the application and deploy the code changes. Take a step back and marvel at what you just did. With one command you spun up Apache with mod_wsgi, allocated disk space, configured logging, configured Linux permissions, registered an IP address with a DNS server, and made both a remote and a local Git repository. With that little bit of typing you have a fully functional application development hosting environment. This is the magic of OpenShift, and your development process may never be the same again.

Figure 2-1. What your first application looks like

OpenShift is the only PaaS on the market that provides autoscaling at the application tier. We have not used it here for the sake of simplicity, but if we were going to run an app in the “real world,” we would make it scalable. When you make an application scalable, a software-based load balancer called HAProxy will be added to the same gear as the application server. All web traffic to the application will then be routed through HAProxy. Currently, if the number of active connections goes above 16—whether they are regular HTTP or WebSocket connections—HAProxy will trigger the creation of another application gear. OpenShift will spin up another app server gear, rsync the code over to the new gear, plug the gear into HAProxy, and then start using it to serve connections. If the connections later drop back below the threshold for long enough for it not to be considered random noise, HAProxy will trigger the draining of connections and OpenShift will spin down the gear.

All of this happens without any human intervention, so you do not have to wake up in the middle of the night or take time out from sailing around the world on your yacht (wouldn’t that be nice). Of course, OpenShift lets you set a maximum number of gears for application server use so you are not surprised by some large bill at the end of the month, thereby ending your yacht trip.

As we have taught more and more classes and seen more and more people using OpenShift, we have arrived at the conclusion that almost all apps should be created as scalable applications. There are several reasons for this:

You are given enough resources in the free tier to make your application scalable, so there is really no reason why you shouldn’t do this by default.

Everything we do in this book can be carried out using the free tier of OpenShift, but there are strong reasons why you might want to move into one of the paid tiers as your application becomes more serious. We will call out some of the benefits as we discuss topics in the following chapters, such as the ability to use your own SSL certificates. However, for the sake of gathering them in one place, we have included a short list here:

There is certainly no requirement to use the paid tier, but there are numerous reasons you may find yourself wanting to take advantage of what it has to offer.