2

My express application is running in an amazon ECS container behind an ALB load balancer.

For cachebusting webpack generates a new hash each time the app is built and released and appends it to the CSS file name (e.g. main.b938eb5b2934c85d13e0.css).

During deployment of a new release, both containers (old version and new version) are running at the same time for about a minute and the LB routes requests to one of the containers randomly.

It then sometimes happens that users get the index.html from the new container, but the following CSS request is routed to the old container, resulting in 404 because the hash part of the filename is different. Users then see a completely broken unstyled GUI.

How can this be avoided this without losing the cachebusting aspect?

Bastian Voigt
  • 5,311
  • 6
  • 47
  • 65
  • 1
    That's an interesting problem. How about establishing [sticky sessions](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html) for the duration of the deployment? – Petr Broz Sep 18 '18 at 15:15
  • Interesting idea! Your link points to the "classic" load balancer, but the ALB also supports stickiness on the target group level. [Documenteation is here](https://docs.aws.amazon.com/de_de/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions). I guess it will not solve the problem completely, it might still happen that a stickiness cookie expires while a release is being deployed. But it should reduce the number of users affected significantly. I'm going to give this a try today! – Bastian Voigt Sep 19 '18 at 06:55

0 Answers0