Helmfile: Use helm's post-render to kustomize existing helm chart

[olfway]

Is it possible to use helm's post-render flag to kustomize existing helm chart?

https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render

Sometimes upstream helm chart doesn't provide the required option,
so it will be useful to be able to run kustomize on top of it

or maybe it's already possible somehow?

[dudicoco]

Using kustomize with helmfile is already supported, it's documented in the readme

[olfway]

Yep, it's documented but only for helmfile + kustomize + manifests

I want to use kustomize to change manifest rendered from a chart

For example, some upstream chart doesn't allow to set tolerations, so what options do I have?

I think it would be useful if it will be possible to render chart to manifest, then run kustomize and then deploy that updated manifest to my cluster as helm chart

[sjentzsch]

Big +1 from my side too! Would love to make use of https://helm.sh/docs/topics/advanced/#post-rendering with Helmfile, and have several use-cases myself. Post-rendering just got featured at KubeCon by the maintainers, and allows indeed keeping upstream helm charts smaller, as it will become easier to (c/k)ustomize them.

[mumoshu]

I want to use kustomize to change manifest rendered from a chart

For example, some upstream chart doesn't allow to set tolerations, so what options do I have?

@olfway Sounds like a good use-case for releases[].jsonPatches and releases[].strategicMergePatches?

[Preisschild]

@mumoshu I dont think only using jsonPatches/strategicMergePatches is as powerful as e.g. a ConfigMapGenerator

for example, I cant merge my own data to data from a helm chart in configmaps

[mumoshu]

@Preisschild I agree that patching alone isn't as powerful as the generator. So your use-case isn't fully addressed by helmfile's kustomize support, right? Helmfile does support installing any kustomization.yaml as a helm release.

Maybe you can share me an example, theoretical/ideal project structure so that I can fully understand your use-case.

[mumoshu]

If it's just that you want to add dynamically generated resources to an existing chart, you can add dependencies: ["incubator/raw"] to your release and use {{ exec ... }} template function to run any command to generate values for the raw chart :)

[maxaudron]

In my case I want to add some annotations needed by gitlab in the CI, a lot of charts don't expose that via templating, but a simple kustomize.yaml will do:

resources:
  - "{stdin}"

commonAnnotations:
  app.gitlab.com/env: $CI_ENVIRONMENT_SLUG
  app.gitlab.com/app: $CI_PROJECT_PATH_SLUG

(the environment variables are resolved in the shell in my case, just an example)
(and this also uses another PR I just made to kustomize to allow directly reading from stdin kubernetes-sigs/kustomize#3288)

I'd also be in favor of the generic approach in #1530 and will probably just write this down today.

[mumoshu]

@maxaudron Perhaps you can just use Helmfile's kustomize transformers support? https://github.com/roboll/helmfile/blob/master/docs/advanced-features.md#transformers

[artem-kosenko]

one more case. I apply the helm chart for base EKS setup from the terraform (helm_release resource). It allows to use "postrender", where I can run any binary file - bash wrapper for kustomize in my case. I would like to add few line into existed ConfigMap with the variables patterns of region name and cluster name, that helm should replace with proper values. but it is not possible this way. I get Config map deployed with the "cluster_name": "{{ .Values.clusterName }}", instead of it values.
I really surprised that it is to strict way to specify variables for kustomize during execution, or apply helm-chart after it is modified with kustomize