Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Fast server replacement support/documentation
See original GitHub issueI could not find any documentation on this topic, so I assume any behavior I would witness in testing is accidental and prone to change unless specified somehow.
I would like to know the path to effective replacing of servers/containers. What I mean by that is that in a scenario where I have a container A with www.somedomain.com running, and I would like to replace container A with container B to host www.somedomain.com from now, it is not clear to me if there is any supported path short of shutting down A, then starting up B. To minimize outage time, it would be much preferable if I could just give B the appropriate environment variables, start it up, and the companion container would say “hey, this guy has the same VIRTUAL_HOST/LETSENCRYPT_HOST as container A, that sounds like he wants to replace A, so lets route future incoming connections to B”.
Is there any way to get that to work in the way I described ? Or if that is already the case, can we rely on that behavior not changing ?
Issue Analytics
- State:
- Created 3 years ago
- Comments:5
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
So this is exactly how it works already. Spin up container B with the same run command as container A. nginx-proxy will load balance requests to both. Shut down container A, you’re now running on B. Not outage time
This is a great feature. I guess this request can be closed? I will test it with my setup and let you know.