2 ms·
Great writeup and thanks for providing the code as well! I think if I were to do this I'd probably do it the other way around. I'd introduce the new code first
by bluehatbrit 3y ago
Great writeup and thanks for providing the code as well!
I think if I were to do this I'd probably do it the other way around. I'd introduce the new code first on a new node, add it to the load balancer, check it's healthy, and then remove the old node.
It allows a bit more growth for new functionality should it be needed. For example you can run a canary for an hour and check the error rates before promoting the deployment. Or you can rollback if the new code fails to start for some reason without needing to reload the previous application version first.
On the other hand, this works great if you want to keep the VPS more long lived by recycling it.
- memset 3y agoInteresting! So you'd provision a new VM, deploy and add it to the LB, and then destroy the old node? I think that's where a docker-based deployment would shine, it would be way faster.
- bluehatbrit 3y agoThis is how I've done things in the past when working with VM's. It definitely works well with containers as well though. The really great benefit is you can check the new version is healthy before introducing it to public traffic, and then you can hold off as long as you want before pushing on with replacing the other nodes. You also make sure you get a clean VM each time configured the way your IaC dictates. Obviously if your nodes hosting the application are not under IaC or for some reason you want them to be long lived, then this doesn't work as well and your model is going to the better way to go.