-
Notifications
You must be signed in to change notification settings - Fork 0
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
Static files not working when not in DEBUG=True mode #6
Comments
Only serving static files while DEBUG=true seems to be an intended feature. Once we start thinking about moving to production it should be no big deal to put the static files in the correct directory to be served by the server, and not through Django. Django's built in testserver is for convenient development testing, and not intended for deployment. I'll leave this issue open, since it is still an unsolved issue, but not an urgent issue |
I'm not sure what that means precisely. What will be serving the files in this case? You mean like a static file server in Nginx or similar? I could whip that together really, really quickly. Let's aim to get this solved by the end of Saturday's meeting, at the latest. |
Yes. According to the Django tutorial and Django's deployment documentation, Django is run in production through Apache, Nginx, or your favorite webserver compatible with WSGI. The built in server we're running is for development and testing and is not secure or efficient. It is important to note that Django Channels necessitates a server compatible with ASGI, and there are a lot fewer options. Primarily |
Interesting... I'll look into Daphne. |
Reviving this Issue. Very relevant. I have made a We need to set up something else like Other notes: |
That sounds not too hard. I'm busy the next few days but I could do this. |
Hello again 👋 I've got a lot of experience with this now. I'm confident I can get this sorted out. Drop Daphne, grab Uvicorn and Gunicorn and set the container command to When I have time to work on this, I can take care of this. |
It's not too hard in Daphne either. Just set up an nginx reverse proxy to
serve files and send page requests to Daphne. I have it set up on my
personal project, but I'd guess guvicorn may have other pros since your
company chose it.
…On Thu, Jul 16, 2020, 2:28 PM Logan Pulley ***@***.***> wrote:
Hello again 👋
I've got a lot of experience with this now. I'm confident I can get this
sorted out. Drop Daphne, grab Uvicorn and Gunicorn and set the container
command to gunicorn moc.asgi:application --bind 0.0.0.0:8000 -w 4 -k
uvicorn.workers.UvicornWorker. For automatic code reloading in
development, override that command (in docker-compose.yml) to uvicorn
moc.asgi:application --host 0.0.0.0 --reload (doesn't do multiple
workers, but does do code reloading).
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#6 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANIYCQ3TYCGPJ5YE5332D6TR35IGRANCNFSM4JJ2CVOA>
.
|
Another note supporting Uvicorn/Gunicorn. If they work identically easily in dev (with reloading) and production, that is awesome. It is a bit annoying to switch to daphne, and then sometimes not get the same results if you're not serving the files quite right in nginx and there are some edge cases my nginx implementation does not cover that I wouldn't expect others to know about so much. |
For dev, just change the command in compose. The Dockerfile command should be gunicorn (which doesn't really do good reloading, but does do workers) and then dev should use plain uvicorn (which does do good reloading) |
I have a whole setup for this that I learned from research. It's very nice |
We need to figure out how to serve static files correctly in production. Running in DEBUG=True mode is insecure. Might have to tweak views.py and settings.py.
The text was updated successfully, but these errors were encountered: