Remove makemigrations in start.sh about django-docker-quickstart HOT 4 CLOSED

Hello @ddahan,

Thank you for your insightful suggestion and for using this template!

I understand your point about the makemigrations command and the potential issues that can arise if it's run in the production environment. It's a valid concern as migrations ideally should be generated on the local environment and then versioned.

Based on your feedback, I've decided to modify the start.sh script. I'm planning to introduce an optional environment variable in the .env file, say ENABLE_MAKEMIGRATIONS, which will control whether the makemigrations command runs or not. By default, it will be set to false for the production environment, aligning with best practices.

This change will provide more customization to users of this project, allowing them to decide whether to enable or disable this feature depending on their specific needs.

I will implement this in the next update. Meanwhile, if you have a specific implementation in mind or any other suggestions, please feel free to submit a pull request or open a new issue.

from django-docker-quickstart.

Glad this helped. If you want to ensure best practices about deployment stages, I suggest taking a look to the Twelve-Factor App (by the creators of Heroku). This might sound overkill but makes lots of sense, and avoids many pitfalls over time.

Based on this, it would make no sense to run migrate or collectstatic commands whenever the server starts or restarts. It would slow down server and these commands are sure to have no effect if they have been run previously, for example on a release.sh script.

From what I know, .env file is not usually used to handle deployment config, it's more related to how to use the application itself, in a specific environment. Plus, as I said earlier, I'm pretty confident there is no reason to run makemigrations automatically (unlike migrate or collectstatic)

I know about Django best practices but I actually don't know Docker very well, I'm trying to learn it the hardway. As soon as I get some skills, I could be able to help a little more to tweak your useful project with best practices in mind :)

from django-docker-quickstart.

This resource seems pretty interesting too: https://hector.dev/2021/03/16/twelve-factor-methodology-applied-to-a-django-app/#build-release-run

It shows how to use Docker, respecting the whole 12factors principles.

from django-docker-quickstart.

I found something pretty interesting and clever (thanks to chatGPT).

Initially I stated that:
1- Running collectstatic in Dockerfile does not work because the environment is not injected at this stage
2- Running collectstatic in run command has no sense and hangs server start, and create long unavailability time.

The answer:

There's indeed another option for handling static files in a Django application using Docker. You can run the collectstatic command as a part of a build process using a separate Docker container.
This way, your Django application will not start until the static files are collected. It does not add any delay to your container startup time because the static files are already collected when the application starts.

Here is a solution that seems to work well for now:

services:

  srv_pre_django:
    build:
      context: .
      dockerfile: Dockerfile_srv_django
    image: img_django:${GIT_COMMIT}
    command: "/app/release.sh"
    env_file:
      - /root/env/env.srv_django
    volumes:
      - data:/root/data/db
      - static_volume:/app/staticfiles

  srv_django:
    image: img_django:${GIT_COMMIT} # build in other container
    command: "/app/start.sh"
    env_file:
      - /root/env/env.srv_django
    ports:
      - "80:5000"
    volumes:
      - data:/root/data/db
      - static_volume:/app/staticfiles
    depends_on:
      - srv_pre_django

volumes:
  data:
  static_volume:

start.sh

#!/bin/bash
set -xe

gunicorn -b 0.0.0.0:${APP_PORT} dj_config.wsgi

release.sh

#!/bin/bash
set -xe

#
python manage.py migrate --noinput
python manage.py collectstatic --no-input

Note that:

• the same image is used for both services, which is why the build section is only in the srv_pre_django, then the build image is used by srv_django
• the srv_pre_django container will automatically shutdown after release.sh correct execution, which seems elegant to me.

After that, a docker ps -a command will show:

What do you think?

from django-docker-quickstart.