Demo Example Voting Application

Hello — this guide walks through deploying the multi-tier example voting application on an OpenShift cluster. The app is forked from the canonical example voting app on GitHub with a few small changes to add basic authentication between services. We will deploy the microservices in the correct order so dependencies are available when needed:

Redis (required by the voting front-end)
Voting front-end (Python)
PostgreSQL (results DB) and the results app (Node.js)
Worker (processes votes) — built with Docker

Create a new OpenShift project/namespace (this guide uses voting-application) and follow the sections below.

Before you begin: ensure you have cluster access and permissions to create projects, import templates, and start builds. You can use the OpenShift web console or the oc CLI. For reference, see the OpenShift documentation.

Overview of repository and application design

The application source is organized into service-specific context directories in the repository. The primary services:

Service	Language/Runtime	Context Dir	Default Port
voting front-end	Python (Flask)	`/vote`	80 (via route)
results app	Node.js (Express + socket.io)	`/result`	4000 (set `PORT=8080` for OpenShift)
worker	Java (jar)	`/worker`	N/A (background process)
redis	Redis service/template	n/a	6379
db	PostgreSQL service/template	n/a	5432

Design diagram (microservices and how they interact):

A presentation slide titled "Design" showing a simple microservices diagram with colored boxes. The boxes are labeled voting-app (Python), result-app (Node.js), redis, db (Postgres), and a worker service.

Redis template and adding it to the Catalog

If a required service (like Redis) is not already visible in the Service Catalog, you can import an existing template into your project catalog. The OpenShift Origin examples repository contains database templates, including Redis. Search the repository for database examples and pick the Redis template — copy the JSON/YAML and import it into the web console using Import YAML/JSON. When creating the template from YAML, choose Save Template to add it to your catalog so users can instantiate it on demand.

A screenshot of a GitHub repository page showing the origin/examples/db-templates directory with a list of JSON template files (mariadb, mongodb, mysql, postgresql, redis) and commit info. The lower part shows a README titled "OpenShift 3 Database Examples."

The Redis template includes parameter generation for a Redis password. Example (trimmed to the Redis password parameter):

[
  {
    "description": "Password for the Redis connection user.",
    "displayName": "Redis Connection Password",
    "from": "[a-zA-Z0-9]{16}",
    "generate": "expression",
    "name": "REDIS_PASSWORD",
    "required": true
  },
  {
    "description": "Version of Redis image to be used (3.2 or latest).",
    "displayName": "Version of Redis Image",
    "name": "REDIS_VERSION",
    "required": true,
    "value": "3.2"
  }
]

After saving the template and refreshing the Catalog, you should see a Redis catalog item ready to deploy.

Deploying Redis from the Catalog

Deploy the Redis (Ephemeral) catalog item. Leave defaults, but provide a Redis password — remember this password, you will set the same value in the voting front-end environment variables.

A screenshot of the OpenShift web console showing a "Redis (Ephemeral)" configuration dialog with fields for Namespace, Database Service Name, Redis Connection Password and Version. The modal includes navigation steps (Information, Configuration, Results) and Cancel/Back/Create buttons.

Click Create to deploy Redis. The template prints the connection info when creation completes. Example output:

The following service(s) have been created in your project: redis.

Password: redis_password

Connection URL: redis://redis:6379/

For more information about using this template, including OpenShift considerations, see https://github.com/sclorg/redis-container/blob/master/3.2.

Take note of the service name (commonly redis), password, and connection URL — the front-end and worker services will use these values to connect.

Deploy the voting front-end (Python)

The voting UI lives under the vote directory. In the OpenShift web console choose “Add > From Git” (or create an application) and use Advanced Options to set:

Git repository URL: the example voting app repo
Context directory: /vote
Application name: e.g. vote

OpenShift will create a BuildConfig and DeploymentConfig and start an S2I build for the Python app. Repository view of the vote app (for reference):

A GitHub repository page for an "example-voting-app" open in a browser. The file list shows folders (static/stylesheets, templates) and files like Dockerfile, app.py, and requirements.txt along with branch and commit info.

Monitor the build in the Overview page. Example build push output (truncated):

Pushing image 172.30.1.1:5000/voting-application/vote:latest ...
Pushed 0/10 layers, 1% complete
Pushed 3/10 layers, 31% complete
Pushed 6/10 layers, 65% complete
Pushed 9/10 layers, 91% complete
Push successful

Configure the Redis password in the front-end environment

If the voting action fails with an authentication error, the front-end typically lacks the Redis password. The code expects the Redis password in the REDIS_PASSWORD environment variable:

from flask import Flask, render_template, request, make_response, g
from redis import Redis
import os
import socket
import random
import json

option_a = os.getenv('OPTION_A', "Cats")
option_b = os.getenv('OPTION_B', "Dogs")
redis_password = os.getenv('REDIS_PASSWORD', "")

hostname = socket.gethostname()

app = Flask(__name__)

def get_redis():
    if not hasattr(g, 'redis'):
        g.redis = Redis(host='redis', db=0, password=redis_password, socket_timeout=5)
    return g.redis

@app.route('/', methods=['POST','GET'])
def hello():
    voter_id = request.cookies.get('voter_id')
    ...

Add REDIS_PASSWORD to the DeploymentConfig/Deployment environment for the vote container and set it to the same password used when creating Redis. After updating the environment, redeploy the front-end. Once the environment is set correctly, casting votes should succeed.

A screenshot of the OpenShift Origin web console showing the "Example Voting Application" deployments page on the Environment tab for a container named "vote." The form displays an environment variable entry for REDIS_PASSWORD with a blank Value field and options to add values from a ConfigMap/Secret.

Common Redis connection error (example)

Traceback (most recent call last):
  File "/opt/app-root/lib/python3.6/site-packages/flask/app.py", line 2309, in __call__
    return self.wsgi_app(environ, start_response)
  ...
  File "/opt/app-root/src/app.py", line 32, in hello
    redis.rpush('votes', data)
  File "/opt/app-root/lib/python3.6/site-packages/redis/client.py", line 1388, in rpush
    return self.execute_command('RPUSH', name, *values)
  File "/opt/app-root/lib/python3.6/site-packages/redis/client.py", line 667, in execute_command
    connection.send_command(*args)
redis.exceptions.ResponseError: invalid password

Deploy PostgreSQL for the results app

The results application requires PostgreSQL. The DB template is normally available in the Catalog; deploy it and make sure the resulting service name matches what the result app expects (commonly db). Provide the database name, username, and password when deploying. For production use, store credentials in Kubernetes/OpenShift Secrets and inject them into pods; for this demo environment variables are used for simplicity.

For production deployments, use Secrets and ConfigMaps to manage credentials and configuration. Avoid placing plaintext credentials directly in Deployment/Pod environment variables.

A screenshot of the OpenShift Origin web console showing a PostgreSQL configuration dialog (step 2 of 3) with fields like Memory Limit, Namespace and Database Service Name. The left sidebar shows project navigation and the right side displays catalog items (Django, Nginx, Ruby, etc.).

Deploy the results application (Node.js)

The results app is implemented in Node.js and lives under the /result context directory. Add a Node.js application via Advanced Options:

Git repository: example voting repo
Context directory: /result
Application name: e.g. result

The app listens on port 4000 by default (PORT environment variable can override it). The socket and port configuration in the app:

var express = require('express'),
    async = require('async'),
    pg = require("pg"),
    cookieParser = require('cookie-parser'),
    bodyParser = require('body-parser'),
    methodOverride = require('method-override'),
    app = express(),
    server = require('http').Server(app),
    io = require('socket.io')(server);

io.set('transports', ['polling']);

var port = process.env.PORT || 4000;

io.sockets.on('connection', function (socket) {
    socket.emit('message', { text : 'Welcome!' });

    socket.on('subscribe', function (data) {
        socket.join(data.channel);
    });
});

Set an environment variable PORT=8080 so OpenShift routes the app on port 8080 inside the container. Create and monitor the build/deployment in the Overview page and open the route to view real-time results. If votes appear missing after you submit them (for example, counts remain 50-50), that indicates the worker is not processing queued votes.

Deploy the worker using a Docker build

The worker consumes the votes queue from Redis and persists counts into PostgreSQL. For the worker we use a Docker build strategy (Dockerfile-based) rather than S2I. Steps:

Create an app in the console using the /worker context directory (this generates a BuildConfig for S2I by default).
Edit the BuildConfig YAML and change:
- strategy from Source to Docker
- Remove the from (builder image) field so the build uses the Dockerfile in the repo
Save the BuildConfig and trigger a build (oc start-build worker -n voting-application).

Example BuildConfig summary before changing (informational):

Build Strategy: Source
Source Repo: https://github.com/mmumshad/example-voting-app.git
Source Ref: master
Source Context Dir: /worker
Builder Image: openshift/httpd:2.4
Output To: voting-application/worker:latest
Run Policy: Serial

Manual (CLI): oc start-build worker -n voting-application

After switching to Docker and starting the build, the Docker build output will push the built image to the internal registry:

Step 9 : CMD java -jar target/worker-jar-with-dependencies.jar
---> Using cache
Successfully built a818f483a745

Pushing image 172.30.1.1:5000/voting-application/worker:latest ...
Pushed 0/10 layers, 9% complete
Pushed 3/10 layers, 33% complete
Pushed 6/10 layers, 65% complete
Pushed 9/10 layers, 91% complete
Push successful

After deployment, check the worker logs to confirm it’s connecting to Redis and the DB and processing votes:

Connected to redis
Connected to db
Watching vote queue
Processing vote for 'a' by 'a44ff790cd088d2'
Processing vote for 'b' by 'a44ff790cd088d2'
Processing vote for 'a' by 'a44ff790cd088d2'
Processing vote for 'b' by 'a44ff790cd088d2'

When the worker is running, votes pushed to Redis by the front-end are consumed and persisted to PostgreSQL, and the results app will update in real time.

Application design recap

The end-to-end system includes:

voting front-end (Python) — pushes votes into Redis
redis — ephemeral queue for votes
worker (Docker-built) — consumes Redis queue and writes to PostgreSQL
db (PostgreSQL) — persistent store for results
result-app (Node.js) — reads results from PostgreSQL and broadcasts via socket.io

Troubleshooting tips

Invalid password errors in Redis logs indicate mismatched REDIS_PASSWORD values between the Redis instance and the front-end/worker environment.
If results are not updating, confirm the worker pod is running and check its logs for connectivity errors to Redis or PostgreSQL.
For production, store secrets in Secrets and use restricted RBAC rules.

Conclusion

You have deployed a multi-tier voting application on OpenShift: imported templates into the Catalog, deployed Redis, added the Python voting front-end, provisioned PostgreSQL and the Node.js results app, and built/deployed a Docker-based worker. You also learned how to add environment variables, switch build strategies (S2I -> Docker), and validate connections via logs.

Introduction

Pre-Requisite - Docker and Kubernetes

Getting Started with OpenShift

OpenShift Concepts - Projects and Users

Concepts - Builds and Deployments

Networks, Services, Routes and Scaling

Storage, Templates and Catalog

Conclusion and APPENDIX

Demo Example Voting Application

Overview of repository and application design

Configure the Redis password in the front-end environment

Application design recap

Troubleshooting tips

Conclusion

Further reading and references

Watch Video

​Overview of repository and application design

​Configure the Redis password in the front-end environment

​Application design recap

​Troubleshooting tips

​Conclusion

​Further reading and references

Watch Video

Overview of repository and application design

Configure the Redis password in the front-end environment

Application design recap

Troubleshooting tips

Conclusion

Further reading and references