You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I think this is not only for static resources but for assets including our JS code.
I hope we could easily do this without much effort.
I guess with Zeit Now's immutable deployment feature, this will make pretty simple.
Of course we need to have an way to work with any server CDN as well.
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.
The text was updated successfully, but these errors were encountered: