doc: Configuration and templating tips and tricks

[mumoshu]

Let's gather all the tips and tricks worth included in the documentation, by linking from various questions answered in this repo.

[mumoshu]

Use index .Values (requiredEnv "FOO") to get the environment value at the path determined from an envvar #755

[mumoshu]

Including an external file b64-encoded as a helm value #757

[mumoshu]

Selectively inheriting helmfile values to sub-helmfile: #725

[mumoshu]

Leveraging a sub-helmfile to differentiate template params across two or more releases #387 (comment)

[andrewnazarov]

The | trick taken from the Slack discussion

[andrewnazarov]

I've seen somewhere a dedicated block for global values, cannot find it in the current docs. It was quite close to this #640 (comment)

[mumoshu]

Pinning sub-helmfile version by @osterman:

helmfiles:
  - path: "git::https://github.com/cloudposse/helmfiles.git@releases/reloader.yaml?ref=0.48.0"

Slack: https://sweetops.slack.com/archives/CE5NGCB9Q/p1563983556083300?thread_ts=1563939458.049400&cid=CE5NGCB9Q

[mumoshu]

Conditional Release enabled if and only if specific Helmfile value is set: #784 (comment)

Probably we can add it under Environments or Environment Values sections.

[andrewnazarov]

How helmfile destroy deals with the releases order: #797

[mumoshu]

Installing Istio with Helmfile: #789

[mumoshu]

Installation ordering: #137

[mumoshu]

Inline and external template snippets for reducing code repetition: #803

[mumoshu]

Erasing environment values with layering and overrides(Use sprig's unset) #866 (comment)

[mumoshu]

Reusing template of conventional release spec with define and template: #860 (comment)

[mumoshu]

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

[mumoshu]

Reference the cluster name from kubeconfig and reuse it across releases: #852 (comment)

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}}

[mumoshu]

Helm v3: Creating and managing namespaces #891

[jurgenweber]

how to loop releases dynamically and reference a secret:

#986 (comment)

[mumoshu]

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"]

ref: https://sweetops.slack.com/archives/CE5NGCB9Q/p1572946918049300?thread_ts=1572531812.021800&cid=CE5NGCB9Q

[jurgenweber]

exec some bash inline: #1006

[Morriz]

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.

[mumoshu]

@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?

[mumoshu]

Layering values using environment values and merge #2037

[Morriz]

@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 ;)

[mumoshu]

Dynamically generating releases from environment values for DRY

#2037 (comment)

[Morriz]

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?

[Morriz]

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!

[mumoshu]

@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!

[mumoshu]

The combination of tpl and readFile would also work. I thought I've written about that too in somewhere else.

[Morriz]

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!

[mumoshu]

The use of --- for a complex helmfile.yaml template pipeline
#2036 (comment)
#1975

[mumoshu]

Please don't forget to marshal anything to YAML when making it DRY

#2019

[mumoshu]

Leveraging define and template for layering release configs #2048 (comment)

@Morriz FYI, this was what I had in my mind when I've suggested #756 (comment)