Helm chart for Kubernetes

[shairozan]

Summary

The manifests were a good starting point, but there's a lot of variances that need to be accommodated for:

• NGINX as an ingress controller won't be everyone's preferred. Most people default to the K8s native ingress controller
  • This is because most cloud integrations (ACM Certificates in AWS, DNS Integration) etc work via annotations on the controller
• Users should have the option to either run the DB in K8s or just provide a connection string
• Users should have the option to either run redis in K8s or just provide a connection
• Scaling a resiliency should be an option
• I still need to verify if the requests / limits are appropriate to avoid memory pressure termination of the services
• The option of using NFS file systems for the docker-data and the server-data volumes should be an option
  • If that's not used, and a volume from a PVC is used, an init container should be added to the server to chown the volumes recursively

Raw manifests are opinionated, but helm lets a user provide some answers to questions in the values.yml file that conditionally applies manifests based on that input. the only better option would be building an operator (since it controls upgrades as well) but that's a tremendous undertaking. Makes more sense to start with helm and move that way.

Questions for the Community

1. What cloud providers are you using (since this will drive how many api specs need to support custom annotations in helm)
2. What ingress controller are you using
3. Can you list any cloud integrations you have such as:
   4. Load balancer integration
   5. DNS integration
   6. Volume / NFS integration

[cfossto]

I am interested in developing a Helm chart to this project. Just found you, but it seems like an awesome application for my own business. We will try it out in the coming months (we are also looking to probably add some integrations as well, if we are allowed).

Helm charts can be done in an opinionated way with the option to override default variables via a "values.yaml" file. I need to study the code base a bit more, but the Helm chart could be agnostic regarding Loadbalancers, Ingresses, DNS and Volume/NFS. This can be directed via conditional logic in templates. Even DBs can be chosen via conditionals in templates.

In the best of cases you are serving the application with Nginx as a foundation to access the application. You don't have to decide about the end-user's ingress controllers or anything. You can use an ingress controller in front, which routes to a service which in turn routes to your nginx-"proxy"- which serves your application.

Regarding Request quotas and limits, that is often left to the end user to decide. This can be set to a default value (but should probably not really be set by the application) and/or be left to the enduser to alter in a "values.yaml"-file.

I need to study the code base and the way the application is deployed right now. Might take some time, but I will return shortly and see how much time I can put in to this. Because this seems to be a really good application and I like it a lot.