Setup and deployment

We provide three Docker stacks: a development stack, a testing stack and a production stack.

Prerequisites

Required

• Docker-compose: Both Docker stacks utilize a .yml file to organize components.
• Bash: The development and testing Docker stack include a bash script. If you're on Windows, you'll need WSL to execute it.

Optional

• Docker group: By default, most Docker commands require sudo rights. You can avoid this by adding yourself to the Docker group.

Development

The development and production Docker stacks differ in several aspects:

• Database: Instead of Postgres, a simple SQLite file is used.
• Hot reloading: The development Docker stack utilizes volume binding for hot reloading. After modifying backend or frontend files locally, the respective Docker container will reload to reflect the changes.

Setup

The development.sh script serves as your primary interface to the project. There's no need to directly modify the .env file or execute Docker commands, as everything is managed through optional flags when running development.sh.

The typical workflow is as follows:

1. If the environment file, .env, doesn't exist, it will copy the development environment file, .dev.env.
2. It then generates self-signed SSL certificates if they don't exist.
3. Next, it will start the required Docker containers.
4. Depending on the flags provided, it executes different tasks
   1. Display the output of the desired container.
   2. Refresh pre-generated data.

The development.sh script supports five optional arguments:

• c: Perform a clean build instead of starting preexisting images. Use this option if Docker encounters an error.
• b: Follow the logs of the backend container.
• f: Follow the logs of the frontend container.
• d: Specifies the size of pre-generated data to load in: small, medium, large or real (realistic). The database is cleared first.
• s: Regenerates all data. This operation can and will be time-consuming. Only resort to it when absolutely necessary.

These arguments can be combined according to the following logic:

• If -s is used, only -c is relevant
• If both -b and -f are specified, or neither is, the output of both backend and frontend containers is displayed.

Access

Access to the deployed application is as follows:

• Frontend: Accessible at https://localhost.
• Backend: Accessible at https://localhost/api.

Testing

The testing Docker stack mirrors the development stack with one notable difference: the nginx container doesn't bind ports 80, 443, and 8080; instead, it exposes them.

Setup

1. Execute the testing.sh script. It follows the same steps as the developer script, with the exception of step 4. After executing the given tests it will delete all created images. This behaviour can be changed with the -k flag.

The testing.sh script accepts four optional arguments:

• c: Performs a clean build instead of starting preexisting images. Use this option if Docker encounters an error.
• b: Executes backend tests.
• f: Executes frontend tests.
• k: Keep the images after running the tests.

These arguments can be combined. If both -b and -f are provided, it runs tests for both the frontend and backend. If neither is given, both the backend and frontend tests will be run.

The script has default behaviors for image handling. Initially, it searches for existing images to use, creating new ones only if none are found. Additionally, after tests are completed, it automatically removes all images. This means that, if no flag are given, each time the script runs, it builds new images.

However, when you use the -k flag, the script doesn't remove the images at the end of the process. This results in faster startup times because the existing images are reused, avoiding the need for rebuilding. If you used the -k flag in the previous run of the script, it will automatically utilize the preexisting images.

However, if you want to ensure that all images are rebuilt, regardless of whether the -k flag was used in the previous run, you can use the -c flag.

Production

Setup

Deploying to production requires additional steps:

1. SSL: Replace self-signed certificates used in development with a CA certificate. One approach is using certbot. Ensure the certificates are in the same directory and renamed to certificate.crt and private.key.

2. Environment file: Copy the production environment file, .prod.env, to .env, and populate the empty environment keys.

3. Build & run: Use your preferred method to build and run the containers. One way is docker-compose -f production.yml up -d.

Access

Access to the deployed application is as follows:

• Frontend: Accessible at https://{DJANGO_DOMAIN_NAME}.
• Backend: Accessible at https://{DJANGO_DOMAIN_NAME}/api.

DJANGO_DOMAIN_NAME should be specified in the environment file.