Create Helm Chart for K8s Deployment about lynx

[Clivern]

Hi @uvulpos, That makes sense indeed. My knowledge with Helm is limited so i need to check if is it better to have PostgresSQL as dependency to run inside the cluster? or shall i let the user to decide whether to use PostgreSQL from outside the cluster. Honestly i would feel much better having PostgresSQL outside the cluster. but if there is such a thing in helm to let user decide whether to have PostgresSQL inside or provide PostgresSQL connection string, I would like to go for it.

[uvulpos]

Hi @Clivern ,
general speaking is both possible, but it's rather common to just release your helm configuration for your applications and dependencies as postgres is managed elsewhere e.g. with an kubernetes operator. So you would need a kubernetes deployment and a service definition and place helm variables in it

[uvulpos]

I can do a basic pr to create the structure. We can finalize it later, but let's do an MVP first

[Clivern]

Yes, please feel free to open a PR.

…

On Thu, May 23, 2024 at 3:51 PM Tim Riedl ***@***.***> wrote: I can do a basic pr to create the structure. We can finalize it later, but let's do an MVP first — Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMPA6ZFF2MNA6RY27MPETTZDXX63AVCNFSM6AAAAABID6SKT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRXGE3TINRUGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ankek]

Hi there, some updates from my side. K8S is not a good place to store data. There are a lot of examples with data loss. My suggestion to use external (outside of K8S) Database and store data there to avoid data loss for Production-ready environments.

[uvulpos]

@ankek I would agree, speaking about deploying a own database. But this is not the case and not the wanted solution. If you have already deployed an application to k3s / k8s, you most likely deployed an application with some sort of need for storage. Then you either deploy a database as stateful set on a specific node on your not-production-environment, or, if you really need to scale, there are hosted databases as elastic postgres in azure (as an example). And we only ship the application. No database. So the user is responsible for how to store that kind of data and only specify the database credentials as parameter / template values

[ankek]

@uvulpos I do not argue with you. For test cases/ scenarios of course we would need DB in helm deployment. I meant that it would be great to let the people make decisions about the DB backend and its location (inside or outside K8S).
And if we are talking about the Helm chart it makes sense to have this option from the very beginning.

[uvulpos]

You can just start the DB from docker compose file in root and connect to this for testing. Why do you want to deploy a db in k8s for testing purposes. Use Kubernetes inside Docker for testing

docker compose up db

[ankek]

@uvulpos Not sure that we are on the same page. By default, Lynx Helm chart could install PostgreSQL DB as a separate pod inside the K8S cluster and configure it as the default database.

However, it is common practice to allow people to use external DB within Helm deployment. As an example, WordPress CMS
I.e. allow to decide: to use an externally managed (outside of K8S) database or use the default (inside of K8S) PostgreSQL DB. In this part, I agree with Ahmed

Honestly i would feel much better having PostgresSQL outside the cluster. but if there is such a thing in helm to let user decide whether to have PostgresSQL inside or provide PostgresSQL connection string, I would like to go for it.

From my understanding, I see a lot of benefits if Lynx has such an option in the first version of Lynx Helm Chart.

Would be PostgreSQL running in Docker, as SaaS in Azure, or some other solution? It is another question.

I have no experience with Helm Chart development but can assist with K8S deployment (i.e. prepare YAML files)

[uvulpos]

Of course, you can define the connection string as a value in helm. There is the concept of variables. But including a database is still silly for our use case and would just mean lots of extra work.

How I mentioned: you can do a simple stateful set deployment with a single node (for playing around) and put it inside the helm chart, but we can't scale anyway and so many important features as backups or different storage providers would be missing or have no support. Also, you would waste resources if every single application would bring their own database. Lynx will never be the only application inside the cluster. It would just add tickets from unsatisfied users

Victor from DOT also explained it very well:

https://youtu.be/Ny9RxM6H6Hg?si=pgNV9cjHznlEKhav

[uvulpos]

When you want to deploy a database at the same time, I would recommend helmfiles

https://github.com/helmfile/helmfile

And a postgres operator

https://github.com/zalando/postgres-operator