How can I ship a Helm application as a Replicated appliance?


#1

If I have an existing Helm application, what’s the easiest way to get this created as a Replicated YAML file that will be accepted in vendor.replicated.com and packaged as a Replicated application?


#2

Replicated supports any Kubernetes application, but doesn’t currently support Helm applications natively (and likely won’t as the V3 changes to Helm will likely lead to a more compatible Helm that doesn’t require native support). To ship a Helm application on Replicated, you’ll need to render the Helm charts to get plain Kubernetes YAML.

Create a Replicated values.yaml file

For each chart you need to ship, create a values.yaml file that contains static values for any items that your enterprise customers should not be configuring, and Replicated template functions for configurable items.

To explain this, let’s take a look at a sample, public chart. The Sentry chart is available as a stable chart, and the values file is hosted at https://github.com/kubernetes/charts/blob/master/stable/sentry/values.yaml. There are several values in here that shouldn’t be configured by an enterprise customers, and these have sane defaults already listed. But a few of these values should be configurable from the Replicated Admin Console, such as GITHUB_APP_ID and GITHUB_API_SECRET. Using the Replicated Template Functions, provide references to config items here:

  env:
    - name: GITHUB_APP_ID
      value: '{{repl ConfigOption "github_app_id"}}'
    - name: GITHUB_API_SECRET
      value: '{{repl ConfigOption "github_api_secret"}}'

The full example configured YAML is here.

Render the Helm chart using this values.yaml

Next, using the Helm CLI, render the Helm chart to a dynamic namespace (configured by Replicated at install time), using the values.yaml file just created:

$ helm template --namespace '{{repl Namespace}}' -f ./values.yaml path/to/chart > replicated.yaml

Create Replicated YAML

Each separate document will be separated with:

---
# Source: sentry/charts/redis/templates/secrets.yaml

To make this compatible with Replicated, we need to insert a line between these two lines, everywhere they appear:

$ sed -i -e 's/---/---\\\n# kind: scheduler-kubernetes/g' replicated.yaml

Add Config items

Finally, add a config section to this YAML file that defines the ConfigOption items in your Kubernetes YAML.


#3

What are best practices around excluding a helm dependency, since this occurs post-render?

That is, if I ship an application where in helm there’s an optional dependency, such as a database.
In Replicated I’d want to choose whether to deploy the database or connect to an external one. So far the only thing I can think of is setting replicas to 0 but still creating the deployment.


#4

Replicated supports templating in Kubernetes YAML, so this can be done after the chart is rendered. You can optionally include or exclude components using the ConfigOptionEquals function:

---
# kind: replicated

config:
- name: db_settings_type
  title: Database Type
  description: Would you like to run an internal database or provide your own?
  items:
  - name: db_type
    type: select_one
    default: embedded
    items:
    - name: embedded
      title: Embedded
    - name: external
      title: External

....

---
# kind: scheduler-kubernetes

{{repl if ConfigOptionEquals "db_type" "embeded"}}
  ... kubernetes database yaml...
{{repl end}}