Open mumoshu opened 5 years ago
Use index .Values (requiredEnv "FOO")
to get the environment value at the path determined from an envvar #755
Including an external file b64-encoded as a helm value #757
Selectively inheriting helmfile values to sub-helmfile: #725
Leveraging a sub-helmfile to differentiate template params across two or more releases https://github.com/roboll/helmfile/issues/387#issuecomment-513737164
The |
trick taken from the Slack discussion
I've seen somewhere a dedicated block for global values, cannot find it in the current docs. It was quite close to this https://github.com/roboll/helmfile/issues/640#issue-451506618
Pinning sub-helmfile version by @osterman:
helmfiles:
- path: "git::https://github.com/cloudposse/helmfiles.git@releases/reloader.yaml?ref=0.48.0"
Conditional Release enabled if and only if specific Helmfile value is set: https://github.com/roboll/helmfile/issues/784#issuecomment-517577134
Probably we can add it under Environments or Environment Values sections.
How helmfile destroy
deals with the releases order: #797
Installing Istio with Helmfile: #789
Installation ordering: #137
Inline and external template snippets for reducing code repetition: #803
Erasing environment values with layering and overrides(Use sprig's unset
) https://github.com/roboll/helmfile/issues/866#issuecomment-533748904
Reusing template of conventional release spec with define
and template
: https://github.com/roboll/helmfile/issues/860#issuecomment-532465422
Referencing the release name from other releases, without release templates:
{{ $db_release := "mydb" }}
releases:
- name: {{ $db_release}}
chart: charts/db
- name: app
chart: charts/app
values:
- db:
host: {{ $db_release }}:3306
Ref: https://sweetops.slack.com/archives/CE5NGCB9Q/p1568910579018700
Reference the cluster name from kubeconfig and reuse it across releases: https://github.com/roboll/helmfile/issues/852#issuecomment-533782003
clustername.sh
:
#!/bin/bash
set -e
KUBE_CONTEXT=${KUBE_CONTEXT:-$1}
kubectl config view > kubeconfig.tmp
KUBECONFIG=kubeconfig.tmp
if [ ! -z "$KUBE_CONTEXT" ]; then
kubectl config use-context $KUBE_CONTEXT 1>&2
fi
kubectl config view --minify -o jsonpath='{.clusters[*].name}'
rm kubeconfig.tmp
helmfile.yaml
{{ $cluster := exec "bash" (list "clustername.sh") }}
releases:
- name: datadog
chart: stable/datadog
values:
- datadog:
tags:
- cluster:{{$cluster}}
Helm v3: Creating and managing namespaces https://github.com/roboll/helmfile/issues/891
how to loop releases dynamically and reference a secret:
https://github.com/roboll/helmfile/issues/986#issuecomment-555792108
Adding annotations with a post-sync hook:
hooks:
- events: ["postsync"]
command: "/bin/sh"
args: ["-c", "kubectl annotate --overwrite --namespace={{`{{ .Release.Namespace }}`}} DaemonSet/{{`{{ .Release.Name }}`}}-agent secret.reloader.stakater.com/reload=kiam-agent-certificate-secret,kiam-ca-cert"]
- events: ["postsync"]
command: "/bin/sh"
args: ["-c", "kubectl annotate --overwrite --namespace={{`{{ .Release.Namespace }}`}} DaemonSet/{{`{{ .Release.Name }}`}}-server secret.reloader.stakater.com/reload=kiam-server-certificate-secret,kiam-ca-cert"]
exec some bash inline: https://github.com/roboll/helmfile/issues/1006
Hi @mumoshu do you think it would be possible to extract a large variables assignment snippet (like some complex nested loops to generate a dict or list) somewhere to be reused? So that I don't have to copy paste that all over the place? Like an import that pulls in a precreated variable.
@Morriz We don't have a way to define custom function so I'm afraid it isn't possible. Perhaps you get similar outcome by using {{ define }}
and {{ template }}
by go template?
Layering values using environment values and merge
#2037
@Morriz We don't have a way to define custom function so I'm afraid it isn't possible. Perhaps you get similar outcome by using
{{ define }}
and{{ template }}
by go template?
Thanks for the suggestion, but I tried that and it does not work. Maybe I am doing it wrong? Would love to get a working snippet ;)
Dynamically generating releases from environment values for DRY
https://github.com/roboll/helmfile/issues/2037#issuecomment-1009375418
but that is not even coming close to defining a reusable template imo...or do I fail to see how? Anyway, I guess it's just not possible but can we just say so? For those reading this one day?
The one solution that is possible is creating a folder with snippet files, each containing the template, and then use tpl
with readFile
, but that means one snippet per file which is a bit of a bummer. But hey, it's functionally the same!
@Morriz Sorry it wasn't meant to be a reply to you. I've already written tricks to use template/define somewhere else so perhaps you'd better search for it in github search!
The combination of tpl and readFile would also work. I thought I've written about that too in somewhere else.
hah, tnx for the quick reply...I guess we covered it extensively now. And yes, I read that from you once I believe.
Moving on!
The use of ---
for a complex helmfile.yaml template pipeline
https://github.com/roboll/helmfile/issues/2036#issuecomment-1010503017
Please don't forget to marshal anything to YAML when making it DRY
Leveraging define
and template
for layering release configs https://github.com/roboll/helmfile/issues/2048#issuecomment-1013664264
@Morriz FYI, this was what I had in my mind when I've suggested https://github.com/roboll/helmfile/issues/756#issuecomment-1008691053
Let's gather all the tips and tricks worth included in the documentation, by linking from various questions answered in this repo.