How to work with multi-site projects¶
Multi-site hosting, also known as multi-tenancy, makes it possible to host multiple sites,serving multiple domains, using a single database.
Note
This is distinct from serving a single site under multiple domains - this does not requitedjango-multisite, and only requires those domains to be set up in the Control Panel.
There are two ways of achieving this:
- multiple sites, one database, one project: Django Multisite
- multiple sites, one database, multiple projects: Multiple Divio Cloud projects
Logging in to multi-site instances¶
In all multi-site projects, you will notice that each site requires its own log-in. Logging in toone will not log you in to another. This is because the Django session cookie is per-domain.
Django Multisite¶
Our Django Multisite Plus allows you to serve multiple sites under multiple domains (includingsub-domains) from a single Divio Cloud Django project.
You need to inform us about each domain to be served. We will apply the configuration required,which includes:
- installing and configuring Django Multisite Plus addon
- applying the necessary settings and environment variables
Because Live and Test servers use different domains, we provide a runtime module that sets up thedomain rewriting - via theSite
model - appropriately in each case.
This will populate the Django Sites table (Sites > Sites in the admin), and the Django MultisitePlus Sites table (Multisite+ > Sites in the admin), when the environment variableDJANGO_MULTISITE_PLUS_AUTO_POPULATE_SITES
is True
.
In this case, these auto-populated domains should not be edited manually, as any changes willsimply be overwritten at the next deployment.
Switching between sites in a multi-site project¶
Suppose you have a multi-site project example-stage.eu.aldryn.io
whose domains are configuredthus:
Site | Live | Test |
---|---|---|
Germany | example.de | de.example-stage.eu.aldryn.io |
Ghana | example.gh | gh.example-stage.eu.aldryn.io |
USA | example.us | us.example-stage.eu.aldryn.io |
On both the Test and Live Cloud servers, domain routing will be configured by us and will workautomatically.
Locally, more work is required, as each of the sites will be served at the same address (i.e.localhost
). Unlike the Cloud set-up, your local environment has no way to route differentrequests to different sites - because the request for localhost
doesn’t contain the domaininformation needed to do this.
Instead, you will need to handle multi-site routing manually.
There are two approaches you can take:
Option one: Force the site with an environment variable¶
This is the simpler method and recommended unless you need to be able to switch often between sites.
Set a local environment variable, SITE_ID
, to forceDjango to serve a particular site. The site ID you need can be found in the list of Sites in theadmin.
After changing the SITE_ID
you will neeed to restart the runserver for the change to takeeffect.
If you set explictly set the SITE_ID
this way, the next method will not work.
Option two: capture the sites’ domains in /etc/hosts¶
The other method is to point all the domains you need to handle locally to localhost
. Forexample, for each of the domains in the table above, you could add an entry in your /etc/hosts
file:
- localhost example.de
- localhost example.gh
- localhost example.us
These should match the domains as they appear in the admin at Sites > Sites.
Now, each domain will resolve to localhost
.
It will help to have your local site served on port 80, so in the docker-compose file, set:
- ports:
- - "80:80"
for the web
service.
The local Divio environment server running will now be able to use the information contained in therequest for say example.de or example.gh to serve the required site.
Using this method, you can readily switch between sites using the standard site-switchingfunctionality. The site-switching links will refer to the various Live sites, but these addresses will be intercepted by the modified hosts
file.
Note
If the port on which you access local sites is not 80, you will need to append this to theaddresses you require.
This method is more convenient if your local development work requires you to switch sites, but youmust remember to remove the entries from hosts
once you’ve finished.
Note also that if you force the site using the environment variable method, then this method willnot work.
Multiple Divio Cloud projects¶
This method involves separate Django instances, one for each site. Its advantage is that it allowsyou guarantee that each site will be served from a different instance, and it gives you morecontrol over the resources allocated to each site.
Set up your projects, including their domains, and then contact Divio support so we can configurethem all to use the same database and storage backend.
We will also advise on any other configuration you need to make.
Important
It is crucial that you ensure all the projects sharing the same database use the same code,particularly around models. Otherwise, you could run into site errors or even databasecorruption problems, if model code is not in line with database table structure.
You must take care to make and deploy code changes across sites in as consistent way aspossible.
As each project runs separately, the easiest way to work on them locally is simply to launchand stop each one as required.
原文: http://docs.divio.com/en/latest/how-to/work-with-multisite-projects.html