Building a multitenant application with Django
1 like329 views
The document outlines the process of building a multi-tenant application using Django, explaining key concepts like multi-tenancy, and different SaaS models (IaaS, PaaS, and SaaS). It discusses various approaches for tenant data management, including shared and isolated database schemas, and describes the necessity of creating tenant-aware models. Additionally, it provides practical guidance on identifying tenants via subdomains and isolating their data in administrative views.
Building a multitenant application with Django
- 1. Building a Multi-tenant Application with Django. Adedapo Adedamola @dexbeulah_ Data Totems
- 3. Glossary • Database – collection of structured data to model reality in a way that support processes requiring information. • Schema - refers to the set of formulas or “rules” imposed on data in a database to be organized into a certain way. • App server – is a distributed network that provides the business logic for an application.
- 4. What is Multi-tenancy? • Multi tenant applications allow you to serve multiple customers with one install of the application. • It is the ability to run one instance of an app, and serve it to multiple distinct end user. Each one of them is isolated from the other in terms of performance & data-leads.
- 6. Iaas • Iaas – Insfrasture Application as Software. • This is the tenancy model created by virtualization, and it is the ability to carve large large server into multiple virtual machine. App 1 App 2 App 4App 3 Host OS Hypervisor it - centric
- 7. Paas • Paas – Platform as a Service. • This is a better way of hosting a co-habiting Apps rather than dedicating a whole OS instance to them. OS OS OS OS Component
- 8. Saas • Saas – Software as a Service. • It is the ability to run a single instance of an app that serves multiple distinct end users. Each one of them is isolated from the other in terms of performance & data- leads. APP 1 T 1 T 2 T 3 User User User User User User User User User
- 10. Saas • Benefits: • Reduce infrastructure costs by sharing hardware resources. • Simplify software maintenance by keeping a single code base. • Simplify infrastructure maintenance by having fewer nodes. App management is once. Monitoring is once. QA is once.
- 11. Multi-tenancy • Approaches: • Shared database with shared schema • Shared database with isolated schema • Isolated database with a shared app server Argh! Django again…
- 12. Crash course on Django:
- 13. Shared database with shared schema
- 16. Adding multi tenancy: • python manage.py startapp tenants • Create a model for storing Tenant data. • TenantAwareModel class will be subclass from.
- 17. Adding multi tenancy: • Poll.model subclassing TenantAwareModel
- 18. Identifying tenants: • Giving each tenant their own subdomain. • abc.example.com • xyz.example.com • This will be will have a subdomain_prefix which will identify the tenant.
- 19. Extracting tenant from request: • Utils.py
- 20. A detour to /etc/hosts: • C:WindowsSystemsDriversetchosts
- 21. tenant_from_request in the views: • Function based || Class based || Django rest framework
- 22. Isolating the admin: • Get_queryset: so that only the current tenant’s objects show up. • Save_model: so that tenant gets set on the object when the object is saved.
- 23. Limitation: • Weak separation of tenant’s data. • Tenant isolation code is intermixed with app code. • Duplication of code.
- 24. QUESTION(S)?
- 25. Shared database with isolated schema
- 26. What to do? • Map tenant to schema • Manage database migrations • Tenant separation in views • A middleware to set schemas • Add get and set methods to utils.py
- 27. • Mapping tenant to schema Mapping tenants to schemas for easy routing
- 28. • Manage database migrations • Tenant separation in views • A middleware to set schemas • Add get and set methods to utils.py CREATE SCHEMA IF NOT EXISTS potter SET search_path to potter We make manage.py schema aware, therefore, it create schema according to the tenant in case it never existed, and set search_path tenant accordingly.
- 29. • Tenant separation in views • A middleware to set schemas • Add get and set methods to utils.py The following methods allow us to get and set the schema.
- 30. • Tenant separation in views • A middleware to set schemas Separating the tenants in the view.
- 31. • Tenant separation in views • A middleware to set schemas Separating the tenants in the view.
- 32. • A middleware to set schemas
- 33. Make admin.py aware of the shared schema Separating the admin page for tenant.
- 34. Isolated database with shared app server
- 35. Multiple database support in Django: To read poll from thor: Poll.objects.using(‘thor’).all() But we’d rather avoid code duplication, therefore use db routing
- 36. DB_ROUTERS settings take a list of classes which implement a few methods. A router class looks like this. DB routing: But none takes an argument, therefore, we cannot call tenant_db_from_request We use threadlock variables to calculate DB to use, pass it to the router
- 39. Content credit: Django Multi Tenant Application documentation. https://books.giliq.com/projects/Django-multi-tenant/en/latest Demo: https://github.com/agiliq/building-multi-tenant-applications-with-django/tree/master/isolated-db Memes credit: Ajakaye Paul E-mail: dexbeulah@gmail.com
- 40. THANK YOU