Tryton one install multiple instances

Dear Trytoner

I would like to know if someone have done something similar to do one simple install and use this install for multiple users. I mean somehing like

  • One OS with trytond / Sao
  • Multiple trytond.conf for different users
  • if extra / custom modules are required, then we could install in a homedir and added at the uwsgi starting file

Any suggest or comment related please if have some experiences on it

Thanks

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.

1 Like

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.

Thanks for suggests

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.

1 Like

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.

1 Like

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.

2 Likes

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.

1 Like