Creating Applications

OpenShift Online makes it easy to create new applications, either through a few clicks in the web console or a single RHC command. Using a simple Python application as an example, this section will show you how to create an application using the RHC Client Tools and what your options are when creating applications.

In This Section

This guide shows you how to spin up a plain Python application without any code dependencies.

Preliminary Steps

  • Signed up for an OpenShift account

  • Installed the RHC command line tools. While we could have used the web interface or the Eclipse plugin, we believe the command line give developers the full power of developing applications on OpenShift. If you would like to use the web interface instead, you can click here (login required).

Creating Your First Application

With your RHC setup complete, you are ready to create your first application. The following example will create a Python application. Before you make an application, please 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.

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 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.

When the command finishes executing you will have Apache HTTP server with mod_wsgi running in the cloud. It will have a public URL, which will have the form: 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.

You could have made the 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 later when we discuss autoscaling in depth.

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 give your gear more RAM. Please see the paid tier documentation to understand other reasons to move into the paid tier.

Finally, we could also use the --from-code option to point to a publicly accessible Git repository to serve as the template for our application. 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.

To delete OpenShift applications, use the command rhc app delete. This will trash all your resources in the application on the OpenShift servers and allow you to use the resources in a new application.

Go ahead and look at your web page (Figure 1). What you should see is the template page created for all OpenShift applications. This page is pretty generic. 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, DNS registered a URL, and made both a remote and local Git repository. With that little bit of typing you have a fully functional application development hosting environment.

Screenshot of the default Python application
Figure 1. A What your first application looks like!

While that was exciting and all, you can do much more with your application. Time to modify your application.

Autoscaling and Why You Should Use it by Default

OpenShift is the only PaaS on the market that provides autoscaling at the application tier. 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 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. Of course, OpenShift lets you set a minimun and maximum number of gears for application server use.

It is highly recommended that you make your applications scalable by default. There are several reasons for this:

  • Your application server, your database server, and any other server you put in your application will each go on their own gear and therefore not compete for disk, memory, or other resources. This will give you much better performance compared to non-scaling where they all run in the same gear.

  • It gives you more flexibility if you start to experience more load on your application. You can set the scaling limits for the application tier to accommodate the new traffic.

  • It will allow you to scale up manually if you know a big event is coming up and you want to warm up the servers beforehand.

  • There is no command to make a non-scalable application into a scalable application.

Premium Plan Advantages

Everything above can be carried out using the OpenShift Free Plan but there are strong reasons why you might want to use one of the premium plans as your application becomes more serious:

  1. Your application will be idled only after prolonged periods of no http or websocket requests flowing to it.

  2. You gain the ability to buy more gears, thereby allowing you to create more applications. With more gears you can also allow your application to scale to handle more traffic.

  3. You gain the ability to buy larger gears, which can be crucial for memory-hungry application servers.

  4. You gain the ability to purchase premium application servers for more than 3 gears or on larger gears, such as JBoss EAP.

  5. You gain the ability to get access to more disk space, beyond the 1GB that comes with the Free Plan.

  6. You can use your own SSL certificates with your custom domain names.

  7. Some of the premium plans provide the ability to open support tickets.