Master Your Helm Chart Repositories in Artifactory
Following our initial release of Helm Chart repository support in Artifactory a few weeks ago, it’s time to leap into the fast track and get your Helm repositories up and running. Just a short recap, Helm is the package manager for Kubernetes and helps you manage Kubernetes applications using Helm Charts.
Artifactory now natively supports Helm repositories, giving you full control of your deployment process to Kubernetes. It supports proxying remote Helm repositories, deploying Helm Charts to local repositories and, of course, using a virtual repository to aggregate all those other Helm Chart repositories so you can access them through a single endpoint.
Put your Helmet on and enjoy the ride!
To get the most out of your Helm Chart repositories in Artifactory, we recommend applying these best Helm repository practices:
Virtual repositories are the way to go
Artifactory supports creating virtual Helm repositories for Kubernetes, which can contain both local and remote repositories. This allows you to access both locally hosted Helm charts as well as proxied remote Helm chart repositories from a single URL defined for the virtual repository.
You gain the following when using virtual repositories:
- Helm Chart resolution
Artifactory only supports resolution of Helm charts from virtual repositories. To resolve Helm charts from local or remote Helm chart repositories, you need to aggregate them in a virtual Helm chart repository. - Controlled domains
Controlled domains for search and resolution of artifacts.
- Easy access to multiple repositories
Once all of your local and remote Helm chart repositories are aggregated by a virtual repository, all of you Helm charts can be access through a single URL. - Secure and private repositories
Using virtual repositories adds layers of security beyond those already available in Artifactory giving you fine-grained access control to your Helm charts according to projects or development teams in Kubernetes.
To define a virtual Helm Chart repository in Artifactory:
- Create a virtual repository.
- Set the Package Type to Helm.
- Select the underlying local and remote Helm repositories to include in the Basic settings tab.
Proceed to configure the repository in the JFrog Helm client.
Separate your Stable and Incubator repositories
While we recommend using a single virtual repository, we also recommend keeping a clear separation between stable charts found in the Stable Public Helm Chart repository, and their pre-release counterparts found in the Incubator Helm Chart repository. These two should be aggregated in two different virtual repositories so you can work with one when you want official release versions, and the other when you need a pre-release version. This will make sure your builds get the right version of the chart you want and avoid confusion in Kubernetes.
Use SemVer v2 versioning in your charts
JFrog recommends using SemVer as it will help with later versioning, version range requirements, and proper sorting order and resolution from the index.yaml.
Keep your Helm users in the loop
The Helm package search in Artifactory is customized to allow users to search for Helm repositories by “App version” and not only by “Version”, which refers to the Chart version. App Version is a useful piece of information as it lets your users know what version of your app they are using, as the chart version could differ. You can search for the parameter after you add it to the Chart.yaml file.
Recalculate the index.yaml file from scratch
Artifactory supports recalculating the local index.yaml file in seconds in cases where you suspect your index.yaml might be corrupt.
To recalculate the local index.yaml file:
- Select your Helm Chart repository in the tree browser.
- Choose Recalculate Index from the right-click menu.
Once selected, the index is calculated asynchronously.
Control the metadata retrieval cache period for a virtual repo
Virtual repositories merge the index.yaml file of all the repositories they aggregate into a single index.yaml file. However, recalculating the aggregated index for every change to one of the aggregated local or remote repositories may be resource intensive.
To avoid having to recalculate the aggregated index for every change in a remote repository, it is cached and only recalculated according to the Metadata Retrieval Cache Period setting for the virtual repository. By default, this is set at 10 minutes as a reasonable time-out on average, however; if you find that any of your aggregated repositories change frequently, you may lower this value to recalculate the index more frequently.
At any time, you can also manually trigger a recalculation of the index by clearing the cache – what we refer to as “Zapping” the cache which can be invoked as follows:
To zap a cache in Artifactory:
- From the Artifacts module Tree browser, select the virtual repository to zap.
- Click Zap Caches in the right-click menu or select Actions from the drop-down menu.
JFrog CLI helps you deploy your Helm Charts
You can use JFrog CLI to publish and upload your Helm Charts as the Helm client currently does not support deploying Helm Charts.
For example, upload all your *.tgz files to helm-local using the JFrog CLI Upload command:
jfrog rt u "*.tgz" helm-local
To learn more about general best practices when creating Helm Charts, see The Chart Best Practices Guide.
