Skip to main content
Version: 0.7

Helm

The Helm backend storage gives you an option to map the TypeInstance's value to a given Helm release installed in a cluster. This solves problems with outdated static data about Helm release that is stored in the built-in database. The functionality in a form of a dedicated storage backend is installed using Capact Action. This guide describes how to install and configure the Helm storage backends for Capact Local Hub.

To learn more about Capact Local Hub storage backends, see the Introduction document.

Features​

There are different options of using the Helm storage backend. In each option Helm backend works locally, which means that it can resolve only a given Helm release if it's installed on the same Kubernetes cluster.

Helm Release​

Provides the metadata for a given Helm release installed on the Kubernetes cluster. Returned value contains:

# Name specifies installed Helm release name.
name: rel-name
# Namespace specifies in which Kubernetes Namespace Helm release was installed.
namespace: rel-namespace
# Chart holds Helm Chart details.
chart:
  # Name specifies Helm Chart name.
  name: chart-name
  # Version specifies the exact chart version.
  version: installed-chart-version
  # Repo specifies URL where to locate the requested chart.
  repo: repo-url

Helm Release backend doesn't store any data. Thus, it works only on the Helm release fetched from the cluster. The create and update methods check only if a given Helm release is accessible. The delete revision, delete the whole object, lock, and unlock methods don't execute any operation.

Helm Template​

Renders a given Go template against an installed Helm release. The output depends on the given goTemplate context property.

Helm Template backend doesn't store any data. Thus, it works only on the Helm release fetched from the cluster. The create and update methods check only if a given Helm release is accessible and if provided Go template can be rendered. The delete revision, delete the whole object, lock, and unlock methods don't execute any operation.

Prerequisites​

Installation​

In the default mode, both Helm storage backends are installed. To change it, copy the snippets from the “Customized” tab and change either helmReleaseBackend.enabled or helmTemplateBackend.enabled to false before creating input files.

  1. Create parameters:

    cat > /tmp/helm-storage-input-params.yaml << ENDOFFILE
    input-parameters: {}
    # Optional input parameters, e.g.:
    # version: 0.6.0-bf8d006
    ENDOFFILE

  2. Create Action:

    capact act create cap.interface.helm.storage.install --name helm-storage -n capact-system --parameters-from-file /tmp/helm-storage-input-params.yaml

  3. Wait for the Action to have the READY_TO_RUN status:

    capact act wait --for=phase=READY_TO_RUN  helm-storage -n capact-system

  4. Run Action:

    capact act run helm-storage -n capact-system

  5. Watch the Action for completion:

    capact act watch helm-storage -n capact-system

  6. Get output TypeInstances:

    capact act get helm-storage -n capact-system -ojsonpath -t '{.Actions[0].output.typeInstances}'

    See the details of the created TypeInstances:

    • Copy ID of the Helm Release backend:
      capact act get helm-storage -n capact-system -ojsonpath -t '{.Actions[0].output.typeInstances[?(@.typeRef.path == "cap.type.helm.release.storage")].id}'
    • Assign Helm Release backend ID to the variable
      HELM_RELEASE_STORAGE_ID={Helm Release backend ID}
    • Display Helm Release backend details:
      capact ti get $HELM_RELEASE_STORAGE_ID -oyaml
    • Copy ID of the Helm Template backend:
      capact act get helm-storage -n capact-system -ojsonpath -t '{.Actions[0].output.typeInstances[?(@.typeRef.path == "cap.type.helm.template.storage")].id}'
    • Assign Helm Template backend ID to the variable
      HELM_TEMPLATE_STORAGE_ID={Helm Template backend ID}
    • Display Helm Template backend details:
      capact ti get $HELM_TEMPLATE_STORAGE_ID -oyaml

Use Helm backends​

Once the Helm backends are installed, you can configure it for Helm related TypeInstances.

For example, you can set a Global Policy to inject Helm backends to all Implementations that require them:

cat > /tmp/helm-storage-policy.yaml << ENDOFFILE
interface:
  default: # properties applied to all rules above
     inject:
       requiredTypeInstances:
          - id: ${HELM_TEMPLATE_STORAGE_ID}
            description: "Helm template"
          - id: ${HELM_RELEASE_STORAGE_ID}
            description: "Helm release"
  rules:
      - interface:
          path: cap.*
        oneOf:
        - implementationConstraints:
            requires:
            - path: cap.core.type.platform.kubernetes
        - implementationConstraints: {}
ENDOFFILE
capact policy apply -f /tmp/helm-storage-policy.yaml

To read more about TypeInstance backend configuration, see the Definition of rules for TypeInstance section.