How to deploy applications on Openshift

Many people look for a container orchestrator and choose Openshift for its features, security, performance, and you may be among them.

In this article, I will present you how to quickly deploy an application on Openshift.

There are many examples on the Internet on how to deploy applications on Openshift through the Web Console or with the CLI but how can you deploy by respecting good practices ?

Indeed, deploying applications using the Web Console or CLI is quite simple. But deploying hundreds or even thousands of applications, knowing the status of the deployments and their version - this is not the right method.
Just like the source code of applications, the actions you perform in Openshift must be stored and versioned in a SCM.
In Openshift, everything is object, and that’s what we store and version, in YAML or JSON format.

What I propose to you is to deploy a microservices voting application on an Openshift cluster using YAML files and oc CLI.

Voting application architecture


I will use CodeReady Containers (crc) for this example, which is a minimal OpenShift 4 cluster able to run on your local computer.

This could be an Openshift (version 3 or 4), OKD (version 3 or 4) or a Minishift.
At the moment, I use crc 4.6.15 and oc CLI 4.6.16.

Using git repositories allows us to keep a track of what has been done, to version all YAML files, as we can do for source code.
Using and understanding the oc CLI will make it possible to automate the creation and deployment of applications.

Deploy voting app

In this example, we will deploy a voting application, which is an Official Docker sample that I modified to be able to deploy it on Openshift, in three different ways.

Before starting, if you don’t know the basics of Openshift or Kubernetes, let me redirect you to the official documentation of the objects that will be used:

You can now clone the project from github.

First, follow this procedure to create and initialize an environment to deploy our application.

The last things you should know:

  • Deployments may take a few minutes, the cluster needs to pull images, to build images from Dockerfile or from Source to Image.
  • When your deployments are performed, you can access the result and vote application through the Openshift routes and you should see something like this:

First, we will deploy this example with container images, that can be built and stored in any registry.

This method is often used when you have already a toolchain that build images for you and you don’t want to change this operation.

If you want to build images and push them in a registry, you can do that as well. If you want to use images that I pushed for this article, you do not have to do anything.

Let’s deploy our application.

Voting app in Openshift

Before continue, check the application is working !

In a second step, we are going to deploy the same application but with some changes: use of Dockerfile in your Git repository. It’s Openshift that will take care of building our images.

Let’s update Openshift objects to try out this method and trigger container image building.

This method allows you to update your Dockerfile and source code at the same time in your SCM, you keep control over everything and it’s all versioned.

With the container images, you will need an external process to build images. Once it’s done, you have to deploy your new images by forcing an image pull in Openshift or pushing the image in the Openshift registry (to be able to use triggers).

With Dockerfile, everything is done in Openshift: you push the code, Openshift builds the image, push it in the registry and can deploy it automatically thanks to “triggers”.

To go further, you can set webhooks in your Git repositories to be able to trigger Openshift builds automatically.
That becomes an application deployment in one action: push the source code !

Now, what if you don’t want to worry about a Dockerfile and want to stay focused on your source code? This is the last method we are going to implement.

Let’s update Openshift objects again and trigger new builds.

This method is pretty similar to the previous one, the difference is that you’re using a builder container image instead of Dockerfile. You don’t have to worry about how to create and build your container images, stay focus on your source code and Openshift will take care of the rest for you.

To deploy application on Openshift, I slightly reworked the source code of the application and I also reworked the Dockerfile compared to the original.
The first thing is that applications must not expose ports below 1024 and can’t run as root user.


In this article, we have learned how to deploy applications on Openshift in several ways :

  • With container image already built
  • With Dockerfile from Git repository
  • With Source to Image (S2I)

There are several ways to migrate applications, and there is not a best way to do that, it depends on how you want to manage your application lifecycle.

Do you already have tools that build images and store them, and you don’t want to migrate everything to Openshift? Then deploy your applications using your container images.

Do you want to deploy applications from their source code? If you want to take care of a Dockerfile, choose to build your application with it. If not, Source to Image allows you to deploy already secured container images in your cluster.

There are other solutions you can implement, a combination of Dockerfile and S2I for example, or launching CICD pipelines with other tools and so on.

Thanks for reading.