Open dcernoch opened 2 months ago
Andrew you bring up an important point. Who are LME's potential clients?
How many clients can one server support? What factors besides disk size have to be taken under consideration? If one server can support as many clients as we think is reasonable, then we can use that as a guideline as we move forward.
"Small" means different things to different people. We need to have a clearer definition of who we are building LME for.
Something thats always hard to determine is "how many clients can an ELK stack handle" when self hosting. Because everyone has different numbers of logs and activity, and verbosity etcetc. But typically a 16GB 4 core server should be able to handle hundreds of clients.
As long as they have enough disk space? That makes sense.
Don't know if there is something in the architecture that would need to change if LME went from single server to multi-server. There is also the issue of replicas
Although it's always tempting to make something completely scaleable, if it adds complexity we might want to deliberately start small. It's OK to say that LME is for "up to 500 clients" or something like that. We can't be everything for everyone.
Will move ticket to back log. Haven't really put alot of time on it.
We spoke about this in our TEM meeting last week. We added this as One of the features LME 2.0 will have (secure by dfault, enforce principles of least privilege across entire LME).
I do like podman as an option here as I think we can use the exact same docker compose either way and would provide rootless containers.
I also like that it appears we could use podman secrets without the use of docker swarm:
https://docs.podman.io/en/latest/markdown/podman-secret.1.html
Docker secrets requires swarm -- this would allow us to use secrets and rid ourselves of the complexity of docker swarm. Swarm is really in situations where you need scaling, load balancing etc -- and that just doesn't align with the missions of a simple one server deployment