#helmfile (2023-04)
Questions and discussion around helmfile https://github.com/roboll/helmfile and https://github.com/cloudposse/helmfiles
Archive: https://archive.sweetops.com/helmfile/
2023-04-05
2023-04-10
What is the best way to check for a directory existence in a helmfile.yaml template? Value files can be safely ignored if they don’t exist, but I have a use-case for conditionally including a chart folder. And if that folder doesn’t exist, the release will fail.
I currently have this little snippet but it’s failing for me with the following error: can’t evaluate field Environment in type fs.DirEntry
{{ range $index,$item := readDirEntries "./policies" }}
{{- if eq $item.Name .Environment.Name -}}
- name: policies-{{ .Environment.Name }}
chart: ./policies/{{ .Environment.Name }}
{{- end -}}
{{- end -}}
What about $.Environment.Name
?
Same issue unfortunately
Somehow it doesn’t recognise the different scope
@voron any idea what the issue could be, or protectively a wholly different approach?
Well, I have a working dirty sample
environments:
dev:
---
releases:
# always remove these releases
{{- range $_, $file := ( exec "bash" (list "-c" "cd values-bots-to-remove;echo -n *.yaml") | splitList " " ) }}
{{ $releaseName := trimSuffix ".yaml" $file }}
- name: {{ $releaseName }}
chart: xyz-{{ $.Environment.Name }}
installed: false
{{ end }}
And the output is
helmfile -e dev list
NAME NAMESPACE ENABLED INSTALLED LABELS CHART VERSION
bot true false xyz-dev
Maybe
---
after environments is what you’re missing inside helmfile ?
I do have the —
Would you mind putting an if eq statement in there, like I have?
And see if it picks up on the $
I didn’t try using the $.Environment.name on its own, I’ll do that now
It seems to trip specifically on the if statement it seems
Using it in isolation, like in your example, does work
I don’t have issues using $.Environment.name
inside if
too
environments:
bot:
---
releases:
# always remove these releases
{{- range $_, $file := ( exec "bash" (list "-c" "cd values-bots-to-remove;echo -n *.yaml") | splitList " " ) }}
{{ $releaseName := trimSuffix ".yaml" $file }}
{{ if eq $.Environment.Name $releaseName }}
- name: {{ $releaseName }}
chart: xyz-{{ $.Environment.Name }}
installed: false
{{ end }}
{{ end }}
and the output is
helmfile -e bot list
NAME NAMESPACE ENABLED INSTALLED LABELS CHART VERSION
bot true false xyz-bot
I’m using helmfile v0.149
Did you tried to “output” $item.name
w/o condition ?
I have no idea why but it seems to work now:
{{ range $index,$item := readDirEntries "./policies" }}
{{- if and $item.IsDir (eq $item.Name $.Environment.Name) }}
- name: policies-{{ $item.Name }}
chart: ./policies/{{ $item.Name }}
{{- end -}}
{{- end -}}
Really weird, but happy that it works. Thanks for thinking with me on this, it did help to get a working solution
Seems a little stupid to iterate over all the directories but I couldn’t find a ‘direct’ check. Is there any way to avoid the dot being evaluated as a fs.DirEntry and use the environment name instead?
Putting it in a variable outside the loop {{ $env := .Environment.Name }}
seems to trigger the same error.
2023-04-11
Hi gents Is it possible to somehow use template values un Chart.yaml? I have a library chart and based on environment I need to specify registry for the lib chart. Chart.yaml example that I want to achieve but this doesn’t work:
apiVersion: v2
name: datasources
version: 0.1.0
description: Chart to deploy
dependencies:
- name: common
version: 1.2.0
repository: "{{ .StateValues.registry.helm }}"
Isn’t it {{ .Values.registry.helm }}
It’s almost the same things afaik. Problem not in how to use that variable. I did’t find is it possible to use helmfile variables in Chart.yaml
May be not same. ‘Values’ this could be the keyword in helm terminology. Can u try that and see if it work. Pls ignore if you have tried already
Pretty sure you can’t template Chart.yaml
@bradym Is there a workaround? I saw documentation provides some but they are not applicable to my case
@Sajja Sudhakararao you are right, I want to use values from helmfile not from helm therefore I used StateValues. But in any case I tried this option too) Thank you)
I’ve never needed to do this, but I’d probably write a script to use vals (https://github.com/helmfile/vals) to set that value before running helmfile on the results. vals is used as a lib in helmfile so if you’re using ref
or secretref
to get secrets from something like aws ssm or vault it works the same.
Helm-like configuration values loader with support for various sources
looks interesting,going to check thanks you
2023-04-12
I’ve just stumbled upon helmfile and it looks like it can really solve some of my pain points with helm and my workarounds (custom shell scripts). The main thing I need is the ability to add new manifests (with env vars). It looks like this is done by using a dependency incubator/raw
which expects the manifests to be inline. so 1) Is there a way to put those manifests into their own files with requiredEnv
support and 2) it appears incubator/raw
is deprecated. Should I be using something different?
It looks like helm-x
support for using a dir of manifests was added, though I’m not sure how to get it to work. Here is my current helmfile.yaml but I’m getting an error on the dependency:
Error: dependency "manifests" has an invalid version/constraint format: improper constraint: ]
repositories:
- name: vsphere-tmm
url: <https://vsphere-tmm.github.io/helm-charts>
releases:
- chart: vsphere-tmm/vsphere-csi
version: 3.0.2
name: vsphere-csi
namespace: vsphere-csi-system
createNamespace: true
values:
- helm/values.yaml
dependencies:
- chart: ./templates/manifests/
Though it looks like helm-x
might be abandoned…. disappointing
Yea I’m very confused. Apparently chartify
handles the releases[].dependencies
and it is supposed to be able to turn a dir of manifests into a chart, chartify is a Go library that is primarily used by helmfile to let it convert Kuberntes resource YAMLs or kustomize into a helm chart, and apply various modifications to the resulting chart.
However @mumoshu explicitly states that it’s integration into helmfile doesn’t work that way. https://github.com/helmfile/helmfile/issues/472#issuecomment-1312620664 though maybe I’m mixing up what helm-x
is theoretically intended to handle.
And then if I have to create a chart for my local manifests already, I’m not sure what the point of the helmfile here is hmm
helm-x is now chartify and chartify can treat raw manifests dir as a chart. however, it does not support manifests-as-chart in adhoc dependencies yet!
re incubator/raw, just keep using it or fork it if necessary. we dont host our own raw chart due to limited bandwidth so it’s unfortunately your responsibility…
Ahh ok, thanks for the information. So for the moment, if I want to use manifest files, I have to create a local chart and set that as a dependency. If instead I put the manifests inline, I don’t have to create a chart. Correct? Will either method still allow usage of requiredEnv
?
requiredEnv is available within helmfile.yaml and values.yaml templates so if you are trying to write templates within a non-chart local directory and wanting chartify to treat it as a chart, that’s impossible
Right, I would have to create a local chart, and then pass it a values.yaml that has the requiredEnv
values?
do you really need adhoc dependencies? i think you can just point releases[].chart to a local directory containing raw manifests.
yeah you’d need to do so if you need to dynamically generate release values from envvars.
Well I want to bundle my changes with the existing chart that I’m trying to extend so they are upgraded together. Using 2 releases, one being the original chart and the other being my local manifests would treat them as separate things right?
Also, just a dir of manifests can be used in releases[] just not releases[].dependencies? correct?
Using 2 releases, one being the original chart and the other being my local manifests would treat them as separate things right?
Yes
ust a dir of manifests can be used in releases[] just not releases[].dependencies
Correct
Then the only way possible today would be to add incubator/raw as an adhoc dependency and write some values to add your resources
releases:
- name: foo
chart: whatever/main/chart
values:
- bar:
resources:
- kind: ConfigMap
apiVersion: v1
data:
foo: bar
dependencies:
- name: bar
chart: incubator/raw
2023-04-13
2023-04-17
I’m curious is there an option to specify helmfile environment (helmfile -e
) via OS environment variable ?
only options. if you like. please post a feature request.
It was there for a long time, but it’s undocumented
A simple change to allow the ‘environment name’ to be set by an environment variable. Precedence have command line option.
PR is welcome. @voron
Yea, I was looking what files I need to patch and was not able to find any specific place. It seems there is no ready sections for CLI args or HELMFILE_*
env vars
Oh I see CLI reference
you can add a new section for ENVs.
@voron
yep, will try to do it
It’s fixed
Awesome
I’m try to use HELMFILE_V1MODE=true
because we want to be prepared but i think our concept does break with v1 :thinking_face:
We do nested helmfiles (terraform-module-like) but we also want to ‘gotemplate the sub-helmfile itself. We used helmfile.yaml
for the sub-helmfile and with the HELMFILE_V1MODE=true
i’m forced to change the filename to helmfile.yaml.gotmpl
if i do that, the main execution of the parrent helmfile returns this error:
err: no releases found that matches specified selector() and environment(stagename), in any helmfile
(no i do not intend to use selectors so no labels, no selectors are used) why is that? and is our entire concept borken with v1 ?
We add a new “V1 mode” to Helmfile so that you can seemlessly upgrade Helmfile from the current v0.x to the upcoming v1.0.
The idea is that we build both v0 and v1 binaries from the same tagged commit within the main branch, with different defaults for the “V1 mode”- the V1 mode is disabled by default for v0.x binaries, while it is enabled by default for v1.x binaries.
The V1 mode can be overrode at runtime via envvar. That is, even after upgrading the binary to v1, you will not see any backward-incompatible changes while you explicitly set an envvar, HELMFILE_V1MODE=true
, at runtime.
Signed-off-by: Yusuke Kuoka [email protected]
2023-04-18
2023-04-19
I got a question and maybe it is already answered a thousand times I really love to use helmfile, but how do I handle the creation of Kubernetes Manifests(like ConfigMaps, Secrets etc.) outside of a Helm Chart. Currently I use terraform to deploy kubernetes resources (kubernetes provider) and helm releases (helm provider), but it just feels kind of wrong at sometime to use terraform for this
we usually use raw
chart for that and pass the whole manifest as helm values. F.e. https://artifacthub.io/packages/helm/itscontained/raw
A place for all the Kubernetes resources which don’t already have a home
This looks good awesome
2023-04-24
Hey together, hopefully a small question: how does one apply a helmfile which includes sub-helmfiles? My current unexpected result is “no releases found that match my selector() and environment(dev) I’m trying to setup a layered helmfile and staying as DRY as i can - my use case is for example multiple mongdb-databases and they are 90% the same with only minor diffs in the values (persistence size for example):
070-my-service-mongodb.yaml.gotmpl:
bases:
- 000-environments.yaml.gotmpl
- 000-repositories.yaml
---
helmfiles:
- path: _mongodb.helmfile.yaml.gotmpl
values:
- {{ toYaml .Values | nindent 4 }}
- releaseName: my-service-mongodb
releaseNamespace: {{ .Values.myMainNamespace }}
000-environments.yaml.gotmpl:
environments:
default:
values:
- "../environments/dev.values.yaml"
dev:
values:
- "../environments/dev.values.yaml"
---
helmDefaults:
kubeContext: {{ .Values.kubeContext }}
verify: false
wait: true
timeout: 1800
tls: false
_mongodb.helmfile.yaml.gotmpl:
---
releases:
- name: {{ .Values.releaseName }}
installed: true
namespace: {{ .Values.releaseNamespace }}
labels:
release: "{{`{{ .Release.Name }}`}}"
namespace: "{{`{{ .Release.Namespace }}`}}"
chart: bitnami/mongodb
version: {{ .Values.bitnamiMongoDbChartVersion }}
values:
- "../values/infrastructure/mongodb/mongodb.values.yaml.gotmpl"
wait: true
- name: {{ .Values.releaseName }}-backup
namespace: {{ .Values.releaseNamespace }}
labels:
release: "{{`{{ .Release.Name }}`}}"
namespace: "{{`{{ .Release.Namespace }}`}}"
type: backup
chart: myCharts/jobs
version: {{ .Values.jobsChartVersion }}
values:
- "../values/infrastructure/mongodb/mongodb-backup.values.yaml.gotmpl"
wait: true
Output of HELMFILE_V1MODE=true helmfile --debug -i -f ~/IdeaProjects/my-helmfile/helmfile.d/070-my-service-mongodb.yaml.gotmpl -e dev apply
...
A LOT OF ENV + ENV_DEBUG
...
rendering result of "_mongodb.helmfile.yaml.gotmpl.part.0":
0: ---
1: releases:
2: - name: my-service-mongodb
3: installed: true
4: namespace: my-service-dev
5: labels:
6: release: "{{ .Release.Name }}"
7: namespace: "{{ .Release.Namespace }}"
8: chart: bitnami/mongodb
9: version: 13.9.4
10: values:
11: - "../values/infrastructure/mongodb/mongodb.values.yaml.gotmpl"
12: wait: true
13:
14: - name: my-service-mongodb-backup
15: namespace: my-service-dev
16: labels:
17: release: "{{ .Release.Name }}"
18: namespace: "{{ .Release.Namespace }}"
19: type: backup
20: chart: myCharts/jobs
21: version: 13.9.4
22: values:
23: - "../values/infrastructure/mongodb/mongodb-backup.values.yaml.gotmpl"
24: wait: true
25:
changing working directory back to "/Users/PRIVATE/IdeaProjects/my-helmfile/helmfile.d"
helm:XBjnS> v3.11.2+g912ebc1
helm:XBjnS>
Adding repo bitnami <https://charts.bitnami.com/bitnami>
exec: helm --kube-context my-aks repo add bitnami <https://charts.bitnami.com/bitnami> --force-update
helm:MRUSy> "bitnami" has been added to your repositories
helm:MRUSy>
"bitnami" has been added to your repositories
0 release(s) found in 070-my-service-mongodb.yaml.gotmpl:
changing working directory back to "/Users/PRIVATE/IdeaProjects/my-helmfile/helmfile.d"
err: no releases found that matches specified selector() and environment(dev), in any helmfile
In the debug i can find the 2 releases and they look as i would expect it, but then they are not found for applying?
i think i found the cause of the error: my sub-helmfile does not contain environments, as i am trying to pass the values in the main helmfile, i now added:
bases:
- 000-environments.yaml.gotmpl
---
and now it looks like it can apply, which looks related to https://github.com/roboll/helmfile/issues/704
I’m trying to make my helmfiles DRY
helmfile.yaml
helmfiles:
- apps/99_monitor.yaml
apps/99_monitor.yaml
bases:
- ../common/environments.yaml
- ../common/repositories/kubernetes.yaml
- ../common/helmdefaults.yaml
{{ readFile "../common/templates.yaml" }}
releases:
- name: gitlab-{{ .Environment.Name }}-branch-fluent-bit
chart: stable/fluent-bit
version: ~1.8.0
values:
- "../environments/{{ `{{ .Environment.Name }}` }}/gitlab-{{ `{{ .Environment.Name }}` }}-branch-fluent-bit.yaml"
<<: *default
If I lint charts, using apps/99_monitor.yaml
I’ve no errors:
$ helmfile -e master --log-level debug -f apps/99_monitor.yaml lint
processing file "99_monitor.yaml" in directory "apps"
changing working directory to "/home/jjmartres/Desktop/deploy/apps"
first-pass rendering starting for "99_monitor.yaml.part.0": inherited=&{master map[] map[]}, overrode=<nil>
first-pass uses: &{master map[] map[]}
first-pass produced: &{master map[] map[]}
first-pass rendering result of "99_monitor.yaml.part.0": {master map[] map[]}
vals:
map[]
defaultVals:[]
second-pass rendering result of "99_monitor.yaml.part.0":
0: environments:
1: master:
2: review:
3:
merged environment: &{master map[] map[]}
first-pass rendering starting for "99_monitor.yaml.part.1": inherited=&{master map[] map[]}, overrode=<nil>
first-pass uses: &{master map[] map[]}
first-pass produced: &{master map[] map[]}
first-pass rendering result of "99_monitor.yaml.part.1": {master map[] map[]}
vals:
map[]
defaultVals:[]
second-pass rendering result of "99_monitor.yaml.part.1":
0: repositories:
1: - name: kubernetes-charts
2: url: <https://kubernetes-charts.storage.googleapis.com/>
3:
merged environment: &{master map[] map[]}
first-pass rendering starting for "99_monitor.yaml.part.2": inherited=&{master map[] map[]}, overrode=<nil>
first-pass uses: &{master map[] map[]}
first-pass produced: &{master map[] map[]}
first-pass rendering result of "99_monitor.yaml.part.2": {master map[] map[]}
vals:
map[]
defaultVals:[]
second-pass rendering result of "99_monitor.yaml.part.2":
0: helmDefaults:
1: # args:
2: # - "--debug"
3: # Differents contexts: <https://www.reddit.com/r/kubernetes/comments/am5mcq/helmfile_how_to_deal_with_different_versions_in/>
4:
merged environment: &{master map[] map[]}
first-pass rendering starting for "99_monitor.yaml.part.3": inherited=&{master map[] map[]}, overrode=<nil>
first-pass uses: &{master map[] map[]}
could not deduce `environment:` block, configuring only .Environment.Name. error: failed to read 99_monitor.yaml.part.3: reading document at index 1: yaml: unknown anchor 'default' referenced
error in first-pass rendering: result of "99_monitor.yaml.part.3":
0:
1:
2: releases:
3: - name: gitlab-master-branch-fluent-bit
4: chart: stable/fluent-bit
5: version: ~1.8.0
6: values:
7: - "../environments/{{ .Environment.Name }}/gitlab-{{ .Environment.Name }}-branch-fluent-bit.yaml"
8: <<: *default
9:
first-pass produced: &{master map[] map[]}
first-pass rendering result of "99_monitor.yaml.part.3": {master map[] map[]}
second-pass rendering result of "99_monitor.yaml.part.3":
0: templates:
1: default: &default
2: namespace: "gitlab-{{ `{{ .Environment.Name }}` }}-branch"
3: atomic: true
4: missingFileHandler: Warn
5: recreatePods: true
6: wait: true
7:
8:
9: releases:
10: - name: gitlab-master-branch-fluent-bit
11: chart: stable/fluent-bit
12: version: ~1.8.0
13: values:
14: - "../environments/{{ .Environment.Name }}/gitlab-{{ .Environment.Name }}-branch-fluent-bit.yaml"
15: <<: *default
16:
merged environment: &{master map[] map[]}
Adding repo kubernetes-charts <https://kubernetes-charts.storage.googleapis.com/>
exec: helm repo add kubernetes-charts <https://kubernetes-charts.storage.googleapis.com/>
exec: helm repo add kubernetes-charts <https://kubernetes-charts.storage.googleapis.com/>: "kubernetes-charts" has been added to your repositories
"kubernetes-charts" has been added to your repositories
Updating repo
exec: helm repo update
exec: helm repo update: Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "anasen" chart repository
...Successfully got an update from the "gitlab" chart repository
...Successfully got an update from the "kubernetes-charts" chart repository
...Successfully got an update from the "stable" chart repository
...Successfully got an update from the "bitnami" chart repository
Update Complete.
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "anasen" chart repository
...Successfully got an update from the "gitlab" chart repository
...Successfully got an update from the "kubernetes-charts" chart repository
...Successfully got an update from the "stable" chart repository
...Successfully got an update from the "bitnami" chart repository
Update Complete.
worker 1/1 started
Fetching stable/fluent-bit
exec: helm fetch stable/fluent-bit --version ~1.8.0 --untar --untardir /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit
exec: helm fetch stable/fluent-bit --version ~1.8.0 --untar --untardir /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit:
worker 1/1 finished
successfully generated the value file at ../environments/master/gitlab-master-branch-fluent-bit.yaml. produced:
backend:
type: es
es:
host: elasticsearch-client.namespace.svc.cluster.local
port: 9200
index: master_branch
logstash_prefix: master_branch
Linting /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit/fluent-bit
exec: helm lint /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit/fluent-bit --namespace gitlab-{{ .Environment.Name }}-branch --values /tmp/values179823557
exec: helm lint /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit/fluent-bit --namespace gitlab-{{ .Environment.Name }}-branch --values /tmp/values179823557: ==> Linting /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit/fluent-bit
Lint OK
1 chart(s) linted, no failures
==> Linting /tmp/085914238/gitlab-master-branch-fluent-bit/~1.8.0/stable/fluent-bit/fluent-bit
Lint OK
1 chart(s) linted, no failures
But If I lint charts using helmfile.yaml
I got the following error:
$ helmfile -e master --log-level debug lint
processing file "helmfile.yaml" in directory "."
first-pass rendering starting for "helmfile.yaml.part.0": inherited=&{master map[] map[]}, overrode=<nil>
first-pass uses: &{master map[] map[]}
first-pass produced: &{master map[] map[]}
first-pass rendering result of "helmfile.yaml.part.0": {master map[] map[]}
vals:
map[]
defaultVals:[]
second-pass rendering result of "helmfile.yaml.part.0":
0: helmfiles:
1: - ./apps/99_monitor.yaml
2:
err: no releases found that matches specified selector() and environment(master), in any helmfile
What’s going wrong ?
update: by adding the environments to the sub-helmfile i got now the problem that list-elements are duplicated inside which is wrong, i think that’s the case because the environments will also be merged and then the result will be sth. like 2 times the result
second update: HELMFILE_V1MODE=true changes the behaviour and i get duplicated list results
2023-04-27
2023-04-28
Hey together,
Did anyone experience this message with helmfile?
failed to render [values.yaml.gotmpl], because of template: stringTemplate:113: function "toUpper" not defined
Trying to render sth like this:
templateFiles:
{{ define "slack.title" -}}
[{{ .Status | toUpper -}}
{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{- end -}}
] {{ .CommonLabels.alertname }}
{{- end }}
{{ define "slack.text" -}}
It is my prometheus alertmanager config which uses this functions
The corresponding sprig function is upper
http://masterminds.github.io/sprig/strings.html
Useful template functions for Go templates.
@Andrew Nazarov Now I get:
failed to render [values.yaml.gotmpl], because of template: stringTemplate:113:14: executing "slack.title" at <.Status>: can't evaluate field Status in type state.releaseTemplateData
Seems to be an issue:
Consider the following values.yaml
file. This is an excerpt from the default values file for the prometheus helm chart:
## ConfigMap override where fullname is {{.Release.Name}}-{{.Values.server.configMapOverrideName}}
## Defining configMapOverrideName will cause templates/server-configmap.yaml
## to NOT generate a ConfigMap resource
##
configMapOverrideName: ""
When we’re attempting to use helmfile to template into this values.yaml.gotpl
file, we are seeing errors. Obviously it is picking up on {{
and seeing it as a template. We can accept this for comments since they can simply be deleted, however the same thing is happening for nested values that are not in comments.
## alertmanager ConfigMap entries
##
alertmanagerFiles:
alertmanager.yml:
global:
slack_api_url: '<https://slack.com>'
receivers:
- name: default-receiver
pagerduty_configs:
- service_key: key
slack_configs:
- channel: '{{ .CommonAnnotations.channel }}'
send_resolved: true
title: '{{ template "slack.default.title" . }}'
title_link: '{{ template "slack.default.titlelink" . }}'
pretext: '{{ .CommonAnnotations.summary }}'
text: |-
{{ range .Alerts }}
*Alert:* {{ .Annotations.summary }} - `{{ .Labels.severity }}`
*Description:* {{ .Annotations.description }}
*Details:*
{{ range .Labels.SortedPairs }} • *{{ .Name }}:* `{{ .Value }}`
{{ end }}
{{ end }}
To be completely honest, I don’t really know what the answer to this question is. It is understandable that helmfile
is detecting these interpolation tokens - however it introduces a lot of escaping and complexity. Given that prometheus is such a widely used chart, I felt it was worth raising to start a discussion.
hey guys I’m trying to achieve path base routing in an ALB created BY AWS Load Balancer Controller upon ingress object been initialise
apiVersion: [networking.k8s.io/v1](http://networking.k8s.io/v1)
kind: Ingress
metadata:
name: {{ .Chart.Name }}-ingress-rules
annotations:
[alb.ingress.kubernetes.io/scheme](http://alb.ingress.kubernetes.io/scheme): internet-facing
[alb.ingress.kubernetes.io/target-type](http://alb.ingress.kubernetes.io/target-type): ip
[alb.ingress.kubernetes.io/group.name](http://alb.ingress.kubernetes.io/group.name): {{ .Values.ingress.lbGroup }}
[alb.ingress.kubernetes.io/load-balancer-name](http://alb.ingress.kubernetes.io/load-balancer-name): {{ .Values.ingress.lbGroup }}
[alb.ingress.kubernetes.io/listen-ports](http://alb.ingress.kubernetes.io/listen-ports): '[{"HTTP":80},{"HTTPS":443}]'
[alb.ingress.kubernetes.io/ssl-redirect](http://alb.ingress.kubernetes.io/ssl-redirect): "443"
[alb.ingress.kubernetes.io/security-groups](http://alb.ingress.kubernetes.io/security-groups): {{ .Values.ingress.securityGroup }}
[external-dns.alpha.kubernetes.io/hostname](http://external-dns.alpha.kubernetes.io/hostname): {{ .Values.ingress.host }}
[external-dns.alpha.kubernetes.io/alias](http://external-dns.alpha.kubernetes.io/alias): "true"
spec:
ingressClassName: alb
rules:
- host: {{ .Values.ingress.host }}
http:
paths:
- path: {{ .Values.ingress.intercomPath }}
pathType: Prefix
backend:
service:
name: {{ .Values.ingress.intercomServiceName }}
port:
number: {{ .Values.ingress.intercomServicePort }}
`- path: {{ .Values.ingress.engagePath }}`
`pathType: Prefix`
`backend:`
`service:`
`name: {{ .Values.ingress.engageServiceName }}`
`port:`
`number: {{ .Values.ingress.engageServicePort }}`
`- path: {{ .Values.ingress.usersPath }}`
`pathType: Prefix`
`backend:`
`service:`
`name: {{ .Values.ingress.usersServiceName }}`
`port:`
`number: {{ .Values.ingress.usersServicePort }}`
`- path: {{ .Values.ingress.enrichPath }}`
`pathType: Prefix`
`backend:`
`service:`
`name: {{ .Values.ingress.enrichServiceName }}`
`port:`
`number: {{ .Values.ingress.enrichServicePort }}`
For some reason it seems not to work