How to Setup Django Development Environment on Ubuntu 18.04

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 is required (Nginx - Apache).

In this guide, we will demonstrate how to install and configure some components on Ubuntu 18.04 to support and serve Django applications. We will be setting up a PostgreSQL database instead of using the default SQLite database. We will configure the Gunicorn application server to interface with our applications. We will then set up Nginx to reverse proxy to Gunicorn, giving us access to its security and performance features to serve our apps.

Create non-root user with sudo privileges configured

  1. Logging in as root
  2. Creating a new user
    # adduser bobby
  3. Granting Administrative Privileges
    To add these privileges to our new user, we need to add the new user to the sudo group. By default, on Ubuntu 18.04, users who belong to the sudo group are allowed to use the sudo command.

    # usermod -aG sudo bobby

Install the Packages from the Ubuntu Repositories

To begin the process, we'll download and install all of the items we need from the Ubuntu repositories. We will use the Python package manager pip to install additional components a bit later.
We need to update the local apt package index and then download and install the packages. The packages we install depend on which version of Python your project will use.
Installing Django with Python 3, type :

$ sudo apt-get update
$ sudo apt-get install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx

This will install pip, the Python development files needed to build Gunicorn later, the Postgres database system and the libraries needed to interact with it, and the Nginx web server.

Create the PostgreSQL Database and User

We're going to jump right in and create a database and database user for our Django application. 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 installation, an operating system user named postgres was created to correspond to the postgres PostgreSQL administrative user. We need to use 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 :

$ sudo -u postgres psql

You will be given a PostgreSQL prompt where we can set up our requirements.

First, create a database for your project

Postgres=# CREATE DATABASE newproject;

Note: Every Postgres statement must end with a semi-colon

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

Postgres=# CREATE USER newprojectuser WITH PASSWORD 'password';

Afterward, we'll modify a few of the connection parameters for the user we just created. This will speed up database operations so that the correct values do not have to be queried and set each time a connection is established.

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 to use UTC. These are all recommendations from the Django project itself.

Postgres=# ALTER ROLE newprojectuser SET client_encoding TO 'utf8';
Postgres=# ALTER ROLE newprojectuser SET default_transaction_isolation TO 'read committed';
Postgres=# ALTER ROLE newprojectuser SET timezone TO 'UTC';

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

Postgres=# GRANT ALL PRIVILEGES ON DATABASE newproject TO newprojectuser;

When you are finished, exit out of the PostgreSQL prompt by typing:

Postgres=# \q

Create a Python 3 Virtual Environment for your Project

Now that we have our database, we can begin getting the rest of our project requirements ready. We will be installing our Python 3 requirements within a virtual environment for easier management.

To do this, we first need access to the virtualenv command. We can install this with pip3.

Upgrade pip3 and install the package by typing:

  $ 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:

  $ mkdir ~/djangoproject
  $ cd ~/djangoproject

Within the project directory, create a Python virtual environment by typing:

$ virtualenv djangoprojectenv

This will create a directory called djangoprojectenv within your djangoproject directory. Inside, it will install a local version of Python and a local version of pip. We can use this to install and configure an isolated Python environment for our project.

Before we install our project's Python requirements, we need to activate the virtual environment. You can do that by typing:

$ source djangoproject/bin/activate

Your prompt should change to indicate that you are now operating within a Python virtual environment. It will look something like this: (djangoprojectenv)[email protected]:~/djangoproject$ .
With your virtual environment active, install Django, Gunicorn, and the psycopg2 PostgreSQL adaptor with the local instance of pip:

Note: Regardless of which version of Python 3 or python 2 you are using, when the virtual environment is activated, you should use the pip command (not pip3).

(djangoprojectenv)$ pip install django gunicorn psycopg2-binary

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

Create and Configure a New Django Project

With our Python components installed, we can create the actual Django project files.

Since we already have a project directory, we will tell Django to install the files here. 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:

(djangoprojectenv)$ django-admin.py startproject djangoproject ~/djangoproject

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

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

The first thing we should do with our newly created project files is adjust the settings. Open the settings file in your text editor:

(djangoprojectenv)$ nano ~/djangoproject/djangoproject/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.

In the square brackets, list the IP addresses or domain names that are associated with your Django server. Each item should be listed in quotations with entries separated by a comma. If you wish requests for an entire domain and any subdomains, prepend a period to the beginning of the entry. In the snippet below, there are a few commented out examples used to demonstrate.

~/djangoproject/djangoproject/settings.py
. . .
# The simplest case: just add the domain name(s) and IP addresses of your Django server
# ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
# To respond to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '103.25.111.5']
ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . .]

Next, find the section that configures database access. It will start with DATABASES. The configuration in the file is for a SQLite database. We already created a PostgreSQL database for our project, so we need to adjust the settings.

Change the settings with your PostgreSQL database information. We tell Django to use the psycopg2adaptor we installed with pip. We need to give the database name, the database username, the database user's password, and then specify that the database is located on the local computer. You can leave the PORT setting as an empty string:

~/djangoproject/djangoproject/settings.py
. . .
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'newproject',
        'USER': 'newprojectuser',
        'PASSWORD': 'password',
        'HOST': 'localhost',
        'PORT': '',
    }
}
. . .

Next, move down to the bottom of the file and add a setting indicating where the static files should be placed. This 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:

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

Save and close by typing Ctrl + x the file when you are finished.
Now, we can migrate the initial database schema to our PostgreSQL database using the management script:

(djangoprojectenv)$ ~/djangoproject/manage.py makemigrations
(djangoprojectenv)$ ~/djangoproject/manage.py migrate

Create an administrative user for the project by typing:

(djangoprojectenv)$ ~/djangoproject/manage.py createsuperuser

You will have to select a username, provide an email address, and choose and confirm a password.
We can collect all of the static content into the directory location we configured by typing:

(djangoprojectenv)$ ~/djangoproject/manage.py collectstatic

You will have to confirm the operation. The static files will then be placed in a directory called static within your project directory.

If you followed the initial server setup guide, 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.

Create an exception for port 8000 by typing:

(djangoprojectenv)$ sudo ufw allow 8000

Finally, you can test your project by starting up the Django development server with this command:

(djangoprojectenv)$ ~/djangoproject/manage.py runserver 0.0.0.0:8000

In your web browser, visit your server's domain name or IP address followed by :8000:

http://server_domain_or_IP:8000

You should see the default Django index page for Django 2.0.7:

django-loding-page

If you type http://server_domain_or_IP:8000/admin in the address bar, you will be prompted for the administrative username and password you created with the createsuperuser command:

django-administration

After authenticating, you can access the default Django admin interface:

django-site-administration

When you are finished exploring, hit CTRL-C in the terminal window to shut down the development server.

Testing Gunicorn's Ability to Serve the Project

The 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:

(djangoprojectenv)$ cd ~/djangoproject
(djangoprojectenv)$ gunicorn --bind 0.0.0.0:8000 djangoproject.wsgi

This will start Gunicorn on the same interface that the Django development server was running on. You can go back and test the app again.

Note: The admin interface will not have any of the styling applied since Gunicorn does not know about the static CSS content responsible for this.

We passed Gunicorn a module by specifying the relative directory path to Django's wsgi.py file, which is the entry point to our application, using Python's module syntax. Inside of this file, a function called application is defined, which is used to communicate with the application.

When you are finished testing, hit CTRL-C in the terminal window to stop Gunicorn.

We're now finished configuring our Django application. We can back out of our virtual environment by typing:

(myprojectenv)$ deactivate

The virtual environment indicator in your prompt will be removed.

Create a Gunicorn systemd Service File

We have tested that Gunicorn can interact with our Django application, but we should implement a more robust way of starting and stopping the application server. To accomplish this, we'll make a 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.

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 bind 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 example, we specified 3 worker processes in this case.

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
[Unit]
Description=gunicorn daemon
After=network.target

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

[Install]
WantedBy=multi-user.target

With that, our systemd service file is complete. Save and close it now.

we should add bobby user to www-data group:

$ sudo usermod –a –G www-data bobby

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

$ sudo systemctl start gunicorn
$ sudo systemctl enable gunicorn

We can confirm that the operation was successful by checking for the 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 existence of the djangoproject.sock file within your project directory:

$ ls /home/bobby/djangoproject
Output
manage.py  djangoproject  djangoprojectenv  djangoproject.sock  static

If the systemctl status command indicated that an error occurred or if you do not find the djangoproject.sock file in the directory, it's an indication that Gunicorn was not able to start correctly. Check the Gunicorn process logs by typing:

$ sudo journalctl -u gunicorn

Take a look at the messages in the logs to find out where Gunicorn ran into problems. There are many reasons that you may have run into problems, but often, 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. Check the following items:
    • 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 djangoproject.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 djangoproject.wsgi module (which translates to a file called ./djangoproject/wsgi.py)

If you make changes to the /etc/systemd/system/gunicorn.service file, reload the daemon to reread the service definition and restart the Gunicorn process by typing:

$ sudo systemctl daemon-reload
$ sudo systemctl restart gunicorn

Make sure you troubleshoot any of the above issues before continuing.

Configure Nginx to Proxy Pass to Gunicorn

Now that Gunicorn is set up, 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 nano /etc/nginx/sites-available/djangoproject

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.

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 ~/djangoproject/static directory. All of these files have a standard URI prefix of "/static", so we can create a location block to match those requests.

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/djangoproject
server {
    listen 80;
    server_name server_domain_or_IP;

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

Save and close the file when you are finished. Now, we can enable the file by linking it to the sites-enabled directory:

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

Test your Nginx configuration for syntax errors by typing:

$ sudo nginx -t

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

$ sudo systemctl restart nginx

Finally, we need to open up our firewall 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:

$ 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.

Read also

Note: 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.

Ahmed Abdalhamid 12:05 am

About Ahmed Abdalhamid

Technical Support Engineer experienced in Linux servers administration of production environments. Exploring DevOps culture and tools. Interested in containerization and open source monitoring tools.

Author Archive Page

Have anything to say?

Your email address will not be published. Required fields are marked *

All comments are subject to moderation.