Using an identical database for dev breaks my css

Using Django
1

Hi guys,
As per the title, I’m getting this weird issue. It only recently started happening with no obvious changes that should’ve affected this part of the application.

Setup - Django 3.0.3. I have two postgres 12 databases setup on the same server. In my settings.py, I use environment variables to set the database which are passed in to two separate docker containers (prod/dev). The source code and container images are identical in both containers. Migrations are automatically applied using a container start script. I’ve tested using both pg_dump and templates to create an identical postgres database.

Issue - In my prod docker container, static files and CSS aren’t loading (e.g. /static/rest_framework/css/bootstrap.min.css - Not found). Everything at /api and /admin isn’t loading correctly. Bootstrap CSS is working fine for the root page (root.html which extends base.html). collectstatic runs fine but still no luck. I have both STATIC_ROOT and STATIC_URL set too.

Env tests:
prod (container) -> dev (db) - Works
prod (container) -> prod (db) - Doesn’t work
dev (container) -> dev (db) - Works
dev (container) -> prod (db) - Doesn’t work
laptop (ubuntu) -> prod (db) - Works

Doesn’t work = When accessing /static/admin/css/base.css:
hub: “GET /static/admin/css/base.css HTTP/1.0” 404 179
hub-dev: “GET /static/admin/css/base.css HTTP/1.0” 200 16378

Seems database related based on these tests. I’d be happy to use just one (working) database for both environments if that’s advisable?

Any advice or pointers please
Many thanks in advance

2

Database data issues are not going to affect whether or not static resources are located. My initial guess is some difference in the web server configuration between your test and prod environments. You don’t provide enough information about how you’re serving your application from either container, so it’s kinda hard to be more specific than that.

Also, I’d like to add that simply saying something “doesn’t work” doesn’t provide anyone with useful information to provide assistance. The specific error messages or symptoms displayed (404? 500? Stack dump?) generally contain a lot of detail.

3

Hey, I thought that was the case but the tests are confusing me more than I already am. My apologies, here’s the docker setup and error messages. (I removed my previous edit with the nginx.conf - the issue persists without any reverse proxy in front).

  django-prod:
    image: registry/hub-django
    networks:
      - hub-net
    ports:
      - 8001:8000
    volumes:
      - /var/home/wabi/hub-prod:/hub
    environment:
      - DB=hubdb

  django-dev:
    image: registry/hub-django
    networks:
      - hub-net
    ports:
      - 8002:8000
    volumes:
      - /var/home/wabi/hub-dev:/hub
    environment:
      - DB=hubdbdev

When accessing /static/admin/css/base.css:
hub1:8001: “GET /static/admin/css/base.css HTTP/1.0” 404 179
hub1:8002: “GET /static/admin/css/base.css HTTP/1.0” 200 16378

4

Cool, we’re getting closer.

What is running on port 8000 in django-prod that is servicing requests? (Actually, same question for django-dev, too)

(I really hope it’s not “runserver”.)

Now, I recognize that there are different ways of doing things, but when we’re running django (through uwsgi) behind nginx, we have nginx serving the static content. That’s the purpose of the collectstatic command. We then have an nginx section for ‘/static/’ to tell nginx where to find the static files.

5

Dare I say yes to both haha. It is indeed (python manage.py runserver 0.0.0.0:8000). This is all pretty new to me as I’m just at the end of an online course. I’ve updated my reply above to mention that this issue still occurs without any reverse proxy in front of the prod site (hub1:8001).

Do you suggest I use gunicorn instead? I’ve used that for an old flask site.

6

Bingo! And we have a winner.

I’ll assume for the moment that you’re just prototyping some ideas right now and don’t have any intent of actually serving content in a production environment using this architecture.

I suggest you read some more about runserver, and this page about runserver, especially this section about the insecure parameter.

(I also strongly suggest that you become familiar with working through a production-quality django deployment before even thinking about doing it in docker. There are enough hidden gotchas that you don’t want to try to diagnose more layers of the stack than absolutely necessary at each stage.)

Ken

1 Like
7

Regarding your comment about gunicorn - if you’re familiar with it, sure. It’s definitely better than runserver. (We use uwsgi because I’m running a variety of apps in python, php, and perl and wanted to minimize the number of different environments being used.)

But I’ll point out that we don’t use uwsgi to serve static resources. We have a specific directory for static resources to be served by nginx, and collectstatic copies those files from the django directories to the nginx-aware directories. That gets both python and uwsgi out of the way.

Take a look at the Django Deployment section (with the checklist) in the documentation for more information and ideas.
Ken

1 Like
8

Yeah just prototyping at the moment. I’m mainly Ops and have numerous stacks running in production but this is a first for Django at least. Thanks for your help with this, particularly all those links provided. That’ll keep me busy tomorrow for sure!