For ERPNext: Which is better Multi Tenancy or Multiple Instance?

Install / Update Deployment
,
1

I have a need to setup multiple ERPNext on same VPS, each linked to a separate sub domain and each will have their own SSL using Lets Crypt.

In case of multiple instance we will get multiple Frappe instances but in case of multi tenancy there is only one instance. So logically it feels multi tenancy is resource friendly.

But when it comes to performance over period of time with many users will multi tenancy stand rock solid?

Experts on this please share your insights and help me decide which way to go.

Regards,

1 Like
2

You can try with Press

1 Like
3

There was a PR review system that was running on a Kubernetes cluster [For Developers] Help us develop the PR Review System

4

I copied the useful parts from PR Review System into a Kubernetes api/operator + Frappe Framework app. It works on Kubernetes only.

In brief,

  • It can create container images from frappe framework, apps and branch combination. (it was used to create a frappe-bench from frappe or erpnext fork branches for PR review system)
  • It can execute any bench commands as kubernetes jobs. e.g. new-site, migrate, set-config, custom-command.
  • It can create ingresses pointing to benches, e.g. it created an ingress route for the sub-domain/domain combination as per the PR to be reviewed.

If you already use Frappe framework apps or ERPNext on Kubernetes, it is as easy as installing a Helm Release on your Kubernetes cluster and then operating the benches and sites from familiar Frappe Framework App (use System Manager role)

K8s Bench Interface - Frappe Framework App (Useful and familiar for frappe framework developers)

https://castlecraft.gitlab.io/k8s_bench_interface

Kubernetes API + Operator (FastAPI, Kopf, python kubernetes client):

https://k8s-bench.castlecraft.in

2 Likes
5

Thanks.

I know about Press. But my question is whether we should take the route of creating sites or creating separate instances for each different sub-domain?

Regards,

6

If each site needs different app or different branch of the app then you will need multiple benches.

If one app is going to run on multiple sites and change in app code specific to site is not required then you can have 1 bench and multiple sites.

2 Likes
7

@revant_one How do you manage multiple sites when you need to “migrate” database changes? Each site has it’s own database and running “bench --site all migrate” for a few sites is OK, but if you have 100 sites, for example, I think this could take a while, no?

What’s the best strategy to reduce database migration time during updates?

8

In brief,

  • create new bench. Run old and new bench in parallel
  • backup site
  • move site from old bench to new bench and migrate.
    • if migrate succeeds, repeat for other sites
    • if migrate fails, move back the site to old bench and drop and restore to backed up database

After this you’ll have set of sites with issues on old bench and migrated sites on new bench.

3 Likes