Monocular on OpenShift

Adnan Abdulhussein
Bitnami Perspectives
4 min readJun 7, 2017

Monocular, is an open source search and discovery front-end for Helm Chart repositories. You can see it in action over at https://kubeapps.com, but running it in your own cluster gives you a neat way to create and manage Helm Chart installations inside your cluster. Let’s take a look at running it on an OpenShift cluster.

Helm on OpenShift

Before we install Monocular, we need to install Helm on OpenShift. More specifically, we need to run Helm’s server-side component, Tiller. This runs in the kube-system namespace and uses the Kubernetes API to create and manage the resources defined by charts.

In RBAC enabled Kubernetes clusters, you need to make sure you give Tiller the right roles to manage your resources. Whilst more restrictive permissions can be used depending on what charts you intend to install, we can give Tiller a Service Account with cluster-admin access permissions. On an OpenShift (I'm using minishift) cluster, we can use the OpenShift CLI to create a Service Account with this role:

$ oc login -u system:admin
$ oc create serviceaccount --namespace kube-system tiller
$ oc adm policy add-cluster-role-to-user cluster-admin -z tiller -n kube-system

To verify that we’ve given the Service Account the correct role, check that the Service Account shows up in the cluster-admins role binding:

$ oc get clusterrolebindings cluster-admins
NAME ROLE USERS GROUPS SERVICE ACCOUNTS SUBJECTS
cluster-admins /cluster-admin system:admin system:cluster-admins default/pvinstaller, kube-system/tiller

Now we can go ahead and install Tiller using the Helm CLI, passing it the Service Account we created for it:

$ helm init --service-account=tiller

Once the Tiller pod is ready, we can check if everything is setup properly by successfully installing a chart:

$ helm install --name mariadb stable/mariadb
$ helm delete --purge mariadb

Install Monocular chart

Monocular has three components:

  1. The backend API that indexes chart repositories, providing endpoints to fetch data about a chart
  2. The frontend UI, an Angular.js application
  3. A prerender service for serving static HTML from the rendered Angular.js application

The frontend assets (HTML, JavaScript, CSS, etc.) are served by an Nginx server. By default, the Bitnami Nginx image starts up as the root user, configures the server and starts up workers under an unprivileged daemon user.

However, OpenShift doesn’t allow containers to start up as the root user. We previously worked around this by modifying the security context constraints, but it would be more secure to modify the container to run in a non-root setting. To this end, I built a variant of the Bitnami Nginx container that runs as an unprivileged user. Basing the Monocular UI container off this image, we’re able to run Monocular on OpenShift without modifying security constraints.

The backend API and prerender service are both already able to run in the restricted OpenShift environment, so changes were not needed here.

So, to get Monocular running in your OpenShift cluster, you only need to specify the modified image (pushed to prydonius/monocular-ui) and update the service port to the unprivileged 8080. We'll also enable the ability to install charts from Monocular (api.config.releasesEnabled), and configure api.monocular.local and monocular.local to serve the frontend and backend respectively.

From the checked out repository, run:

$ helm install --name monocular ./deployment/monocular --set api.config.releasesEnabled=true,ui.image.repository=prydonius/monocular-ui,ui.service.internalPort=8080,ui.backendHostname=http://api.monocular.local,api.config.cors.allowed_origins={http://monocular.local}

On other Kubernetes platforms, you’d typically use an Ingress controller to route traffic to the frontend and backend. On OpenShift, we can instead use the OpenShift Router, which is enabled by default in minishift. Create the following resources to setup the routing:

apiVersion: v1
kind: Route
metadata:
name: monocular-api
spec:
host: api.monocular.local
to:
kind: Service
name: monocular-monocular-api
---
apiVersion: v1
kind: Route
metadata:
name: monocular-ui
spec:
host: monocular.local
to:
kind: Service
name: monocular-monocular-ui
$ oc apply -f routes.yaml

You will need to point api.monocular.local and monocular.local to your OpenShift cluster to be able to resolve them. On minishift you can get the IP address by running minishift ip, and then point the hosts to this IP in your /etc/hosts.

<minishift ip> monocular.local api.monocular.local

Finally, once all the Monocular pods are up and running, you can visit http://monocular.local in your browser to access your running instance.

Next step: moar charts working on OpenShift

Running Monocular on OpenShift is awesome, but most of the Helm charts in the default repository don’t work out of the box on OpenShift yet. As we mentioned before, we’re working on improving our containers to run unprivileged, and we encourage other container and chart developers to do the same. Containers that work in restrictive environments work fine in less restrictive environments, but never the other way around.

--

--

Adnan Abdulhussein
Bitnami Perspectives

Software Engineer at Brex working on all things #cloud, #containers and #kubernetes.