DEV Community

Livio Ribeiro
Livio Ribeiro

Posted on • Updated on

My journey through Openshift

Recently I started working with Openshift since the company I work for adopted it. It will be quite an interesting journey because I will have to adapt our services that currently run on JBoss and Tomcat to run on containers.

But first, what exactly is Openshift?

From my understanding, it is a distribution of Kubernetes focused on providing an easier way to migrate, deploy and manage your applications on a containerized environment. It hides some of the complexities of Kubernetes while providing some nice features like its dashboard and the source-to-image (S2I) strategy.

Openshift is maintained by RedHat.

The S2I is very interesting: it combines a specially built docker image with your application's source code and build another docker image ready to be deployed. Each S2I image is specialized in building and deploying a different technology stack. For example, the JBoss S2I image will look for a pom.xml in the sources, run mvn package, copy the generated artifact to the deployments directory and, when run, will configure the datasource using environment variables. The Tomcat S2I image works similarly. RedHat provides images for Java, Python, Ruby, Nodejs and others.

You can also deploy an image from docker hub.

Getting started

To get started with Openshift, you can download the minishift tool, which will start a virtual machine running an instance of Openshift.

But before we begin, we should tweak the virtual machine a little bit:

minishift config set vm-driver virtualbox
minishift config set memory 8G
minishift config set cpus 4
minishift config set disk-size 100G
Enter fullscreen mode Exit fullscreen mode

These commands will tell minishift to:

  • use virtualbox instead of KVM/Hyper-V/xhyve (you can still use those)
  • set the memory to 8GB (but 4GB will do too)
  • set the number of cpus to 4, so we can run a few more containers
  • use a disk size of 100GB, so we do not run out of storage

You can use lower values for memory and cpus, but it will be very limited (and sometimes openshift may freeze).

To start minishift we can run:

minishift start
Enter fullscreen mode Exit fullscreen mode

When the machine is ready, we can run:

eval $(minishift oc-env)
Enter fullscreen mode Exit fullscreen mode

to have oc (the openshift command line tool) in our path.

Before we can interact with Openshift, we need to login (use admin/admin as credencials):

oc login
Enter fullscreen mode Exit fullscreen mode

With everything running, it is time to deploy an application. For this example we will deploy Gitea, a git repository manager forked from Gogs.

But first, we need to create a project (which is effectively a kubernetes namespace):

oc new-project scm --display-name "Source Control Management"
Enter fullscreen mode Exit fullscreen mode

Now we tell openshift to create an "app" from Gitea docker image:

oc new-app gitea/gitea:1.5
Enter fullscreen mode Exit fullscreen mode

which will end up creating:

To expose the service to the external world, we can create a Route

oc expose svc/gitea \
    --name gitea-http \
    --port 3000-tcp
Enter fullscreen mode Exit fullscreen mode

The 3000-tcp is the name of the port on the service.

With the Route created, Gitea will now be available at

You can also expose Gitea's ssh endpoint

oc expose svc/gitea \
    --name gitea-ssh \
    --port 22-tcp \
Enter fullscreen mode Exit fullscreen mode

Gitea is working, but its data will be lost on container restart, so we need a persistent volume to hold that data:

# remove automatically create volume
oc volume dc/gitea --remove --name gitea-volume-1

oc volume dc/gitea --add \
    --name 'gitea-volume-data' \
    --type 'pvc' \
    --mount-path '/data/' \
    --claim-name 'gitea-data' \
    --claim-size '1G'
Enter fullscreen mode Exit fullscreen mode

One thing that is missing is configuration. Fortunately, Gitea can be configured using environment variables. So now we will create a ConfigMap to hold the environment:

oc create configmap gitea-config \
    --from-literal APP_NAME="My Gitea Instance" \
    --from-literal RUN_MODE=prod \
    --from-literal \
    --from-literal ROOT_URL= \
    --from-literal DB_TYPE=sqlite3 \
    --from-literal INSTALL_LOCK=true
Enter fullscreen mode Exit fullscreen mode

Now add the environment to the DeploymentConfig:

oc set env --from configmap/gitea-config dc/gitea
Enter fullscreen mode Exit fullscreen mode

If you access our Gitea instance right now, you will notice that our configuration was not applied! This happened because Gitea already have a configuration file in the volume we created. To solve this, we need to add another volume, an EmptyDir volume, so Gitea can rebuild the configuration using the environment variables we set:

oc volume dc/gitea --add \
    --name 'gitea-volume-config' \
    --type 'emptyDir' \
    --mount-path '/data/gitea/conf'
Enter fullscreen mode Exit fullscreen mode

It may take a bit longer for the application to be ready since it is creating the database tables, but then you will see that our settings were applied.

Now we just need to setup probes to monitor application health:

oc set probe dc/gitea --liveness \
    --failure-threshold 3 \
    --initial-delay-seconds 5 \
    -- echo ok

oc set probe dc/gitea --readiness \
    --failure-threshold 3 \
    --initial-delay-seconds 10 \
Enter fullscreen mode Exit fullscreen mode

The readiness probe is particularly useful during rollouts so openshift can tell if it can safely remove the old container and redirect requests to the new one.


I made a Template to make easier to deploy Gitea. It is available here.

Gitea has more settings than the ones configurable through the environment variables, but right now setting the config file (app.ini) from a configmap does not work very well since Gitea tries to write to the file and fails because it is readonly. However, there is a pull request to fix that.

Top comments (1)

simbo1905 profile image
Simon Massey

There are instructions on running Gitea 1.9.2 on minishift over at