tiangolo
commented
4 years ago That seems like a complex setup with very high availability requirements you're targeting at! :sweat_smile: :rocket:
If I had to do something like that, I would probably try to namespace assets by path, probably having the assets with the version of the app as part of the path, and putting a load balancer (e.g. Traefik) on top to forward to one set of containers under one path, and the new one for the new set of containers.
On the other side, you might want to disable the hash names in the built React app so that they are always available, and make sure to reduce the cache times. That might be an easier solution, it would mean that your app wouldn't be broken not even for seconds, but would also mean that it would also load more slowly, as it would not hit the local cache as often.
andresmoschini
github-actions[bot]
This doubt is related to the article "React in Docker with Nginx, built with multi-stage Docker builds, including testing"
As you can see in the image, the generated css and js files have a hash in the file name. That is great because it allows having a very aggressive cache for that kind of files in the browser.
The problem is when you publish it as a docker service in a swarm stack and you want to update the service without downtime:
Suppose that you have multiple replicas of the same service. When you update the service, the replicas with the updated images are initiated, but the old replicas are still alive.
So, some requests will get the old HTML file (referencing the old js and css files), and some requests will get the new HTML file (referencing the new js and css files). Then when you ask for the js or css file, some replicas have it and some replicas do not.
Configure Swarm to update all the replicas at the same time mitigates the problem, but it is not useful to guarantee zero downtime.
Do you know what is the right way to deal with this?