About Helm Installations with Replicated
This topic provides an introduction to Helm installations for applications distributed with Replicated.
Overview
Helm is a popular open source package manager for Kubernetes applications. Many ISVs use Helm to configure and deploy Kubernetes applications because it provides a consistent, reusable, and sharable packaging format. For more information, see the Helm documentation.
Replicated strongly recommends that all applications are packaged using Helm because many enterprise users expect to be able to install an application with the Helm CLI.
Existing releases in the Replicated Platform that already support installation with Replicated KOTS and Replicated Embedded Cluster (and that include one or more Helm charts) can also be installed with the Helm CLI; it is not necessary to create and manage separate releases or channels for each installation method.
The following diagram shows how Helm charts distributed with Replicated are installed with Helm in online (internet-connected) customer environments:
View a larger version of this image
As shown in the diagram above, when a release containing one or more Helm charts is promoted to a channel, the Replicated Vendor Portal automatically extracts any Helm charts included in the release. These charts are pushed as OCI objects to the Replicated registry. The Replicated registry is a private OCI registry hosted by Replicated at registry.replicated.com
. For information about security for the Replicated registry, see Replicated Registry Security.
For example, if your application in the Vendor Portal is named My App and you promote a release containing a Helm chart with name: my-chart
to a channel with the slug beta
, then the Vendor Portal pushes the chart to the following location: oci://registry.replicated.com/my-app/beta/my-chart
.
Customers can install your Helm chart by first logging in to the Replicated registry with their unique license ID. This step ensures that any customer who installs your chart from the registry has a valid, unexpired license. After the customer logs in to the Replicated registry, they can run helm install
to install the chart from the registry.
For information about how to install with Helm, see:
About the global.replicated
Helm Values
When a customer installs your Helm chart from the Replicated registry, the Replicated registry injects values into the global.replicated
field of the Helm chart values file.
The following is an example of a Helm values file containing the global.replicated
field injected by the Replicated registry:
# Helm values.yaml
global:
replicated:
channelName: Stable
customerEmail: username@example.com
customerName: Example Customer
dockerconfigjson: eyJhdXRocyI6eyJd1dIRk5NbEZFVGsxd2JGUmFhWGxYWm5scloyNVRSV1pPT2pKT2NGaHhUVEpSUkU1...
licenseFields:
expires_at:
description: License Expiration
name: expires_at
signature:
v1: iZBpESXx7fpdtnbMKingYHiJH42rP8fPs0x8izy1mODckGBwVoA...
title: Expiration
value: "2023-05-30T00:00:00Z"
valueType: String
licenseID: YiIXRTjiB7R...
licenseType: dev
The values in the global.replicated
field provide information about the following:
- Details about the fields in the customer's license, such as the field name, description, signature, value, and any custom license fields that you define. You can use this license information to check license entitlments before the application is installed. For more information, see Checking Entitlements in Helm Charts Before Deployment.
- A base64 encoded Docker configuration file. To proxy images from an external private registry with the Replicated proxy registry, you can use the
global.replicated.dockerconfigjson
field to create an image pull secret for the proxy registry. For more information, see Proxying Images for Helm Installations.
Limitations
Helm installations have the following limitations:
- Installing with Helm in air gap environments is an Alpha feature. For more information, see Installing and Updating with Helm in Air Gap Environments.
- Helm CLI installations do not provide access to any of the features of the Replicated KOTS installer, such as:
- The KOTS Admin Console
- Strict preflight checks that block installation
- Backup and restore with snapshots
- Required releases with the Prevent this release from being skipped during upgrades option