HOWTO run multiple Django sites under a single uWSGI instance

sean

Do you have several Django sites that run from a common codebase and want to run them from a single uWSGI instance (similar to virtual hosting in Apache)? This tutorial borrows heavily from Multiple Sites with Routing in uWSGI to show how to modify a standard Opalstack Django (or bare uWSGI) application to support multiple sites by using uWSGI's emperor mode and internal routing features.

To begin, create a shell user and a Django or uWSGI application via the control panel and add it to a site using the domains that you want to serve.

The rest of this tutorial uses the following values:

Shell user name: myuser
Application name: myapp
Application port: 55555
Domain #1: domain1.com
Domain #2: domain2.com
Project directory #1: project1
Project directory #2: project2

Be sure to replace those values with your own shell user name, app name, etc when following these steps.

Edit /home/myuser/apps/myapp/uwsgi.ini to look like this:

   [uwsgi]
   master = True
   http = 127.0.0.1:55555
   daemonize = /home/myuser/logs/myapp/uwsgi.log
   pidfile = /home/myuser/apps/myapp/tmp/uwsgi.pid
   emperor = %dvassals.d/*.ini
   route-host = ^domain1\.com$ uwsgi:/home/myuser/apps/myapp/tmp/domain1.sock,0,0
   route-host = ^domain2\.com$ uwsgi:/home/myuser/apps/myapp/tmp/domain2.sock,0,0

Create a directory named vassals.d to hold the uWSGI configuration files for each site:

   mkdir /home/myuser/apps/myapp/vassals.d

Create a new file /home/myuser/apps/myapp/vassals.d/domain1.ini with the following contents:

   [uwsgi]
   pidfile = /home/myuser/apps/myapp/tmp/domain1.pid
   uwsgi-socket = /home/myuser/apps/myapp/tmp/domain1.sock
   virtualenv = /home/myuser/apps/myapp/env/
   workers = 2
   threads = 2
   # adjust the following to point to your project
   python-path = /home/myuser/apps/myapp/domain1
   wsgi-file = /home/myuser/apps/myapp/domain1/domain1/wsgi.py
   touch-reload = /home/myuser/apps/myapp/domain1/domain1/wsgi.py

Create a new file /home/myuser/apps/myapp/vassals.d/domain2.ini with the following contents:

   [uwsgi]
   pidfile = /home/myuser/apps/myapp/tmp/domain2.pid
   uwsgi-socket = /home/myuser/apps/myapp/tmp/domain2.sock
   virtualenv = /home/myuser/apps/myapp/env/
   workers = 2
   threads = 2
   # adjust the following to point to your project
   python-path = /home/myuser/apps/myapp/domain2
   wsgi-file = /home/myuser/apps/myapp/domain2/domain2/wsgi.py
   touch-reload = /home/myuser/apps/myapp/domain2/domain2/wsgi.py

Restart the application:

   /home/myuser/apps/myapp/stop
   /home/myuser/apps/myapp/start

That's it - you're done! Requests for http://domain1.com and http://domain2.com will be routed to their respective projects, both running as workers under a single uWSGI instance.

vince

Thanks for the tutorial! I did this today and it works great.

Only a minor thing but when I run the stop script I get

uWSGI did not stop, killing it. ./stop: line 19: kill: (25080) - No such process Stopped.

I guess it just takes a little longer to stop uWSGI when it's set up like this. I edited the script and increased the sleep time on line 13 from 3 to 4 and that sorts it.

sean

vince That sounds to me like your pid (in the app's tmp directory) got out of sync somehow.

vince

Sorry if I didn't make it clear in my initial reply, I had already increased the sleep period and this fixes it.

vince I guess it just takes a little longer to stop uWSGI when it's set up like this. I edited the script and increased the sleep time on line 13 from 3 to 4 and that sorts it.

vince

Yeah it does seem a bit strange. So I checked tmp/uwsgi.pid and the pid is correct. And I ran /home/myuser/apps/myapp/env/bin/uwsgi --stop tmp/uwsgi.pid from the command line and it works fine.

Looking at the stop script and how it sleeps for 3 seconds after running /home/myuser/apps/myapp/env/bin/uwsgi --stop $PIDFILE and another 3 seconds before running kill -9 $PID I'm fairly convinced it's taking more than 3 seconds but less than 6 seconds to stop uwsgi which would cause this behaviour.

sean

vince OK, I think my procedure up there didn't take into account the fact that the vassals might take longer to shut down. Have you tried increasing the sleep period?

sean

vince My bad, thanks for sharing your fix ❤️

etienneh

Some questions about this tutorial:

It mentions project directory #1 and 2 (project1 and project2) but those are never referenced again in the domain. Is that just a typo and instead should be domain1 and domain2?
It looks like there's a file: /home/myuser/apps/myapp/domain1/domain1/wsgi.py but where does that come from? Is that your example of a Django site with it's typical double project-name folder setup? 😛
Okay, so say I'm like, "Yeah, I do want to do that, and run two django apps with a common codebase", why is there a domain2 folder? Isn't there just one codebase? Or are we assuming we've deployed the same codebase twice in two separate folders? Trying to understand what the reduced complexity is here 🤓

sean

etienneh It mentions project directory #1 and 2 (project1 and project2) but those are never referenced again in the domain. Is that just a typo and instead should be domain1 and domain2?

Probably, it's been a while since I put that procedure up. Will run through and correct as needed 🙂

etienneh Is that your example of a Django site with it's typical double project-name folder setup?

Yes, this procedure is "HOWTO run multiple Django sites under a single uWSGI instance" 🤷‍♂️

etienneh why is there a domain2 folder? Isn't there just one codebase? Or are we assuming we've deployed the same codebase twice in two separate folders? Trying to understand what the reduced complexity is here

You can install your common code in the app's virtualenv (or in a third project directory added to the Python search path) and keep the site-specific things in their individual project directories.