Closed
Description
Currently we map single release in helmfile by using helm sub charts i.e.
subchart1: worker-type1
subchart2: worker-type2
chart1:
subchart1-alias1:
overide-variables1
subchart2-alias1:
overide-variables1
subchart2-alias2:
overide-variables2
where a chart refers to a subchart multiple times by using aliases in requirements.yaml. We then manage the deployment of chart1 by mapping it to a release in helmfile.
While this pattern works it is very difficult to iterate over this pattern. Figure this scenario:
- we want to update the subchart1 - for every end-to-end test on this we will need to update the chart1 to point to the new version of subchart1 and then update helmfile to point to new versions of chart1.
- we want the release to map directly to an application - for every application we want to have a single release so we can easily map and graph the unique names. while we can still work-around this by using a unique label across a single helmfile declaring multiple releases - but that would not be as consistent.
An ideal solution would be to flatten the structure and have no subchart and let helmfile manage the alias declaration. Effectively in helmfile release we call something like:
helmDefaults:
tillerNamespace: {{ .Environment.Values.tiller }}
kubeContext: {{ .Environment.Values.kubectx }}
environments:
env1:
values:
- ../../envs/env1.yaml
env2:
values:
- ../../envs/env2.yaml
releases:
- name: app
namespace: {{ .Environment.Values.namespace }}
charts:
- alias: app-worker1
chart: repo-name/app-worker1
version: 0.1.4
- alias: app-worker2
chart: repo-name/app-worker1
version: 0.1.4
secrets:
- secrets/app.{{ .Environment.Values.env }}.yaml
values:
- values/app.yaml.gotmpl
--app.yaml.gotmpl
app-worker1:
override-values:
aa: 112asas
bb: 121212
app-worker2:
override-values:
cc: 12412
dd: 124sdf
It would be very convenient to have a feature similar to helm alias in helmfile so we can call multiple instances of a single chart.
Metadata
Metadata
Assignees
Labels
No labels