Transition from Jinja to Helm¶

Why move to Helm?¶

As part of delivery modernization, we want to move to solid deployment practices and tools for our cloud native delivery.

Helm simplifies the deployment of containerized applications
Helm is the defacto package manager for Kubernetes (K8s)
Helm has large community support and provides ArtifactHub for community supported Charts
Flexibility of local deployments for fast feedback
Brings the control of the deployment and troubleshooting back to the team
Deployments are simple throughout multiple environments
Safer deployments with an easy rollback mechanism

Installing a Helm Chart into your cluster is as easy as running a single helm install while Jinja may require multiple executions & configurations to deploy applications to a K8s cluster
Helm gives you a deployment history (metadata that is stored in the cluster) that Jinja doesn't. This enables helm rollback.
The Helm metadata also allows helm to check what is deployed via helm list
Helm lets you see what values were provided to the template, which aids in debugging with helm get
Helm has a Chart that is made up of Chart.yaml, values files and templates (.tpl) files providing abstract, component level control
Helm has some intelligence around how k8s works; it was designed to work with k8s, whereas Jinja is a generic templating tool.
Once packaged, helm releases are resources that are logically grouped together
Helm provides flow control baked inside of it's clear and simple templates
With Jinja, complex pyrenders may be used, but with Helm this is accomplished with easy to use charts