Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ops Story: Serve static files in production #250

Open
nlMeminger opened this issue Nov 26, 2019 · 2 comments
Open

Ops Story: Serve static files in production #250

nlMeminger opened this issue Nov 26, 2019 · 2 comments
Assignees
Labels
bug Something isn't working infra Changes related to infrastructure and/or operations quality assurance CI tests, unit tests, integration tests, any kind of testing research Researching documentation for feature enhancement

Comments

@nlMeminger
Copy link
Collaborator

Summary

Django does not serve static files when DEBUG is set to False, or rather when the application is set to be used in production mode.

Background

During our attempt to move the app to production it was discovered that we need to figure out how to serve static files while in production. Something that is already done in Development.

Details

We need to research how to either use another service like Nginx or apache to serve our content or research on how to remove our static content using something like Django-compressor.

Outcome

In the end, we should be able to use our app with DEBUG set to False so that we can move to production.

@nlMeminger nlMeminger added bug Something isn't working backend Changes related to back-end functionality needs triage Metadata needs to be triaged and updated research Researching documentation for feature enhancement labels Nov 26, 2019
@nlMeminger
Copy link
Collaborator Author

here is what I've got so far. In the Django documentation, using the ./manage.py runserver command in production is not recommended. That is only meant for development. Instead, it is suggested to use another web application like Nginx since Django is not a web application like we expected.

So here is what I've found from these two sources, which are related (linked below). We need to amend our documentation to include Nginx installation and configuration, and use it to serve our static content. This is pretty simple, just install nginx, make a server block for our app, and start the service. These steps are better documented in the sites I've linked.

As I understand so far, using Docker like we have been is still possible. What we need to change to make it work is add gunicorn as a dependency and make our entrypoint command for the container the gunicorn command instead. This may be a wrong assumption.

All the work I've done has been commited to the branch named production.

Links as promised, in the order they should be read.
https://medium.com/@_christopher/deploying-my-django-app-to-a-real-server-part-i-de78962e95ac
https://medium.com/@_christopher/deploying-my-django-app-to-a-real-server-part-ii-f0c277c338f4

@jwflory jwflory added infra Changes related to infrastructure and/or operations quality assurance CI tests, unit tests, integration tests, any kind of testing and removed backend Changes related to back-end functionality needs triage Metadata needs to be triaged and updated labels Nov 28, 2019
@jwflory jwflory added this to the Bonus Sprint milestone Nov 28, 2019
@jwflory jwflory changed the title BE Story: serve static files over production Ops Story: Serve static files in production Nov 28, 2019
@jwflory jwflory removed this from the Bonus Sprint milestone Dec 5, 2019
@jwflory
Copy link
Owner

jwflory commented Dec 13, 2019

This has stretched out for a long time, but I figured out the best way for us to approach this:

  1. Change the entrypoints on containers to use Gunicorn
  2. Point Monroe County I.T. at extensive documentation for running Django application in production with a web server in front

The changes required for no. 1 are in change/gunicorn. No. 2 saves us from a lot of work that we won't be able to address in time, but we can point out to the Gunicorn documentation for help here. It's pretty thorough.

I need @nlMeminger to build it on the staging server one last time to make sure it starts up in a production environment. Once he does and if it checks out, we'll officially close this out.

jwflory added a commit that referenced this issue Dec 13, 2019
This commit changes the entrypoints on the Dockerfiles to use `gunicorn`
instead of the Django debug server. I was able to switch it for both
development and production since Gunicorn is fairly simple.

For development, I included a setting that automatically reloads
Gunicorn if files change on disk. This is a setting intended for local
development, such as when we have container volumes with docker-compose.

Also, I have waited a long time to have a semi-valid excuse to use the
:unicorn: emoji.

Closes #250.

Signed-off-by: Justin W. Flory <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working infra Changes related to infrastructure and/or operations quality assurance CI tests, unit tests, integration tests, any kind of testing research Researching documentation for feature enhancement
Projects
None yet
Development

No branches or pull requests

2 participants