Posted on 31 July 2019, updated on 6 August 2021.
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.