How to monitor code changes / reload app automatically after errors?

[kennyhei]

Everything is working great with this project except that apparently gunicorn is not able to survive from e.g. coding errors. App crashes -> I fix the error -> code changes are not being monitored anymore and app does not reload. As a workaround I have to manually restart the web container.

Am I missing something here or could there be e.g. dev configuration for using python manage.py runserver?

[kennyhei]

Here's my fix unless better solution is provided 😄

1. I added new environment variable DOCKER_ENV to .env with value development
2. I added the variable to args for x-app in compose.yaml:

- "DOCKER_ENV=${DOCKER_ENV:-production}"

3. I removed last line from Dockerfile CMD [...]
4. I modified bin/docker-entrypoint-web as follows:

#!/usr/bin/env bash

set -e

# Always keep this here as it ensures your latest built assets make their way
# into your volume persisted public directory.
cp -r /public_collected /app

if [ "$DOCKER_ENV" = "development" ]; then
    exec python manage.py runserver 0.0.0.0:8000
else
    exec gunicorn -c python:config.gunicorn config.wsgi
fi

And then build image again. Obviously runserver is slower than gunicorn but at least now app reloads even after code errors.

UPDATE:

My previous solution will mess up the ./run pip3:install script. Here are my latest changes:

1. Add new environment variable DOCKER_ENV to .env with value development
2. In compose.yaml, add this to x-app (after volumes):

  command: >
    sh -c
    'if [ "$DOCKER_ENV" = "development" ]; then
      exec python manage.py runserver 0.0.0.0:8000
    else
      exec gunicorn -c python:config.gunicorn config.wsgi
    fi'

3. Remove last line from Dockerfile (CMD [...] )
4. Leave bin/docker-entrypoint-web as it is!

And you're done.

[nickjj]

That is one way to solve it. The concern there is not using the same app server in development vs production. That's why I tend to stick with gunicorn in all environments although it shouldn't be too bad.

I'm not aware of too many other options unless you had a wrapper process start gunicorn which always stays up and then if it detects gunicorn went down it would restart it. Basically a process monitor.

[kennyhei]

I fine-tuned my original solution some more, will write it here, maybe someone finds it useful:

1. Add environment variable DOCKER_ENV to .env with value development
2. In Dockerfile, edit last three lines from this

ENTRYPOINT ["/app/bin/docker-entrypoint-web"]

EXPOSE 8000

CMD ["gunicorn", "-c", "python:config.gunicorn", "config.wsgi"]

to this:

EXPOSE 8000

ENTRYPOINT ["/app/bin/docker-entrypoint-web"]

3. Modify bin/docker-entrypoint-web as follows:

#!/usr/bin/env bash

set -e

# Always keep this here as it ensures your latest built assets make their way
# into your volume persisted public directory.
cp -r /public_collected /app

# Execute command that was passed from compose.yaml or from run script
# E.g. deps:install passes command `cd .. && bin/pip3-install`
# to `docker compose run`. It overrides whatever is defined in the compose
# file.
if [ "$#" -gt 0 ]; then
    echo "Executing additional command: $*"
    exec "$@"  # Execute the provided command and exit
    exit 1
fi

# If no commands are passed, check if DOCKER_ENV is set to 'development'
if [ "$DOCKER_ENV" = "development" ]; then
    # Run the Django development server
    echo "Running in development mode. Starting Django development server..."
    exec python manage.py runserver 0.0.0.0:8000
else
    # Run the Gunicorn server using config file from src/config/gunicorn.py
    echo "Running in production mode. Starting Gunicorn server..."
    exec gunicorn -c python:config.gunicorn config.wsgi
fi

And that's it! With env variables, you can easily add more automation to bin/docker-entrypoint-web (e.g. when deploying to prod) such as running migrations:

if [ "$RUN_MIGRATIONS" = "true" ]; then
    echo "Running migrations..."
    until python manage.py migrate
    do
        echo "Waiting for db to be ready..."
        sleep 2
    done
fi

[nickjj]

Hi, yep that would work. Thanks for posting it. You can also consider piggy backing off DEBUG=true which already exists with the expectation that if debug mode is enabled you want to use the Django development server. This avoids introducing a new DOCKER_ENV env var.

I'd be careful about running migrations in an entrypoint btw. In certain runtime environments you might have multiple containers get started up. Technically the migration process is idempotent but I much prefer running tasks like that in a post-deploy hook. This way it only gets run once, no matter if you're using Docker Compose, Kubernetes with Helm / Argo CD or a managed provider like Heroku.