Hi yall - I've got a question for anyone here - How would I handle utilizing garden with a Helm Chart that encompasses all of my services? For example...

chart/templates/service-a
chart/templates/service-b
chart/templates/service-c

And we have a monorepo that is home to all our services, which look something like:

packages/service-a
packages/service-b
packages/service-c

Right now the chart is really only used in production, and for dev we have garden setup using Container Modules for each of our services (rather than Kubernetes or Helm). The plan is to make the helm chart flexible enough for both prod and dev, and Garden could use Helm Modules against it. I'm trying to steer clear of completely renovating the helm chart and not separate each service into it's own chart, I think that'd be the cleanest solution, but it would be a large lift that I don't think we're ready for, is there possibly an in-between solution that you can think of or have experience with in the past? Or even a public repo I could reference would be awesome!

I would: - Create the Helm chart so is reusable for all the microservices, a good example of this is a [go-seed](https://github.com/garden-io/go-seed) I created a while ago, where basically we are using Helmet (helm library) that is a really nice Helm chart that supports all the configuration you might need for all your services. - Now you can do a folder structure like:

helm_chart/Chart.yaml
services/{service-a,b,c}.yaml # This is going to be the Garden helm module to deploy the services using the same Helm chart.
project.garden.yaml # This file would have the providers config, and any variables you might need to reuse across the board.

This is just my opinion, there might be better ways to handle this

Hey Shanky, thanks for the suggestion. I like the idea of using something like

helmet

- that's a pretty nifty Helm library. However, I think it's outside the scope of this conversion. Our Helm chart is HUUUUUUGE and complex (lots of conditional templating), and an effort like converting all of our helm files to

helmet

would be a big undertaking and could take roughly 2-4 weeks. I'm trying really only to focus on the "let me get garden running against my existing helm chart without making too many changes to the chart" 😂 I think the question to ask is, is it even possible for Garden to run an individual service against a multi-service helm chart. What I was thinking was, disabling all template files (services) by default, and when garden wants to deploy a service, or multiple, it sets an enable-flag against the values file (

services-a.enabled=true

). This does feel pretty unconventional I will admit, but I'm trying to find a balance between getting garden to utilize our Helm Chart, and not completely rebuilding our Helm architecture.

Yes, you can do that with Garden, just turn off all the feature flags in your default values files and then you can deploy with Garden Helm module turning the feature flags on that you will need for each service! At the end, this is just your regular helm, nothing crazy going on on the Garden side!

Is it possible to have a garden file (helm module) per service though? Or would it just be one giant Garden helm module file? That way at the service (package/service-a) level I'd have a garden file, with service-specific values. Does that make any sense, sorry, I'm a still a bit of a garden noob.

Yes sir! You can have multiple garden modules per service! Just do a nice folder structure that makes sense for the use case the only requirement is that you run garden where your project.garden.yaml is then you can do folder recursion! I mean, Garden is so powerful that you can even call modules from different repos using remoteSources

Thanks @bright-policeman-43626 - I was able to get something going, and looks like it's working just fine. I have enough info to close this ticket. 🙂

I'm glad I could help!

@bright-policeman-43626 Thanks for your suggestions!