Support helm post renderers

[tkinz27]

Summary

Helm 3.1 added support for Post Renderering. This is the helm developers solution for last mile configuration, for instance with kustomize. See https://helm.sh/docs/topics/advanced/#post-rendering

Motivation

I would like to use this to kustomize some helm charts that do not quite support what I need. For instance the stable/jenkins helm chart does not give me the ability to add additional paths to the ingress object. Using the post renderer we could use kustomize to patch the ingress with additional paths such as a redirect from port 80 to 443 with the alb ingress controller.

Proposal

I think the Application's helm section could be extended with a postRenderer section. There probably be some gotchas with ensuring the post renderer was available inside the argocd-repo-server but I do not believe this would be any different than custom config management plugins.

edit: It would also be nice if this supported kustomize nicely. Checking out https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render it seems like they needed to wrap kustomize in a script that wrote out the templated helm, then applied kustomize to it.

[mzahorik]

A concern with this is the colocation of both helm charts and kustomize files in the same spec.source.path. Worse yet if you have directory.recurse set to true. I believe the (default?) behavior of ArgoCD is to scan for Chart.yaml | kustomization.yaml | whatever else and react accordingly.

You would need to add spec.source.helm.path and spec.source.kustomize.path fields to kind: Application.

If I understand the argo helm processs, it runs helm dependency build in a working directory, then helm template release.name path to render YAML, which it then uses to run a sync.

In this case, you'd run helm dependency build, then change the working directory to spec.source.kustomize.path, then run helm template release.name /absolute/path/to/charts with the postRenderer option, then use the resulting YAML to run a sync.

Given this more complex workflow, I'd argue that a flag such as spec.source.helm.kustomizePostRenderer with true or false (default) is more appropriate than allowing the user to specify an arbitrary value to postRenderer

[mzahorik]

I found this which should address this issue:

https://github.com/argoproj/argocd-example-apps/tree/master/plugins/kustomized-helm

[amalagaura]

Duplicated by #3882

[kristofferlundberg]

I found this which should address this issue:

https://github.com/argoproj/argocd-example-apps/tree/master/plugins/kustomized-helm

This works great for Helm Charts stored within the git repo, but if you have dependencies to external Helm Charts, you run into issues, since the Helm Repositories are not available in the environment where the plugin is running.

Finding a more out of the box solution for transforming the rendered Helm Charts with Kustomize would be great, just like you suggested above, @mzahorik !

[gw0]

I noticed that Flux v2 supports defining postRenderers and their configuration directly in the HelmRelease CRD (equivalent to Application). If I understand correctly, kustomization.yaml, overlays, and all referenced files need to be embedded in the CRD. This is probably not so bad if they are small one-off patches, but can represent a lot of copy-pasting if you want to re-use some overlays.

• https://fluxcd.io/docs/components/helm/helmreleases/#post-renderers

[cbl315]

Mark.

[cbl315]

Is there any update about post render?

[yosefy]

as i understand this feature is meant to keep helm installed versions in cluster
but as argo only uses helm for templating? i guess it is less important.
so the main thing is to just to apply kustomize after helm

which is really very needed feature

thanks

[andrein]

Have you considered using the Helm generator in Kustomize? https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md

Only needs kustomize.buildOptions: --enable-helm in the argocd configmap.

[pbecotte]

The helm generator in kustomize has a drastic weakness- there's no way to use kustomize patch files against the values.yaml. So I wind up with a huge copy-pasta values.yaml file in every overlay. If you don't need that, its pretty great- but am in the process of moving my test project back to native helm because of the problem. Would love post renderers.

[sathieu]

I think ArgoCD should focus on implementing the most used kustomize features, in the same way as flux (fluxcd/helm-controller#202). At least, support for patchesStrategicMerge and patchesJson6902 :

  postRenderers:
  - kustomize: 
       patchesStrategicMerge:
       -  kind: Deployment
          apiVersion: apps/v1
          metadata:
            name: metrics-server
            namespace: kube-system
          spec:
            template:
              spec:
                tolerations:
                - key: "workload-type"
                  operator: "Equal"
                  value: "cluster-services"
                  effect: "NoSchedule"

As I needed this feature immediately, I've used a workaround in kubitus-installer as explained in argoproj/argocd-example-apps#103 (comment).