This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information

OpenShift Deployment

OpenShift is a PaaS product from Red Hat.
Read further details at Wikipedia or the product site.

It's of interest to us because it's easy to use, supports deployment of pre-created war files and it offers an application server (e.g. Tomcat, JBoss) and a database (MySQL, PostgreSQL) for your applications. OpenShift also has Vert.x as runtime platform if you won't use an application server. The configuration is super easy and your server is ready in around 5 minutes.

The access to your server is protected and you should use a specific client tool from RedHat for advanced configuration or an SSH client like putty.

The PaaS service is so nice because it's the perfect deployment platform for JVx applications. There's a free service for simple tests and maybe smaller applications because there are some limits for memory usage, CPU, and number of applications.

We made some tests with OpenShift and the result was as expected: Our applications did work without problems. Sure, the whole deployment procedure could be more end-user friendly but it wasn't designed for end-users without technical know-how, I guess. It's good enough for software developers or admins.

Our test

We created a new JVx application with VisionX (because it creates the database, has a GUI builder and creates the war file for us) and the application should run with VaadinUI on OpenShift. We didn't have any experience with OpenShift, but with other PaaS products, e.g. Heroku, Cloudbees, Jelastic, AWS.

First steps:

  1. Registering an account (what else :) )
  2. Creating a first application
  3. Cartridge: Tomcat 7 (JBoss EWS 2.0)
  4. Setting application name and domain
  5. Adding MySQL 5.5 cartridge

Above steps were enough to run our OpenShift service(s).

Next was accessing the server via SSH client because we didn't install the RedHat client tool (We won't use client tools for cloud services - why the hell). Sure, we had to use another client tool for accessing the server via SSH, but it was working without installation: PuTTY (still strange). A nice web UI would be great... just my thoughts. We found a Java client but didn't test it.

So, what we did:

  1. Creating private/public RSA keys with PuTTYgen
  2. Configuring OpenShift (used the key from PuTTYgen TextArea because OpenShift didn't like other formats)
  3. Testing connection

    Username was displayed in Application settings under SSH Code, e.g. ssh://<username>
    Used the private key file for putty as key (Key authentication, without password)

Next task was, configuring the access to the database because SSH access was already working. It wasn't possible to access the database without tunnel - means, no direct (Internet) access from your client. This wasn't a real problem and PuTTY had support for port tunneling. Simply detected the IP address of the MySQL server. The hostname was set as environment variable and the command export displayed all variables. The variable OPENSHIFT_MYSQL_DB_HOST had all information and our tunnel was working. There's also a property for the MySQL Port but 3306 is default.

What was next?


This wasn't trivial because the platform expected source code and a maven project for automatic deployment. Wrong for us. But there's an official documentation for manual war deployment.

Short summary of steps

  1. GIT clone
  2. Delete src folder and pom.xml
  3. GIT commit & push
  4. Copy WAR file into webapps folder
  5. GIT commit & push

You don't need git on your client, it's available in your terminal. But... as a developer, git is one of those standard tools...
It's also possible to upload the WAR file via SCP or SFTP...


Not really because our application was deployed without problems but it didn't work because the JDBC URL was wrong. We set the MySQL servername to localhost because of the tunnel!

Here's the original config.xml:

<?xml version="1.0" encoding="UTF-8"?>

    <!-- GLOBAL | DATASOURCE | OFF -->
    <property name="client.metadata_cacherole">OFF</property>
    <db name="default">

JVx has a nice feature which allows environment dependent settings and VisionX sets the environment automatically to prod. So, we simply changed the datasource to:

    <db name="default">

VisionX sets the environment to prod, if it creates a WAR file:


Sure, the solution isn't perfect because the MySQL hostname should be read from the environment variable.
Would be better:


But JVx doesn't support this syntax (right now) -> Feature Request.

Done. Really done.

The application works fine (Login as admin with password admin).

Here's a screenshot, for the case that our OpenShift service isn't running:

OpenShift ERP with JVx and VaadinUI

OpenShift ERP with JVx and VaadinUI