I am not sure, what architecture / which way to go for the persistent data of my docker Swarm SaaS webapp.
A draft of the layout with traefik_proxy and some context for a better understanding of my needs can be found in the diagram: colorful draft of the layout with requirements
- Shall I go with NFS or with glusterfs for the file uploads (=files, attached by the users of the tenants/projects)? - or, is there another, free of charge solution one can recommend for providing the web-app-containers (docker Swarm) with the consistent, tenant-specific files like explained in the linked draw.io diagram?
- I am using mariadb for storing the data needed to create the threads and its content (=the posts): is galera the right solution
- And: shall/can I use the same servers for the file uploads I use for the databases (at least for the beginning)?
USECASE for the SAAS The SAAS is a Client-Server LAMP web-app running on docker, comparable to a discussion board, with different threads for the different deliverables of the project & with the option to upload files. (Related to the subject these files could be bigger (eg if the project is a movie) or smaller (like in most projects, some diagrams, office files, code snippets...))
- A PROJECT MANAGEMENT / TEAM COLLABORATION WEB APP RUNNING ON DOCKER CONTAINERS
- Should be scalable and ready to handle 100.000 projects with an average of 5 project-workers posting and reading messages and uploading files (attachments with their postings)
- Needed to run on "My own" servers (= NO AWS, NO AZURE, NO XYZ-cloud, but on my own "Managed Servers" or VPS)
- Highly Available (HA-solution)
- Very Secure (eg via individual namespaces and networks to separate the access permissions between the tenants or regularly made backups via mysqldump → cURL to 2 backup-servers, same for the uploaded files eg via cronjobs)
- Very low waiting times for the CRUD operations: browsing through the threads must be flawless/the way we expect it to work for not to feel disrupted in our workflow today (= below 5 seconds, better below 2 seconds).
