Question

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

Posted February 9, 2019 21.9k 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.

×
Submit an Answer
4 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

  • Axoplasm & BenSa, I really appreciate your tips.

    I’ve spent a lot of time finding out how to run 2 instances of gnunicorn and for me that was the trick:

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

    I didn’t know that is needed to use systemctl to run the socket.

    Thank you guys!

Hi,

I was wondering why we need a separate socket file. This tutorial https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-16-04#create-a-python-virtual-environment-for-your-project does not mention about the socket file, only the service file.

Regards

by Justin Ellingwood
Django is a powerful web framework that can help you get your Python application or website off the ground. Django includes a simplified development server for testing your code locally, but for anything even slightly production related, a more secure and powerful web server...

Muchas gracias a todos por el aporte, me ha servido mucho!!