Rancher’s Helm Catalog is a feature that lets you deploy applications packaged as Helm charts directly from Git repositories.
Imagine you’re in a Kubernetes cluster managed by Rancher. You want to install a new application, say Prometheus for monitoring. Instead of manually creating all the Kubernetes YAML files for Prometheus, you can use a Helm chart. Rancher integrates with Git repositories that host these Helm charts, making deployment a breeze. It’s like having an app store for your Kubernetes cluster, where the apps are defined by Helm charts and the store is a Git repo.
Here’s how it works in practice. Let’s say you have a Git repository at https://github.com/myorg/helm-charts.git which contains a directory prometheus with a Chart.yaml and values.yaml file.
First, you’d add this Git repository as a catalog in Rancher. In the Rancher UI, navigate to your cluster, then "Apps & Marketplace" -> "Catalogs". Click "Create".
- Name:
my-prometheus-charts - Catalog Type:
Git - Git Repo URL:
https://github.com/myorg/helm-charts.git - Branch:
main(or whatever branch your charts are on) - Path in Repo:
prometheus(if your charts are in a subdirectory, otherwise leave blank)
Once saved, Rancher will fetch the charts from that Git repository. You’ll see my-prometheus-charts appear in your list of catalogs.
Now, to deploy Prometheus:
- Go to "Apps & Marketplace" -> "Charts".
- You’ll see charts from your added catalogs. Find the
prometheuschart undermy-prometheus-charts. - Click "Install".
- You’ll be presented with a form to configure the deployment. This form is generated from the
values.yamlfile within the Helm chart. You can override default values here. For example, you might want to set the retention period for Prometheus:- In the UI, navigate to the "Global" or "Configuration" section, and find the
server.retentionvalue. - Enter
24h(for 24 hours).
- In the UI, navigate to the "Global" or "Configuration" section, and find the
- Click "Install".
Rancher then uses Helm under the hood. It takes the chart from your Git repository, applies your configured values.yaml (including any overrides you made in the UI), and creates the necessary Kubernetes resources (Deployments, Services, ConfigMaps, etc.) in your cluster.
The power here is that your entire application definition – its configuration, dependencies, and deployment logic – lives in a version-controlled Git repository. When you need to update Prometheus, you update the values.yaml in your Git repo, commit, and push. Then, in Rancher, you can go to the deployed Prometheus application and click "Upgrade", selecting the new version from your catalog. Rancher will re-run Helm with the updated values.
The system is designed to abstract away the complexity of Kubernetes YAML. Helm charts provide a templating engine and a standardized way to package applications. Rancher’s Helm Catalog feature simply makes it incredibly convenient to point Helm at a Git repository and deploy those packaged applications into your managed Kubernetes clusters.
Here’s a mental model:
- Helm Chart: A pre-packaged Kubernetes application definition. Think of it as a blueprint for deploying an app. It includes templates for Kubernetes resources and default configuration values.
- Git Repository: Where you store your Helm charts. This provides version control, collaboration, and a single source of truth.
- Rancher Catalog: A pointer in Rancher to a Git repository (or other sources like OCIS registries) containing Helm charts. It tells Rancher where to find the blueprints.
- Rancher App: An instance of a Helm chart deployed into your Kubernetes cluster. You can have multiple instances of the same chart, each with different configurations.
A key detail often overlooked is how Rancher manages the state of the deployed application. When you install an app, Rancher not only tells Helm to deploy it but also keeps track of the Helm release’s status. If a deployment fails, Rancher will report the Helm error directly. Crucially, when you update an app, Rancher doesn’t just re-apply the chart; it triggers a Helm "upgrade" operation. This means Helm intelligently compares the new desired state with the current state and makes only the necessary changes, often performing rolling updates to minimize downtime. This statefulness is managed by the helm.sh/resource-policy: keep annotation on resources managed by Helm, ensuring that even if a resource definition is removed from the chart, it’s not immediately deleted from the cluster during an upgrade, allowing for graceful transitions.
The next step in managing your applications might involve exploring custom resource definitions (CRDs) for more advanced application lifecycle management within Kubernetes.