Configuring assets in your OpenShift namespace usually involves a lot of clicking and typing in the GUI. For some, it involves juggling massive yaml files containing the same information, but machine readable.
Both involve quite a bit of work and a good understanding of OpenShift and its inner workings to do the right things in the right order.
Luckily, there is a CLI tool to aid in this: the OpenShift Command Line Interface, a.k.a. OpenShift CLI, or oc for short.
It can be found here, and is freely available with support from Red Hat.
But, as with any tool, it also has its own complexity and quirks.
Below, I’ll discuss two commons situations and how oc can help you get started quickly!
I’m assuming a successfully installed oc tool and a valid (e.g. logged in) session to your OpenShift instance for the next part of this blog.
Create a runnable image from source (dockerfile)
Let’s assume you have created the perfect Dockerfile to build an image and ultimately a container of your application.
Perhaps it is a base image for future Java-based application development? Or even an extended openshift-jenkins-slave image? Use your imagination here!
Fact is: everything that’s needed to build the Docker Image on your machine is also in a git repository and is reachable by OpenShift. Great!
OpenShift is very much capable to build your Image, and store it in its internal Docker Repository in an ImageStream, but some steps have to be taken.
Source secrets
OpenShift will have to check out the code, and for that it requires a username / password combination. This needs to be set up at your VCS (here: GitLab), and the combination has to be registered in OpenShift. This is done via a Secret which can later be referred to as a Source Secret.
To create a secret in OpenShift, the first of our oneliners is introduced:
oc create secret generic {name-of-your-secret} \
--type=kubernetes.io/basic-auth \
--from-literal={username}={password} \
--namespace {namespace}
Before you contact me about this: yes. I know it’s supposed to be a oneliner, and it is split into multiple lines here; technically making it not a oneliner anymore. It’s a oneliner at heart! Just spread out to make it more legible. ????
Actual content
Having OpenShift being able to read stuff from a git repository is nice and all but worthless until you actually read something from a git repository!
Luckily, OpenShift has a nice on-size-fits-all command to read from an repository and create *all* necessary OpenShift / Kubernetes objects required to actually run the artifact on the platform. This is the command oc new-app and it can use several strategies (--strategy) to accomplish the goal.
Here, we use the docker strategy to take a Docker file and build it into an Image which is ultimately run as Deployment on OpenShift and can be exposed through a Route on the platform to external entities.
The trick is to just point to your repository, provide the source secret and give everything an appropriate name.
oc new-app https://gitlab.local/{group}/{repository}.git \
--strategy=docker \
--source-secret={name-of-your-secret} \
--name={name-of-your-build} \
--namespace {namespace}
This will just create a build and start the build, but not deploy it into your namespace and make it accessible:
oc new-build https://gitlab.local/{group}/{repository}.git \
--strategy=docker \
--source-secret={name-of-your-secret} \
--name={name-of-your-build} \
--namespace {namespace}
Troubleshooting
Every once in a while you probably want to know why your application is not behaving as it should in a namespace. The oc binary can help you here as well!
Reading logs
Logs for pods and/or containers can be veiwed from the OpenShift GUI, but who needs a GUI when there’s a perfectly fine CLI?
Logs from pods can be obtained by using the pod-name:
oc logs {name-of-your-pod} \
--follow=true \
--namespace {namespace}
Or just one container in a pod:
oc logs {name-of-your-pod} \
--container {name-of-the-container-in-the-pod} \
--namespace {namespace}
You can also select pods based on a label:
oc logs --selector {label}={value} \
--namespace {namespace}
Debugging pods
When a container or pods gets stuck in a CrashLoopBackoff state, this will not fix itself. Usually, there’s something wrong with the configuration of the pod. But when the thing won’t start, it is hard to check what’s wrong, right?
A debug instance of the pod will help!
This instance is run without the usual docker ENTRYPOINT but instead /bin/sh is swapped in as a starting command and any liveness or readiness checks are disabled. This gives you a running pod without the actual program started but with all other things equal to a regular start.
The CLI will drop you right into a shell on the pod.
oc debug {name-of-your-pod} \
--namespace {namespace}
More?
There are probably loads more oneliners for your OpenShift Client needs. Let me know if you want me to find some more on a particular subject!
