Skip to content

Migrating from Tailor to Helm

Jump to bottom
Michael Sauter edited this page Dec 10, 2020 · 26 revisions

Scope and Goal of this document

Tailor has been developed for OpenShift 3.11. Back in the days, Helm required the use of a privileged Tiller service and did not work well with OpenShift-specific resources. With Helm 3 and OpenShift 4, this situation as changed.

While Tailor also works in an OpenShift 4 cluster, OpenShift has integrating Helm into its product, and Helm has a huge and growing community. Therefore, it is recommended to use Helm instead of Tailor in an OpenShift 4 cluster.

This document will describe how to migrate from Tailor to Helm.

Tailor is based on OpenShift templates, which define the Kubernetes resources to apply. Helm uses a different templating language / engine, but in the end the templates also describe Kubernetes resources. Therefore, migration effort is relatively low as one only needs to change the syntax of the definition, not the definition itself. Further, there are differences between the CLI of the two tools and not all features of Tailor are available in Helm and vice-versa. Once migration to Helm is complete, it is also recommended to look at the best practices in the Helm community and adopt these.

Migrating templates

There are basically two options how to approach this: you can either convert your existing OpenShift templates to chart templates, or you can start with a blank chart and adjust it as necessary.

Converting OpenShift templates

If you want to convert your existing templates, you may use template2helm. This method should require less effort, but you are left with a template that might have some errors and does not follow best practices from the Helm community.

Example usage:

template2helm convert -t openshift/template.yml -c . # Will create a "chart" folder in .

Starting with a blank chart

The other option is to start from a blank chart and adjust this as necessary to match the live configuration. This will almost certainly be more effort than converting the templates, but you will learn more about Helm templating and can start out with some best practices.

Example usage:

helm create chart

Various pieces

Linting Helm templates

Use helm lint to check for errors.

Verifying migration

To check whether the new Helm templates match the old OpenShift templates, it is recommended to make use of the helm-diff plugin. This will show all differences that exist between live configuration and the Helm template. Adjust until there is no difference.

Adopting existing resources

Helm does not simply take ownership on already existing resources. You need to adopt them first. See https://github.com/helm/helm/pull/7649 for details.

Example:

KIND=deployment
NAME=my-app-staging
RELEASE=staging
NAMESPACE=default
kubectl annotate $KIND $NAME meta.helm.sh/release-name=$RELEASE
kubectl annotate $KIND $NAME meta.helm.sh/release-namespace=$NAMESPACE
kubectl label $KIND $NAME app.kubernetes.io/managed-by=Helm

Tailor features for which there is no equivalent in Helm

  • Exporting of resources via tailor export. Helm does not offer this. You may want to take a look at chartify.

  • Preserving live configuration. This is due to the different patching algorithm, see further below.

Helm features for which there is no equivalent in Tailor

These are just some examples worth noting. The list is by no means complete.

Notable behaviour differences between Tailor and Helm

  • In Helm, manual changes in the cluster are not reported by helm-diff, nor does helm upgrade reset to the value in the chart. Even if the field ownership is changed back to "helm", the manual change is not reset. Only when the value in the chart changes, then the live configuration gets updated. Tailor will immediately report drift.

  • Tailor supports encrypting secrets out-of-the-box, for Helm you can use the helm-secrets plugin

Clone this wiki locally