We avoid such infrastructure and prefer to have one installation per database. This is because otherwise it makes the update job much more difficult as it must be done all at once.
Yes
I am planning to use Tryton as a SaaS on a standard basic install for more than one customer. That is the reason on looking a way to do it as simple as posible, I mean, I am trying to plan to update as simple as posible.
I guess having one install per database, will implies to update code on each install, after version upgrade, and later run database upgrade on each database, probably one install for all databases, considering this way on install is focused on a standar install with no customized data or modules.
Depending on the number of database and their size, you may have a downtime quiet long. Also if one database fails to update for any reason, all this other may be blocked.
About keeping the installed code up to date, I would suggest to look at docker images. This is a way reuse the same code but deploy separately.
Iâm in this business and can share my experience (and tool eventually).
Iâm currently moving from what you try to do âget your tryton on lineâ , to âget your own Saas to distribute Trytonâ
As a first feed-back, I would say the more separated you go, the better.
A big step is always more difficult than looping on a simple one.
This is a perfect example to start using containers. Even better use a set of containers. Look at Podman to create rootless containers and sets (pod) of containers (Tryton, Postgresql, storage, etc), so no Docker is needed. With this, you can basically replace the Tryton container with a new one, run a database upgrade and of you go.
The same pod can be used again for another user. So upgrading one user will not affect others. You can also have one database server on your system and only run for each user Tryton in the container and add the user-specific data also from your system. This is a more simple approach.
Also be sure to take backups during operation which are tested and working.
Very small sidenote:
When Tryton is used be aware that it can become âmission criticalâ and that hardware failure must be taken into account. For the future, better create a cluster of machines and a loadbalancer for switching between the machines when one fails. Keep in mind the synchronization between the machines, mostly the database.
I both use multi-tenant servers, inside an LXC infrastructure.
When a single customer needs n services they can co-exist in a single LXC container.
An LXC container is an administration unit, whose root password can be given to the customer.
I use proxmox to set the network and monitor resources.
I donât use high-availability capabilities and no online synch. I re-invented my own clustering tool
Today I run up to 100 LXC containers and 50000 databases with occasional load per server for classrooms.