Question

How to deploy multiple Django apps (as subdomains) using nginx and Gunicorn

Posted February 9, 2019 8.4k views
NginxDjangoUbuntu 18.04

I have a new 18.04 Droplet running a Django website on nginx. I’d like to use this droplet to serve several websites at subdomains. I have successfully:

  1. Followed this excellent tutorial to set up my first website: https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-18-04

  2. Configured nginx and DNS to serve (static) websites & subdomains on this server

  3. Set up a second Django app that I can run on port 8000, using Gunicorn as a console process

So where I’m hung up is what I add to the systemd configuration? I tried copy/pasting the [Service] block for my new site but when I try to restart gunicorn I get this error:

systemd[1]: gunicorn.service: Service has more than one ExecStart= setting, which is only allowed for Type=one

Should I create a second *.service file in /etc/systemd/system/? Is there some way to put multiple Django apps into one ExecStart directive? Each app runs in its own virtual environment.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
2 answers

I believe you need to create multiple socket and service files.

  1. I created a separate *.service and *.socket file for each web app
  2. I changed the WorkingDirectory and ExecStart values in the *.service files appropriately

Then I was able to host multiple django projects, each one with a different domain.

From my surface understanding, the process goes something like this. Nginx listening on port 80 receives an HTTP request. This request includes a Host header, which includes myDomain.com. Nginx then looks through it’s sites-available configs for a site that accepts myDomain.com. If it finds one it will look at the appropriate location section in the config file. In my case this includes

proxy_pass http://unix:/run/[MySockFileName].sock;

Some kind of information is then pushed into the unix socket file, named [MySockFileName].sock, inside the /run directory. SystemD notices this and starts up gunicorn if it’s not running already. Gunicorn consumes the information in the socket and after that magically runs python and sends you a rendered web page.

If you find best practices on this for production please let me know.

Thank you so much BenSa! This got me on the right path. I’m not sure if this is “best practices” but it works.

It helps to walk through DO’s tutorial (linked above) but substitute a handle for the subdomain for gunicorn. So for a subdomain foobar.example.com:

File /etc/systemd/system/foobar.service:

[Unit]
Description=gunicorn daemon
Requires=foobar.socket
After=network.target


[Service]
User=myUserName
Group=www-data
WorkingDirectory=/home/myUserName/foobar
ExecStart=/home/myUserName/foobar/.env/bin/gunicorn \
    --access-logfile - \
    --workers 3 \
    --bind unix:/run/foobar.sock \
    foobar.wsgi:application

[Install]
WantedBy=multi-user.target

File /etc/systemd/system/foobar.socket:

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/foobar.sock

[Install]
WantedBy=sockets.target

File /etc/nginx/sites-available/foobar:

server {
    server_name foobar.example.com;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/myUserName/foobar;
    }
    location / {
        include proxy_params;
        proxy_pass http://unix:/run/foobar.sock;
    }
}

Make sure to symlink the nginx site file:

$ ln -s /etc/nginx/sites-available/foobar /etc/nginx/sites-enabled/foobar

And enable the socket for the subdomain:

$ systemctl start foobar.socket
$ systemctl enable foobar.socket

Each socket is its own service. So if I need to restart the foobar site (for example after updating views.py):

$ systemctl restart foobar
  • That’s exactly what I did. I’m glad I could help.

    This does run multiple instances of gunicorn. As for best practices, I was concerned this was not how it was designed. But I found this section of the documentation which mentions multiple instances

    http://docs.gunicorn.org/en/latest/settings.html#proc-name

    I’ve also seen older gunicorn/nginx configurations that used one gunicorn socket for multiple domains (so separate services files but one socket). This would reduce the number of gunicorn instances. But I’m not sure if it’s better to have many instances of gunicorn or fewer instances with more workers. Good luck

Submit an Answer