Master Your Helm Chart Repositories in Artifactory
Following ourinitial release of Helm Chart repository supportin Artifactorya 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 youmanage Kubernetes applications usingHelm Charts.
Artifactorynow natively supportsHelm repositories,giving you full control of your deployment process to Kubernetes. It supports proxying remote Helm repositories,deploying Helm Chartsto 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 bestHelm repository practices:
Virtual repositories are the way to go
Artifactory supports creatingvirtual Helm repositoriesfor 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. Toresolve Helm chartsfrom 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 avirtual repository.
- Set thePackage TypetoHelm.
- Select the underlying local and remote Helm repositories to include in theBasicsettingstab.
Proceed to configure the repository in theJFrog 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 theStable Public Helm Chartrepository, and their pre-release counterparts found in theIncubator Helm Chartrepository. 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 packagesearchin 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 theChart.yamlfile.
Recalculate the index.yaml file from scratch
Artifactory supports recalculating the localindex.yamlfile in seconds in cases where you suspect yourindex.yamlmight be corrupt.
To recalculate the localindex.yamlfile:
- Select your Helm Chart repository in the tree browser.
- ChooseRecalculate Indexfrom the right-click menu.
Once selected, the index is calculated asynchronously.
Control the metadata retrieval cache period for a virtual repo
Virtual repositories merge theindex.yamlfile of all the repositories they aggregate into a singleindex.yamlfile. 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 theArtifactsmoduleTreebrowser, select the virtual repository to zap.
- ClickZap Cachesin the right-click menu or selectActionsfrom the drop-down menu.
JFrog CLI helps you deploy your Helm Charts
You can useJFrog CLIto 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 theJFrog CLI Upload command:
jfrog rt u "*.tgz" helm-local
To learn more about general best practices when creating Helm Charts, seeThe Chart Best Practices Guide.
