We have a web application running on two servers behind an Elastic Load Balancer. We deploy a new release of it multiple times a day. Each time a new release comes out we use different JS and CSS filenames to avoid caching issues. For example, in one release we have app-v1.js and on the following one we have app-v2.js instead.
We want to use CloudFront to serve those resources in gzip format (provided that the browser presented an appropriate Accept-Encoding header).
We explored two modes of operation:
Cloudfront with S3 origin: does not seem to have this capability (either the object is compressed or not, will not serve a compressed version based on the header).
Cloudfront with custom origin: does not cope with rolling updates: when we deploy to server A there will be a reference to app-v2.js from our HTMLs. Since it is not cached yet in CloudFront, CloudFront will request it from our servers and may hit a server that has not received the update yet and hence serve a 404.
What's the best practice? Are we missing anything? We thought of putting up an nginx proxy server so it will compress content from S3 for Cloudfront. It would be something like this:
CloudFront --> nginx proxy --> S3
We can do that, but hopefully we can avoid maintaining this piece. Any advice?
This is the solution I ended up implementing:
Elastic Loadbalancer talks to our servers at www.domain.com and static.domain.com, both are virtual hosts running by the same set of serving machines. Before starting a rolling upgrade to our website, our deployment script uploads the new static resources to be served under static.domain.dom. The webserver is configured to return a gzip compressed response if the browser supports it. When all the webservers received the new files we start the rolling upgrade.
This guarantees that both old revisioned files and new revisioned files can be served by any server during the upgrade.