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 (https://github.com/fluxcd/helm-controller/pull/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 https://github.com/argoproj/argocd-example-apps/issues/103#issuecomment-990793051.

[sylvainOL]

Any news on this? What can I do for help?

[vl-kp]

i have used both fluxcd and argocd in prod environment, i can see the only disadvantage of fluxcd is the UI

[gtirloni]

I'm facing a situation where we can't upgrade an umbrella chart that uses another umbrella chart that uses another chart. All of them outside our control.

So I need to run kustomize on the output of helm to patch a deployment. It works great locally but I couldn't find a way to specify a post-renderer in my ArgoCD application.

[rwojsznis]

For anyone coming from search - there is a argocd-lovely-plugin that seems to be solving same-sish issue 🤔 I'm not affiliated with it nor tried it yet, but looks quite interesting

[crenshaw-dev]

In general I think CMPs are a great way to do this, and argocd-lovely-plugin is a lovely example.

@sathieu regarding patches support, I have an open PR, just don't have time to write unit tests for it.

@sylvainOL regarding how to help, imo adding post-renderer support in the "native" Helm functionality would require a full proposal, especially focusing on how to configure and run post-renderers in a way that is secure on a multi-tenant repo-server instance. My guess is writing and, especially, implementing that proposal will be a lot of work.

[mtrin]

it's nice to have the possibility of plugins but I can't help but feel like I'm "patching" ArgoCD to make it do something. Sometimes I feel stuck going in circles between Helm and Kustomize trying to overcome reusability. To be fair Kustomize itself has many gaps, poor documentation and needs lots of work from Kubernetes SIGS. Which is why I think FluxCD made its "own", to make it easier for Gitops. The worse are the overlays with Helm. It would be awesome if we could easily track Helm semver, overlay values AND be able to transform additional manifests in Kustomize in a not-so-daunting way. I believe Helm should be as fully featured as possible, same for Kustomize, out of the box - or at least we should have a feature flag so we can use at our own risk. It would be good if ArgoCD plugins fully supported the new Kustomize KRM conventions, last I tried I couldn't make it run because of container exec issues. I had to "hack" the repo-server to use kustomize local exec plugins that might get deprecated by SIGS.

[s-silvius]

Evaluating Argocd vs Flux and this may turn us to Flux.

[jdeus]

Any update?