HowTo

How to set up Django with Postgres, Nginx, and Gunicorn on Ubuntu

HowTo, Postgres, django, gunicorn, howto, nginx, ubuntu

Install the packages from the Ubuntu repositories

Python2
1
2
$ sudo apt-get update
$ sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx
Python3
1
2
$ sudo apt-get update
$ sudo apt-get install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx

the Python development files needed to build Gunicorn later, the Postgres database system and the libraries needed to interact with it

Create the PostgreSQL database and user

By default, Postgres uses an authentication scheme called peer authentication for local connections.
Basically, this means that if the user’s operating system username matches a valid Postgres username, that user can login with no further authentication.

During the Postgres install, an operating system user named postgres was created to correspond to the postgres PostgreSQL administrative user.
We need to user this user to perform administrative tasks. We can use sudo and pass in the username with the -u option.

Log into an interactive Postgres session by typing:

1
$ sudo -u postgres psql

First, create a database for your projct:

1
postgres=# CREATE DATABASE myproject;

Next, create a databse user for our project. Make sure to select a secure password:

1
postgres=# CREATE USER myprojectuser WITH PASSWORD 'password';

We are setting the default encoding to UTF-8, which Django expects.
We are also setting the default transaction isolation scheme to read committed, which blocks reads from uncommitted transactions.
Lastly, we are setting the timezone. By default, our Django projects will be set tu use UTC.
These are all recommendations from the Django project itself.

1
2
3
postgres=# ALTER ROLE myprojectuser SET client_encoding TO 'utf8';
postgres=# ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';
postgres=# ALTER ROLE myprojectuser SET timezone TO 'UTC';

Now, we can give our new user access to administer our new database:

1
postgres=# GRANT ALL PRIVILEGES ON DATABASE  myproject TO myprojectuser;

To exit out the PostgreSQL prompt:

postgres=# \q

Create a Python Virtual Environment for your project

python2
1
2
$ sudo -H pip install --upgrade pip
# sudo -H pip install virtualenv
python3
1
2
$ sudo -H pip3 install --upgrade pip
# sudo -H pip3 install virtualenv

With virtualenv installed, we can start forming our project.
Create and move into a directory where we can keep our project files:

1
2
$ mkdir ~/myproject
$ cd ~/myproject

Create a Python virtual environment:

$ virtualenv myprojectenv

This will create a directory called myprojectenv within your myproject directory.
Inside, it will install a local version of Python and a local version of pip.

Activate the virtual environment:

$ source myprojectenv/bin/acivate

With your virtual environment active, install Django, Gunicorn, and the psycopg2 PostgreSQL adaptor with the local instance of pip:

$ pip install django gunicorn psycopg2

You should now have all of the software needed to start a Django project.

Create and Configure a New Django Project

Create the Django Project

It will create a second level directory with the actual code, which is normal, and place a management script in this directory.
The key to this is that we are defining the directory explicitly instead of allowing Django to make decisions relative to our current directory:

$ django-admin.py startproject myporject ~/myproject

At this point, your project directory(~/myproject in our case) should have the following content:

  • ~/myproject/manage.py: A Django project management script.
  • ~/myproject/myproject/: The Django project package. This should contain the __init__.py, settings.py, urls.py, and wsgi.py files.
  • ~/myproject/myprojectenv/: The virtual environment directory we created earlier.

Adjust the Project Settings

The first thing we should do with our newly created project files is adjust the settings.
Open the settings file in your text editor:
(myenv) $ nano ~/myproject/myproject/settings.py

Start by locating the ALLOWED_HOSTS directive. This defines a list of the server’s addresses or domain names may be used to connect to the Django instance.
Any incoming requests with a Host header that is not in this list will raise an exception.
Django requires that you set this to prevent a certain class of security vulnerability.

1
2
3
4
5
# the simplest case: just the domain name(s) and IP addresses of your Djanog server
# ALLOWED_HOSTS = ['example.com', '203.0.113.5']
# To responde to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP',...]

Next, find the section that configures database access. It will start with DATABASE.
The configuration in the file is for a SQLite database.
Change the setting with your PostgreSQL database information.
We tell Django to use the psycopg2 adaptor we installed with pip.

~/myproject/myproject/settings.py
1
2
3
4
5
6
7
8
9
10
DATABASE = {
    'default': {
        'ENGINE': 'django.db.backends.postrgreql_psycopg2',
        'NAME': 'myproject',
        'USER': 'myprojectuser',
        'PASSWORD': 'password',
        'HOST': 'localhosts',
        'PORT': '',
    }
}

static files is necessary so that Nginx can handle requests for these items.
The following line tells Django to place them in a directory called static in the base project directory:

~/myproject/myproject/settings.py
1
2
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

Complete Initial Pfoject Setup

Now, we can migrate the initial databse schema to our PostgreSQL database using the management script:

1
2
(myenv) $ ~/myproject/manage.py makemigrations
(myenv) $ ~/myproject/manage.py migrate

Create an administrative user for project by typing:
(myenv) $ ~/myproject/manage.py createsuperuser

We can collect all of the static content into the directory location we configured
(myenv) $ ~/myproject/manage.py collectstatic

You should have a UFW firewall protecting your server. In order to test the development server, we’ll have to allow access to the port we’ll be using.
(myenv) $ sudo ufw allow 8000

Finally, you can test our your project by starting up the Django development server with this command:
(myprojectenv) $ ~/myproject/manage.py runserver 0.0.0.0:8000

Testing Gunicorn’s Ability to Serve the Project

Ths last thing we want to do before leaving our virtual environment is test Gunicorn to make sure that it can serve the application.
We can do this by entering our project directory and using gunicorn to load the project’s WSGI module.

1
2
(myenv) $ cd ~/myproject
(myenv) $ gunicorn --bind 0.0.0.0:8000 myproject.wsgi

We passed Gunicorn a module by specifying the relative directory path to Django’s wsgi.py file, which is the entry point point to our application, uing Python’s module syntax.
Inside of this file, a function called application is defined, which is used to communicate with the application.
To learn more about the WSGI specification, click here

Create a Gunicorn systemd Service File

Create and open a systemd service file for Gunicorn with sudo privileges in your text editor:

$ sudo nano /etc/systemd/system/gunicorn.service

Start with the [Unit] section, which is used to specify metadata and dependencies.
We’ll put a description of our service here and tell the init system to only start this after the networking target has been reached:

/etc/systemd/system/guicorn.service lang: bash
1
2
3
[Unit]
Description=gunicorn daemon
After=network.target

Next, we’ll open up the [Service] section. We’ll specify the user and group that we want to process to run under.
We will give our regular user account ownership of the process since it owns all of the relevant files.
We’ll give group ownership to the www-data group so that Nginx can communicate easily with Gunicorn.

We’ll then map out the working directory and specify the command to use to start the service.
In this case, we’ll have to specify the full path to the Gunicorn executable, which is installed within our virtual environment.
We will bing it to a Unix socket within the project directory since Nginx is installed on the same computer.
This is safer and faster than using a network port.
We can also specify any optional Gunicorn tweaks here.
For exmapl, we specified 3 worker processes in this case:

/etc/systemd/system/gunicorn.service
1
2
3
4
5
6
7
8
9
[Unit]
Description=gunicorn daemon
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myproject
ExecStart=/home/sammy/myproject/myprojectenv/bin/gunicorn - access-logfile --workers 3 --bind unix:/home/sammy/myproject/myproject.sock myproject.wsgi:application

Finally, we’ll add an [install] section.
This will tell systemd what to link this service to if we enable it to start at boot.
We want this service to start when the regular multi-user system is up and running:

/etc/systemd/system/gunicorn.service
1
2
3
4
5
6
7
8
9
10
11
12
[Unit]
Description=gunicorn daemon
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myproject
ExecStart=/home/sammy/myproject/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/home/sammy/myproject/myproject.sock myproject.wsgi:application

[Install]
WantedBy=multi-user.target

We can now start the Gunicorn service we created and enable it so that it starts at boot:

1
2
$ sudo systemctl start gunicorn
$ sudo systemctl enable gunicorn

Check for the Gunicorn Socket File

Check the status of the process to find out whether it was able to start:

$ sudo systemctl status gunicorn

Next, check for the existenct of the myproject.sock file within your project directory:

$ ls /home/sammy/myproject

If you have a problem with an error or do not find the myproject.sock just check out with this command:

$ sudo journalctl -u gunicorn

If Gunicorn was unable to create the socket file, it is for one of these reasons:

  • The project files are owned by the root user instead of a sudo user
  • The WorkingDirectory path within the /etc/systemd/system/gunicorn.service file does not point to the project directory
  • The configuration options given to the gunicorn process in the ExecStart directive are not correct.
    • The path to the gunicorn binary points to the actual location of the binary within the virtual environment
    • The --bind directive defines a file to create within a directory that Gunicorn can access
    • The myproject.wsgi:application is an accurate path to the WSGI callable. This means that when you’re in the WorkingDirectory, you should be able to reach the callable named application by looking in the myproject.wsgi module (which translates to a file called ./myproject/wsgi.py)

Configure Nginx to Proxy Pass to Gunicorn

Now we need to configure Nginx to pass traffic to the process.

Start by creating and opening a new server block in Nginx’s sites-available directory:

$ sudo vi /etc/nginx/sites-available/myproject

Inside, open up a new server block.
We will start by specifying that this block should listen on the normal port 80 and that it should respond to our server’s domain name or IP address:

/etc/nginx/sites-available/myproject
1
2
3
4
server {
    listen 80;
    server_name server_domain_or_IP;
}

Next, we will tell Nginx to ignore any problems with finding a favicon.
We will also tell it where to find the static assets that we collected in our ~/myproject/static directory.
All of these files have a standard URI prefix of /static, so we can create a location block to match those requests:

/etc/nginx/sites-available/myproject
1
2
3
4
5
6
7
8
9
server {
    listen 80;
    server_name server_domain_or_IP

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/sammy/myproject;
    }
}

Finally, we’ll create a location / {} block to match all other requests.
Inside of this location, we’ll include the standard proxy_params file included with the Nginx installation and then we will pass the traffic to the socket that our Gunicorn process created:

/etc/nginx/sites-available/myproject
1
2
3
4
5
6
7
8
9
10
11
12
13
14
server {
    listen 80;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/sammy/myproject;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/home/sammy/myproject/myproject.sock;
    }
}

Now, we can enable the file by linking it to the sites-enabled directory:

$ sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

Test your Nginx configuration for syntax errors:

$ sudo nginx -t

If no errors are reported, go ahead and restart Nginx:

$ sudo systemctl restart nginx

Finally, we need to open up our filrewall to normal traffic on port 80.
since we no longer need access to the development server, we can remove the rule to open port 8000 as well:

1
2
$ sudo ufw delete allow 8000
$ sudo ufw allow 'Nginx Full'

You should now be able to go to your server’s domain or IP address to view your application.

After configuring Nginx, the next step should be securing traffic to the server using SSL/TLS.
This is important because without it, all information, including passwords are sent over the network in plain text.

If you have a domain name, the easiest way get an SSL certificate to secure your traffic is using Let’s Encrypt.
Follow this guide to set up Let’s Encrypt with Nginx on Ubuntu 16.04.

If you do not have a domain name, you can still secure your site for testing and learning with a self-signed SSL certificate.

Note

https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-16-04

Share