Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Answeredbynickjj
kennyhei asked this question inQ&A
Discussion options

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 usingpython manage.py runserver?

You must be logged in to vote

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.

Replies: 2 comments 2 replies

Comment options

Here's my fix unless better solution is provided 😄

  1. I added new environment variableDOCKER_ENV to.env with valuedevelopment
  2. I added the variable toargs for x-app incompose.yaml:
- "DOCKER_ENV=${DOCKER_ENV:-production}"
  1. I removed last line from DockerfileCMD [...]
  2. I modifiedbin/docker-entrypoint-web as follows:
#!/usr/bin/env bashset -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 /appif [ "$DOCKER_ENV" = "development" ]; then    exec python manage.py runserver 0.0.0.0:8000else    exec gunicorn -c python:config.gunicorn config.wsgifi

And then build image again. Obviouslyrunserver 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 variableDOCKER_ENV to.env with valuedevelopment
  2. Incompose.yaml, add this tox-app (aftervolumes):
  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'
  1. Remove last line from Dockerfile (CMD [...] )
  2. Leavebin/docker-entrypoint-web as it is!

And you're done.

You must be logged in to vote
1 reply
@nickjj
Comment options

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.

Answer selected bykennyhei
Comment options

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

  1. Add environment variableDOCKER_ENV to.env with valuedevelopment
  2. InDockerfile, edit last three lines from this
ENTRYPOINT ["/app/bin/docker-entrypoint-web"]EXPOSE 8000CMD ["gunicorn","-c","python:config.gunicorn","config.wsgi"]

to this:

EXPOSE 8000ENTRYPOINT ["/app/bin/docker-entrypoint-web"]
  1. Modifybin/docker-entrypoint-web as follows:
#!/usr/bin/env bashset -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 ];thenecho"Executing additional command:$*"exec"$@"# Execute the provided command and exitexit 1fi# If no commands are passed, check if DOCKER_ENV is set to 'development'if ["$DOCKER_ENV"="development" ];then# Run the Django development serverecho"Running in development mode. Starting Django development server..."exec python manage.py runserver 0.0.0.0:8000else# Run the Gunicorn server using config file from src/config/gunicorn.pyecho"Running in production mode. Starting Gunicorn server..."exec gunicorn -c python:config.gunicorn config.wsgifi

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

if ["$RUN_MIGRATIONS"="true" ];thenecho"Running migrations..."until python manage.py migratedoecho"Waiting for db to be ready..."        sleep 2donefi
You must be logged in to vote
1 reply
@nickjj
Comment options

Hi, yep that would work. Thanks for posting it. You can also consider piggy backing offDEBUG=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.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
2 participants
@kennyhei@nickjj

[8]ページ先頭

©2009-2025 Movatter.jp