Helm-Chart-Boilerplates VS aws-helm-multi-deploy

I would point you to what I call the "Universal Helm Charts" and some examples of how to use them.

Shameless Plug: Here's one of my dashboards I made for Ingress-Nginx, which is my recommended border router/gateway into all the services. It adds deep robust metrics and configurability, and if you've got years of experience with Nginx also, it allows you rich complex customization via nginx's configuration structure via kubernetes annotations. Besides that I have open-source helm charts which are easy to use, boilerplates showing how to use them, a volume autoscaler to automatically resize your disks as they get full, and a blog where I share various of my experience which is a companion blog to my upcoming book of the same name. Hope this helps! Feel free to ask if you have any further questions.

Here is an example of a repo that uses an sub-chart: https://github.com/DevOps-Nirvana/Helm-Chart-Boilerplates/tree/master/boilerplate-apache-with-configmap-template/deployment

Use multi-values files with helm ALWAYS. Allowing an env-specific overlay to tweak your default values files. See: https://github.com/DevOps-Nirvana/Helm-Chart-Boilerplates/tree/master/boilerplate-echoserver/deployment/boilerplate-echoserver

Helm charts - https://github.com/DevOps-Nirvana/Universal-Kubernetes-Helm-Charts Example using helm charts as sub charts - https://github.com/DevOps-Nirvana/Helm-Chart-Boilerplates/tree/master/boilerplate-echoserver

Helm Chart Boilerplates are examples of usage of the above Universal Helm Charts to help people understand how to use them more, a stop-gap until I add more documentation

Helm Chart Usage Boilerplates (Examples of using these helm chart)

To help you on deploying your service, I've created open source generic/universal Helm Charts to make it easy to do the above. Here are the Universal Helm Charts and here's some boilerplate examples of using them. These built-in have support for HPAs, services, ingresses, etc, making it as easy as autoscaling.enable: true I haven't gotten around to documenting the helm charts yet, but there's lots of comments in the values.yaml file explaining everything.

To help you deploy these, your CI/CD framework or tooling needs to run helm dependencies update before it does a helm diff/update. Here's an Github Action which does this in an opinionated fashion

I think you're talking about two different things. I personally recommend hard boundaries of what your tools do. For IaC, do IaC. For services, use CI/CD. So, for all my clients, I stand up infrastructures with Terraform except for EKS, which I use EKSCTL. These tools are run very rarely, only when you need to adjust/alter/upgrade your infrastructure, but NOT your services. After Kubernetes is stood up though, managing it with Terraform is terrible. Simply use Helm via your CI/CD toolchain. Here's an Github Action my team engineered to deploy via helm recursively easily: https://github.com/DevOps-Nirvana/aws-helm-multi-deploy