Operations teams need to automate deployment of applications, and Helm is the industry-standard solution for deploying to Kubernetes. Like many software vendors, we provide Helm charts for installing Artifactory and other JFrog DevOps platform products, designed for the standard/recommended configurations most teams will need. These templates provide customers a limited set of configuration options.
If you need to customize your Artifactory, Xray, or other deployments in ways of your own, you might fork the chart to create your own custom version. But once you do, each time JFrog updates its Helm chart, your custom version becomes out of sync and obsolete. To keep your version up-to-date, you would need to reintegrate for every update.
How can you customize a Helm chart without forking? That’s exactly what Google created Kustomize for. In this post — and also in an upcoming webinar — we’ll show you how you can use Kustomize overlays to perform custom deployments while always using the latest Helm chart version from your vendor.
Templates vs Overlays
A template is a form that has placeholders that an automated process will parse to replace them with values. Designed to perform a specific function, it marks the places where you must provide the specifics. If you’ve ever played “Mad Libs” this “fill-in-the-blanks” process will be familiar.
As a developer, you’ll recognize that templates and values are like macros and their variables, or subroutines and their parameters.
An overlay is a set of replacement strings. Blocks of text in the original file are entirely replaced with new blocks of text.
What’s the difference?
- A template needs to be carefully prepared to demand specific information in key places. When you use a template, you’re restricted to changing only those elements the template makes available.
- An overlay doesn’t require the original file to be prepared in any way. You can replace any part in its entirety.
HelloWorld Helm Chart
Since Artifactory’s Helm charts are quite advanced, let’s use a very simple example. Here, the template permits an argument for the company name.
The values for the template’s arguments are in the file
Let’s install and see how it works.
Neat! This worked well, and we shipped it to customers. But one customer has a unique requirement, to add employee name and department name to the output to look like this:
My name is John. I work for the Accounting department. Our company name is ABC Company.
Okay, pretty easy, they could fork the Helm chart and change the Helm template as follows:
Then they would add new values in the
But, as we noted, their fork is now out of sync with the original. This is where Kustomize comes to the rescue.
Overlaying with Kustomize
Kustomize enables you to overlay your own “kustomizations” in yaml files. In our example, the customer can “kustomize” to their needs without creating a private, unmaintainable fork of charts.
First the customer will create a
Now we can direct kustomize to apply our overlay.
We will first replace the original template with our new template, then install it with Helm and verify.
Great! This matches our customer’s requirement.
Template First, Overlay Next
In the prior example, we used Kustomize to modify our Helm template to accept new values, then used that version with
helm install to deploy the app.
But there are scenarios where that sequence isn’t ideal. Instead, you may wish to render the chart template first locally, then apply your Kustomize overlay when you deploy the app.
This may work best when you need to deploy the same app to multiple environments, but with cross-cutting concerns such as labels, security, or metering. For example you may have different combinations of requirements for each environment:
Similarly, you may need to adjust ports or access for each of these environments. In these scenarios, it may be more flexible to apply a different Kustomize overlay to the same rendered Helm chart for each environment.
For this purpose, the kubectl command line utility provides the
apply -k option. This facility applies Kustomize on charts using
kustomization.yaml files in the directories.
To start, let’s render the Helm chart locally using the helm template command. This outputs a YAML file with all values resolved, which we capture to a local file.
Create a new kustomization file to add labels to our pod as follows:
Now let’s use
kubectl apply -k to install our chart with new labels:
Success! Now we are able to take any vendor’s Helm chart and add our own‘kustomizations on top while continuing to take updates from upstream charts.
JFrog’s Helm charts are quite advanced, and we’ve often had to maintain multiple versions for our internal use. Using Kustomize has helped us to avoid manual editing of charts, and to more fully automate our CI/CD processes.
Want to learn more? Register for our upcoming webinar on how to Power up Artifactory with Kustomize & Helm. We’re eager to share what we’ve learned and help you to better manage your deployments!