The Rolling method is used to update software in batches, one batch after another.
The batch number represents the number of instances that are updated at the same time. Possible values are from “1” to “n-1”, where “n” is the total number of instances.
To review some of load balancer concepts please visit this page.
How it works
Select a batch of servers, remove them from load balancer, update the software then connect them back to the load balancer. Do this until all serves are updated.
This strategy has zero downtime and during deployment both versions of software will run in production at the same time.
Let’s consider this as our initial phase:
Step 1 is to wait for connection draining, to finish current requests, with a timeout. After this, the server will be removed from load balancer.
Step 2 is to update the server software. This will not cause downtime because the surver currently being updated is not receiving any incoming requests from the load balancer.
Step 3 is to make server available again after software update, the load balancer will check the availability and after health check process will send incoming requests to it.
Repeat step 1, 2, 3 for second and third server (wait for connection draining, remove from load balancer, update software, reconnect them to load balancer)
When should you use this method
You can use this strategy when there won’t be a problem with running new and old software at the same time, for example when preparing the infrastructure for A/B testing (deploy on x serves capacity the new software, the rest of them remaining with the old version. A percent of users will be redirected to new software, the rest of them to the old one).
- Both versions of software will run in production at the same time
- Ensure backwards compatibility for all shared resources between old software and new software (databases, cache etc.)
- Almost all serves (all minus batch number) are available in load balancer during deploy and can handle the incoming requests
- Fast detection of errors which implies executing rapid disaster-recovery procedure or rollback
- Monitoring, logs and health check are an essential part of the deployment as we can see how the new software behaves right after fist batch update. If something goes wrong, then all we have to do is to update those servers with old version of software.
<a href=”https://www.bunnyshell.com/site-reliability-robot/” id=”check-out-srr-image”><img class=”alignnone wp-image-5107 size-medium” src=”https://www.bunnyshell.com/wp-content/uploads/2019/12/check-out-our-site-reliability-robot-300×55.png” alt=”check out our site reliability robot” width=”300″ height=”55″ /></a> <a href=”https://www.bunnyshell.com/devops/” id=”check-out-srr-image”><img class=”alignnone wp-image-5109 size-medium” src=”https://www.bunnyshell.com/wp-content/uploads/2019/12/check-out-our-devops-automation-platform-300×54.png” alt=”check out our devops automation platform” width=”300″ height=”54″ /></a>