Deployment + CDN?

[nburt]

Description

We've recently migrated from gunicorn to Daphne so I've also switched to using ServeStatic from Whitenoise, thanks for making that transition so seamless.

I've now been evaluating serving static assets via CDN. We're deployed on AWS ECS so during a deployment we can have multiple versions of the application running in parallel.

My assumption is that this open issue from Whitenoise applies to ServeStatic as well. Is that right? Or have you made adjustments to be able to use a CDN with that kind of deployment setup? If not it seems like we'll want to switch to uploading our static files to s3 instead of serving them from django

[Archmonger]

This is my interpretation of the issue:

In the middle of a cloud deployment, it is possible to serve a new application that references a new static file, but a user's HTTP request for the new static file can get routed to a stale application (which ultimately provides a 404).

Due to technological limitations, I don't think there is a way to automatically resolve this within ServeStatic. However, you can prevent this scenario by modifying your deployment process. The first two options are only possible on ServeStatic and not within WhiteNoise.

1. Deploy ServeStatic in standalone mode separately from your main application.
   • Use routing rules to ensure that all static files requests are routed to ServeStatic.
   • Ensure ServeStatic is always deployed prior to deploying your main application.
   • Use deployment scripts to retain a combination of the current and previous static files. This ensures zero time gap where a static file could return "404 Not Found".
2. Deploy ServeStatic with autorefresh=True
   • Keep a mixture of all legacy and current static files within your cloud hosting provider's file storage system. Make sure that path is mounted and used as static root within any instances that utilize ServeStatic.
   • If doing this, you might want to consider cleaning up legacy files every so often. Could be automated by scripts.
   • Following in the footstep of the WhiteNoise, the ServeStatic docs mention that autorefresh shouldn't be used in production. However, I've been debating removing that warning specifically from the ASGI variant. Compared to WSGI, my testing has shown that ASGI is much less susceptible to being overwhelmed (DDOS-style) when using a production-grade ASGI webserver like Nginx Unit, Hypercorn, Uvicorn, or Granian.
3. Instead of restarting your instances, you could instead shutdown then startup.
   • This comes with the downside of brief website downtime, but it would remove any chance of pairing new & stale applications together.
   • You should probably only do this during off-hours.

[nburt]

Yes that's correct.

Our application is for B2C and has international users so the downtime option doesn't work for our use case, we don't really have any off-hours with zero usage.

1. For number 1, are you saying we'd add routing rules to the load balancer to send all /static requests to the standalone app? Then we'd need to figure out how to keep assets from previous deploys around, perhaps by copying past staticfiles from the previous docker image in deploy.
2. Interesting on the autorefresh. We're currently running on Daphne, sounds like we generally might benefit from switching away to Uvicorn or others?

Thanks for sharing these options! Seems like number 1 or switching to storing files in our cloud provider with django-storages and moving away completely to a CDN are the best bets.

[Archmonger]

For number 1, are you saying we'd add routing rules to the load balancer to send all /static requests to the standalone app? Then we'd need to figure out how to keep assets from previous deploys around, perhaps by copying past staticfiles from the previous docker image in deploy.

Yes, but whether or not routing rules are within the load balancer depends on your specific tech stack. For example, Azure uses Application Gateway Routes and Cloudflare uses Worker URL Routes.

Alternatively you could put a reverse proxy (like Nginx/Apache) in front of your ASGI apps to handle this application routing. Depending on your tech stack, doing this could also require having a dedicated subdomain for ServeStatic as an intermediary.

Interesting on the autorefresh. We're currently running on Daphne, sounds like we generally might benefit from switching away to Uvicorn or others?

Yes I would highly recommend not using Daphne in production. It's useful for development/debugging since it's pure Python, but it has awful data throughput and does not handle high traffic loads well.

Since ASGI is still fairly new, the webserver landscape changes very rapidly. To my knowledge, Granian has the best HTTP performance and Uvicorn has the best WS performance as of right now.

EDIT: I just did some testing, and Nginx Unit seems to be the best overall, but it is fairly annoying to configure.