Handling different static files between environments when deploying update to primary / fallback Django servers

Question

I'm following Ken Cochrane's answer to the question Seamless deployment of Django to single server. I'm essentially running two production servers, one primary and one fallback, and my nginx is configured as follows (omitting unnecessary details):

upstream app-primary {
    server localhost:12345;
    server localhost:12346 backup;
}
server {
    root /home/fraxtil/app/primary;
    location /static/ {
        alias /home/fraxtil/app/primary/static/;
    }
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass http://app-primary;
    }
}

When pushing an update, I upgrade fallback, then turn off primary, upgrade it, and turn it back on. The solution is almost perfect, but there's one problem: I'm using django-compressor to collect and compress my CSS and JS files, and the two instances aren't guaranteed to have the same static filenames. So while primary is down, the fallback server handles app requests just fine, but nginx is looking for static files in /.../primary/static/ instead of /.../fallback/static/.

Is there a way to solve this problem without routing static file requests through Django? Alternatively, is there a better way to seamlessly deploy Django updates? (I'm interested in having zero downtime, which is why the two-server model enticed me.)

Answer 1

I found a way to make it work using the try_files directive. I had actually tried this before posting the question, but for some reason my first attempt made every request 404. This seems to work, though:

server {
    # Moved the root up one level
    root /home/fraxtil/app;
    location /static/ {
        # Try the primary instance's static folder, then the fallback's
        try_files /primary/$uri /fallback/$uri =404;
    }
...

The only drawback here is that all requests for nonexistent static files will hit the disk twice, but that shouldn't be too big of an issue.