Chapter 2: Creating a Django Project around Docker

In the previous chapter, we learned how to launch an application made in Python using a container system such as Docker. In addition, we created a project in Django, always with an eye on WebSockets for future real-time communication. At the moment, we only have a simple executable; we need to create a service architecture that complements Django. Important pieces such as a database to store and retrieve information, among other things (such as a fake mail server), will be useful for development. By configuring these tools, we will finish building an optimal working environment around Docker to then focus on the code.

We will also work on the communication and integration of environment variables to configure some aspects of the project through docker-compose.yaml. We will modify the critical elements of deployment, such as activating or deactivating the debug mode, changing the domain, indicating the path where the statics will...

Technical requirements

The code for this chapter can be found at https://github.com/PacktPublishing/Building-SPAs-with-Django-and-HTML-Over-the-Wire/tree/main/chapter-2.

Exploring the containers used for building our app

Containers are processes isolated from your operating system. Docker allows us to modify them, add tools, execute scripts, and the like, all without leaving the memory space that Docker reserves for us while they are running. When we want to stop working with a container, we can stop it and any action we have performed will cease to exist. Of course, if we need to, we can save the changes in volumes. These are Docker virtual hard disks that can connect to any container that is mounted in folders; this is very useful in allowing the container to access project files or configurations.

We will use containers to create an environment that is easy to deploy, irrespective of the software or version of Python installed on the machine. In addition, we will be able to select the version for each software in a transparent way.

Let’s start by extending docker-compose.yaml by adding the following services:

Django: We will modify...

Adding the Django service

Within docker-compose.yaml, replace the entire python block with the following:

django:
    build:
      context: ./
      dockerfile: ./Dockerfile
    entrypoint: bash ./django-launcher.sh
    volumes:
      - .:/usr/src/app/
    environment:
      DEBUG: "True"
      ALLOWED_HOSTS: hello.localhost
      SECRET_KEY: mysecret
      DB_ENGINE: django.db.backends.postgresql
      DB_NAME: hello_db
      DB_USER: postgres
      DB_PASSWORD: postgres
      DB_HOST: postgresql
      DB_PORT: 5432
   &...

Configuring the databases

We continue adding services in docker-compose.yaml. After the Django service, we add the following configuration:

postgresql:
    image: postgres
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: hello_db
    volumes:
      - ./postgres_data:/var/lib/postgresql/data/
    expose:
      - 5432

In image: postgres, we are using the official PostgreSQL image. It will be automatically downloaded from the official repositories. Next, we configure the environment variables to indicate the user credentials (POSTGRES_USER and POSTGRES_PASSWORD) and the name of the database (POSTGRES_DB). The variables must match those declared in the Django service; otherwise, it will fail to connect....

Connecting Django to a web server

We must have a gateway service that manages the static content. We will use Caddy for its simplicity.

Caddy is configured with a flat file named Caddyfile. We must create it and add the following content:

http://hello.localhost {
    root * /usr/src/app/
 
    @notStatic {
      not path /static/* /media/*
    }
 
    reverse_proxy @notStatic django:8000
 
    file_server
}
 
http://webmail.localhost {
    reverse_proxy mailhog:8025
}

With the first line, http://hello.localhost, we indicate the domain that we will use. As we are in a development environment, we will indicate the http protocol instead of https. Next, with root * /usr/src/app/ and file_server, we’re telling Caddy to expose static files (images, CSS files, JavaScript files, and so on) because that’s not Django’...

Adding a fake SMTP mail server

At the end of the docker-compose.yaml, we add the last service:

mailhog:
    image: mailhog/mailhog:latest
    expose:
      - 1025
      - 8025

The ports used will be 1025 for Django to connect to the SMTP server and 8025 for the web interface via the webmail.localhost domain because Caddy will act as a reverse proxy.

Now that we have added all the containers, it’s time to test whether the containers run and work with each other.

Testing for correct operation

Finally, we pull up all the services from docker-compose.yaml to test whether the containers run and work with each other.

Caddy and Django

Caddy and Django are easy to check, as when you enter the hello.localhost domain, you will see Django fully functioning with its welcome page:

Figure 2.1 – Django running under the hello.localhost domain

We know that Django has connected to PostgreSQL because we can see in the log how it has applied the migrations:

Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying admin.0003_logentry_add_action_flag_choices... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0002_alter_permission_name_max_length... OK
...

MailHog

MailHog is simple because when you enter the webmail.localhost domain, you will see the web interface...

Summary

In the previous chapter, we were able to run Python in complete isolation from the operating system, including its dependencies. It wasn’t much different from creating a virtual environment. But in this iteration, we’ve taken it up a notch by incorporating all the external software into Django. Containers have become the backbone of the site, incorporating elements as important as databases and the web server itself. What’s more, integration with Django is not merely decorative, as the most critical configurations originate in the Docker environment variables that directly affect settings.py. Right now, if we wanted to, we could deploy the site on any server that has Docker installed with just one command. We can find harmony and architecture in every line of Docker.

We are now ready to dive into asynchrony, WebSockets, channels, and real-time requests.