Octobox is for sure one of my favourite tools in my GitHub centred developer workflow. It is incredible for GitHub notification management which allows me to ignore all the hundreds of GitHub notification emails I get daily.

Octobox is a Ruby-on-Rails application and can be used as SaaS at octobox.io or installed and used separately. Running Octobox in an own account is especially appealing for privacy reasons and for advanced features which are not enabled in the hosted version (like periodic background fetching or more information per notification).

This post shows how Octobox can be ported to the free “starter” tier of OpenShift Online.

Application setup

An Octobox installation consists of three parts:

• Octobox itself, a Rails application
• Redis as an ephemeral cache, used as a session store
• Postgresql as the backend database

Naturally, this would lead to three services. However, as I’m not striving for an HA setup and the sake of simplicity, I decided to combine Octobox and Redis in a single pod. Since a combined lifecycle for Octobox and Redis is a reasonable, fair choice, this reduces the number of OpenShift resource objects considerably.

As persistent store for Postgres, we use a plain PersistentVolume which is good enough for our low-footprint database requirements.

Docker Images

To get an application onto OpenShift, you first need to package all parts of your application into Docker images which eventually become container during runtime.

There are some restrictions for Docker images to be usable on OpenShift. The most important one is that all containers run under a random UID, which is part of the Unix group root. This restriction has the consequence that all directories and files to which the application process want to write should belong to group root and must be group writable.

Octobox already is distributed as a Docker image and has recently be [updated][octobox-dockerfile-chgrp] to be OpenShift compatible. The Postgres image is directly picked up from an OpenShift provided ImageStream, so there is no issue at all. The Redis Imagee is also already prepared for OpenShift However, when using Redis from this image in an ephemeral mode (so not using persistence) there is a subtle issue which prevents starting the Pod: As the Dockerfile declares a VOLUME and even though in our setup we don’t need it, we have to declare a volume in the Pod definition anyway. Otherwise, you end up with a cryptic error message in the OpenShift console (like can't create volume ...). An emptyDir volume as perfectly good enough for this.

Template

To install the application an OpenShift Template has been created. It contains the following objects

• DeploymentConfigs for “Octobox with Redis” and “Postgres”
• Services for Octobox and Postgres
• PersistentVolumeClaim for Postgres

A route for accessing the app is created later on the OpenShift console. Please refer to these installation instructions for more details how to use this templats.

OpenShift Online Starter

OpenShift Online Starter is the free tier of OpenShift online which is very useful for learning OpenShift concept and get one’s feet wet. However, it has some quite restrictive resource limitations:

• 1 GB Memory
• 1 GB Storage

This budget is good enough for small applications like Octobox, but if you need more horsepower than you can easily upgrade to OpenShift Online Pro.

The challenge is now to distribute the three parts (Octobox, Postgres, Redis) over these 1 GB. As Octobox as rails application is quite a memory hog, we want to dedicate as much memory as possible to it. For Postgres, we do not need much Memory at all, so 50 to 100 MB is good enough. The same for Redis as an initial guess. We can always tune this later if we found out that our initial guess a wrong.

Ok, let’s start with:

• 875 MB Octobox
• 50 MB Redis
• 75 MB Postgres

When trying out these limits, I quickly found out that this doesn’t work. The reason is that OpenShift Online has a minimum size for a container which is 100 MB. Also, you can’t choose requests and limits freely, but there is a fixed ratio of 50% to calculate the request from a given limit (the request specified is always ignored). This fact not only means that you get a Burstable QoS class, but also that you have to specify 200 MB as limit to get at least 100 MB request to exceed the required minimum.

So we end up with:

• 600 MB Octobox
• 200 MB Redis
• 200 MB Postgres

Apparently, this is not optimal, but that’s how it works for OpenShift Online Starter tier (and probably also the Pro Tier). For other OpenShift cluster it, of course, depends on the setup of this specific cluster. We could put Redis and Octobox in the same container, and start two processes in the container. This change would free up another 150 MB for Octobox but is ugly design. So we won’t do it ;-)

tl;dr

Porting an application to OpenShift is not difficult. Especially the free OpenShift Online Starter is very appealing for such experiments. The challenges are mostly around creating proper Docker images and getting resource limits right. As a result, you get a decent running and managed installation.

For the full installation instructions, please refer to the OpenShift specific Octobox installation instructions.