This message was deleted.

Hi, we needed something similar a while ago, we went with a library chart to hold all reusable templates (in the form of helper functions) and generic helper functions. All charts have a dependency on this library (incl. the umbrella chart as that has a few templates itself). The charts then still do need template files but they're usually just 1 line to include the library function that renders this template. For the values files, we put some defaults with all the individual charts already, so the umbrella chart only needs to override values that are specific to a certain environment/deployment, and have some values for its own templates. For testing the library with

helm unittest

we created a dummy chart, with templates that call all the library functions so we can assert their expected behavior (e.g. using equality, regexes, or paths in the rendered yaml that should or should not exist). The other individual charts also have some tests, but only for logic that doesn't come from the library. Versioning is something to think about, especially when individual charts (and library chart) also get released/used separately, next to the umbrella chart.

I don't suppose you could share an example?

No, sorry... But I can recommend to make a very small test setup / PoC, and discuss with the team if this would be a desirable direction to go into. It's slightly more complicated but that's the trade-off with duplication. In our case the individual service charts were already a bit more complex than just the result of "helm init", so it was really worth it to make that logic reusable. For example, we have a helper function in the library chart to just render an init container section that we can use (behind a "feature toggle" (fancy word for

if

statement)) in any deployment template of any of the service charts.

Makes sense

You could try kustomize https://kustomize.io to provide a base template

@Jacob Hodges I actually just published this recent article on solving that class of problem. We open sourced all the tooling that does the k8s config generation & overriding of base workloads. Eg you can use a base template that works for most apps and then only change a few parameters per app, eg like docker image, resource requirements, and then easily have them all packaged for deployment. https://medium.zeus.fyi/hosted-docusaurus-in-5-minutes-and-under-10-month-af999d7ef90a

So I have this same use case (down to even using Azure Pipelines) and I decided that going with Argo Appsets was a great idea. We can reuse the same chart for every service, and use the matrix generator to generate all the combinations of service/environment that we need.