Templating on OpenShift: should I use Helm templates or OpenShift templates?

When deploying applications with container orchestrators such as Kubernetes or OpenShift, the need for templating is rapidly felt. Indeed it is the way to easily:

  • manage several environments (staging, pre-prod, production…)
  • manage similar logical groups of resources (configmap, deployment, service, route…)
On Kubernetes, the usual first choice is Helm even though several alternatives exist. However, when it comes to OpenShift, the choice is somehow trickier because there is a native OpenShift resource for templating. On one hand, this resource is rather basic in terms of functionalities. But on the other hand, the installation of Tiller on OpenShift means giving it the edit (or admin in some cases) rights on all your projects. Thus, it means lower security standards of your OpenShift projects. So what should you choose?

OpenShift templates vs Helm templates

I gathered in the following table a few arguments that might help you make up your mind.

 

 

OpenShift templates

Helm templates

Installation

Comes natively with OpenShift

A few steps need to be taken

Security

 

Tiller needs at least edit rights on all the projects you want to deploy into. (Admin if your Charts contains Role)

Configuration file language

A unique (long) file with a resource of a kind “template” listing all your resources, written in json or yaml with the insertion of variables following shell syntax ${}

Several files in the template folder of your Chart, written in yaml with insertions of variables in go

Templating structures

Basic

Some coding structures such as iteration and condition. some utilities for text formatting (base64, indent, ...)

Variable file name

By convention in .params files

In values.yaml

Orchestrator coupling

Only exists on OpenShift

Works with OpenShift and kubernetes

Release versioning

Unavailable

Allows creating releases and rollback if needed

Resources, sharing

Some templates to install applications are available on GitHub, you can store your template in the cluster in object form so that anyone with reading access can use them

The dynamic community provides Charts but they sometimes need to be adapted to OpenShift for security reasons

 

Overview of configuration files

Let us now compare basic syntaxes for configuration files. Here is what an OpenShift template.yaml looks like:

You will then provide your variables in your production.params file:

And deploy it with the command

oc process template.yaml --param-file=production.params | oc apply -f -

In the Helm case, you would have configmap.yaml, deployment.yaml, service.yaml, route.yaml configuration files in your templates folder. For instance, the configmap.yaml would look like this

Your Values.production.yaml would contain something like

And you would apply your template using

helm upgrade -i my-release -f values.yaml

 

Helm much more than templating

Having said that, we should emphasize the fact that Helm is much more than just a templating tool. It is a package manager, with a dynamic community that prepares Charts for quick installation. A simple  Helm install --name my-release stable/elasticsearch  will install an elastic search on your cluster. However, to use Helm Charts on OpenShift, you might need to adapt them, for instance, if the containers of a Chart run as root (forbidden by default on OpenShift).

 

Security: Version 3 of Helm will reconcile OpenShift and Helm

Overall the main argument against Helm is the loose privileges granted to Tiller. Since the default enabling of Role-Based Access Control in Kubernetes, Helm developers chose to give it default high privileges. That way new users can quickly start playing without having to deep dive into security controls. However, in recent articles, Helm developers announced Tiller will be removed in Helm 3. Indeed, the cluster’s shared release management that Tiller was taking care of, will be assured by Kubernetes resources and requests to the API server. User will be able to deploy through Helm only what their Kubeconfig allow them to. We will thus regain the wanted granularity of privileges.

 

 

In the end, we have decided not to use Helm, to not give Tiller the high privileges it needs at the moment. Also, since we only need the templating functionality at the moment, Helm appears a bit as an overkill. However, the second Helm 3 is stable (it is alpha 2 at the moment) we will probably switch to it. If you want to debate or ask questions about templating on OpenShift, feel free to contact us.

Emmanuel Lilette

Emmanuel Lilette

Emmanuel est Cloud Engineer chez Padok

What do you think? Leave your comments here !