Deploying a django project to a dokku server on a google VM instance

[grim berry]

Hello!

This is a puzzle I can't seem to solve.
I have a django project that runs fine locally in Debug mode.
I tried to deploy it to dokku (on a remote VM), and all I get is Error 500. I followed the usual tutorials but something's wrong, and I have no idea what it is.

I tried to set Debug to True on the remote, and... it works. So at least, the issue is only present in production mode and not related to server or database configuration.

The code can be found here: https://github.com/PliskinGH/RootLeague
(settings.py in particular : https://github.com/PliskinGH/RootLeague/blob/master/RootLeagueProject/settings.py)

In the logs given by dokku, I don't get anything useful:

2024-06-30T19:54:54.088472431Z app[web.1]: Python buildpack: Couldn't determine available memory. Skipping automatic configuration of WEB_CONCURRENCY. 2024-06-30T19:55:00.580110348Z app[web.1]: [2024-06-30 19:55:00 +0000] [13] [INFO] Starting gunicorn 22.0.0 2024-06-30T19:55:00.583053020Z app[web.1]: [2024-06-30 19:55:00 +0000] [13] [INFO] Listening at: http://0.0.0.0:5000 (13) 2024-06-30T19:55:00.583255421Z app[web.1]: [2024-06-30 19:55:00 +0000] [13] [INFO] Using worker: sync 2024-06-30T19:55:00.590341746Z app[web.1]: [2024-06-30 19:55:00 +0000] [156] [INFO] Booting worker with pid: 156 2024-06-30T19:57:35.252764612Z app[web.1]: 172.17.0.1 - - [30/Jun/2024:19:57:35 +0000] "GET / HTTP/1.1" 500 145 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0" 2024-06-30T19:57:35.483967561Z app[web.1]: 172.17.0.1 - - [30/Jun/2024:19:57:35 +0000] "GET /favicon.ico HTTP/1.1" 404 179 "http://35.184.136.225/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"

If anyone has any idea about what's happening, I'd appreciate the help.

Thanks!

[grim berry]

I managed to find the issue by using DEBUG_PROPAGATE_EXCEPTIONS = True

So problem solved! (some static files were removed and then commented out in the templates, but django was still parsing the comments of course)

[sudden laurel]

For next time you should install Sentry on any deployment where debug is false. Then you would have gotten the real error.

[wheat ibex]

Surely there are also log files somewhere? Errors aren't just hidden/invisible unless you have Sentry.

[sudden laurel]

He did look in the logs and didn't find anything so 🤷‍♂️

Personally I find that it's better to point people to sentry which they should have anyway.

[grim berry]

Thanks, I will look into that

It's indeed worrisome that the behavior is different (more tolerant on debug True). Is there any way to get the errors on local debug environment (without having two local development environments, one with debug and one without)?

[sudden laurel]

I still don't understand what the problem was honestly

[grim berry]

I think, by default, logs give nothing in case of error 500. There may be ways of using LOGGING variable to change that, but I found it easier to use DEBUF_PROPAGATE_EXCEPTIONS instead.

[sudden laurel]

oh wait.. you used {% static %} inside an html comment?

[grim berry]

Yep

[wheat ibex]

This isn't true. Logs, even when DEBUG is False, should always contain the full traceback of the exception.

[sudden laurel]

Hmm.. I would expect the page to crash in debug mode too, but the crash you got was from the manifest checking, not the page itself?

[grim berry]

Well, I had nothing

[sudden laurel]

Maybe you looked in the wrong log file? Normally stderr and stdout are in different files

[grim berry]

I'm using gunicorn and whitenoise to serve static files, not runserver

Maybe the logs were somewhere else

[wheat ibex]

The docs for DEBUG_PROPAGATE_EXCEPTIONS say:

This can be useful for some test setups. It shouldn’t be used on a live site unless you want your web server (instead of Django) to generate “Internal Server Error” responses. In that case, make sure your server doesn’t show the stack trace or other sensitive information in the response.

[grim berry]

Yes, I'm disabling it now that my issue is fixed. But still looking for a more viable option to avoid unnecessary duplicate test environments.

[wheat ibex]

I'm also unsure why a {% static %} template tag can throw a 500, I don't think I've ever seen that before. It's basically just string concatenation?

[grim berry]

That static file was removed

[wheat ibex]

So? Standard static file setup doesn't care if a static file exists or not.

Unless you've changed your static files storages setting to something that does some checking, I guess?

[grim berry]

That's probably the same behavior I had with debug True

[grim berry]

No idea, I just followed the tutorials that say to use whitenoise

[wheat ibex]

Actually understanding what's being asked of you when following tutorials is always useful. Did you change the STORAGES setting in settings.py at all?

[grim berry]

Yes, as you can see on my settings.py:

STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

[wheat ibex]

Oh I missed that you shared that, my apologies. Yeah, so that's likely the cause then, as detailed in the Whitenoise troubleshooting docs

But, 500 errors should appear in the stdout/stderr logs of your gunicorn container with DEBUG=False and no other settings