Table of Contents for

Getting Started with OpenShift

All modern programming languages have a “build” process; OpenShift takes advantage of this to build your application dependencies. At the time of this writing we are using the processes listed in Table 6-1 to pull in dependencies for external libraries.

We have tried to make the process as close to development on your local machine as possible. So, for example, with Python if you wanted to download the “default” PostgreSQL drivers (psycopg2) to your local machine you would use Pip:

$ pip install psycopg2

This would install the Psycopg2 drivers to a location where Python can see them on your local machine. The way to reproduce this functionality on OpenShift is to include the dependency in the appropriate “application metadata” file. When you include your dependencies in this file, OpenShift will notice the dependencies during the build process and then download the files and put them where your language runtime can see them. Table 6-2 presents a listing of all the files for a variety of languages.

Let’s go ahead and add Psycopg2 to our project so we can use the library to connect to our database of insults. Go into your local Git repository and edit the setup.py file. We already have a dependency declaration for Flask (see Modifying Application Code), and now we are going to add one for Psycopg2. Your install dependencies section should look like this now:

install_requires=['Flask==0.10.1', 'psycopg2==2.5.2'],

The first time you git push with this new dependency, the build will take longer because of the download and build of the new dependency. After that OpenShift will use the cached version. This is particularly noticeable for Java developers with Maven builds, since the default pom.xml requires the full JEE dependency.

When you do your git push, you should see something like the following in the output:

...
remote: Processing dependencies for Insult-App==1.0
remote: Searching for psycopg2==2.5.2
remote: Best match: psycopg2 2.5.2
remote: Processing psycopg2-2.5.2-py2.7-linux-x86_64.egg
...

These are the lines where the OpenShift build process is adding the Psycopg2 library to the virtual environment for your application.

For each programming language, there is a designated location in the Git repository where you can place your own binaries for your application and have the build pick them up (Table 6-3). For example, you would do this if you have a binary library that you use within your company that you do not want to put in a public repository or in the code base. This way you can reuse the library without exposing the code.

Placing your libraries in these locations means you can use your own libraries, ensure a certain version of a library is used, or include nonpublic libraries.

Some of these languages also have the ability to point to a library in a different Git repository or in other places “on disk.” For example, in your Ruby application you can specify the location to your Gem in your Gemfile.lock file. This is a much more flexible method than using the location specified earlier. The same holds with setup.py or requirements.txt for Python; your metadata file can point to a GitHub repository or other publicly accessible locations.

Now that we know how to pull in dependencies, let’s go ahead and modify our code to take advantage of the database. We are going to design the application so that our insult propagation crew can search out new insults, add them to the database, and have them appear without any code changes. We designed the database tables so we could pick from each adjective type and noun separately and add to each group separately.

We did such a nice job with the separation of concerns between our classes in our original application that we only have to modify insulter.py. We are going to replace the static lists of adjectives and nouns with calls to the database, but nothing else in the application has to change. Even within insulter.py we only have to modify one method. Hooray for clean code!

One quick note before we dig in: as much as we would like to believe Insult App will be hugely successful and allow us to retire early, this app will probably have only one or two users at a time (if we are lucky). Therefore, we are not going to add the overhead of having a connection pool for the database connections. Given that database connections take a relatively long time to establish, in any real production application you would want to use a connection pool for your database connections.

All right, on to the code!

import psycopg2
...

def get_cursor():
    #open a connection
    conn = psycopg2.connect(database=os.environ['OPENSHIFT_APP_NAME'],
                      user=os.environ['OPENSHIFT_POSTGRESQL_DB_USERNAME'],
                      password=os.environ['OPENSHIFT_POSTGRESQL_DB_PASSWORD'],
                      host=os.environ['OPENSHIFT_POSTGRESQL_DB_HOST'],
                      port=os.environ['OPENSHIFT_POSTGRESQL_DB_PORT'] )
    #get a cursor from the connection
    cursor = conn.cursor()
    return cursor

def close_cursor(cursor):
    conn = cursor.connection
    cursor.close()
    conn.close()

def get_word(cursor, table):
    sql = "select string from " + table + " offset random()*
     (select count(*) from " +  table + ") limit 1;"
    cursor.execute(sql)
    result = cursor.fetchone()
    return result[0]

def generate_insult():
    local_cursor = get_cursor()
    final_insult = get_word(local_cursor, "short_adjective") + " " +
     get_word(local_cursor, "long_adjective") + " " +
     get_word(local_cursor, "noun")
    close_cursor(local_cursor)
    return final_insult