Skip to content

Let developers customize static resource serving for safer deployments to clusters without sticky sessions #1474

@ide

Description

@ide

Most cluster configurations are stateless and don't have sticky sessions, which makes them much simpler to work with. One problem with this though is if you load a page from version 2 of your website that contains the HTML <img src="/static/onlyOnV2.png" /> and then the browser tries to load the image (onlyOnV2.png) from a server that still has the version 1 code, the image won't load.

Even with sticky sessions you'll likely run into this problem if you put a read-through CDN (ex: AWS CloudFront) in front of your servers unless the stickiness of the web page gets propagated through your browser's request to the CDN as well. So basically if we can solve this without stickiness that'd be great.

Implementation idea:

One solution to this is to make all versions of the code be able to serve any static resource. When deploying a new version of the site, the first step is to upload the static resources to a shared database that the old version of the site can access. Then the second step is to deploy the code. Since the old version of the site can serve the new resources, we don't have the problem mentioned earlier.

A more concrete implementation of this idea that I imagine many people would use (especially together with content-addressed static resource URLs: #1473) is to upload their static resources to AWS S3 during the first step of deployment and then deploy the code in the second step of deployment. All AWS S3/CloudFront machines can serve both the new and old resources and this part of the deployment is safe.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions