How to achieve zero-downtime during the deployments?

1.	How to achieve zero-downtime during the deployments?
Answer» As the name suggests, zero-downtime deployments do not bring outage in a production environment. It is a clever way of deploying your changes to production, where at any given point in time, at least one service will remain available to customers. Blue-green deployment One way of achieving this is blue/green deployment. In this approach, two versions of a single microservice are deployed at a time. But only one version is taking real requests. Once the newer version is tested to the required satisfaction level, you can switch from older version to newer version. You can run a smoke-test suite to verify that the functionality is running correctly in the newly deployed version. Based on the results of smoke-test, newer version can be released to BECOME the live version. Changes required in CLIENT code to handle zero-downtime Lets say you have two instances of a service running at the same time, and both are registered in Eureka registry. Further, both instances are deployed using two distinct hostnames: /src/main/resources/application.yml spring.application.name: ticketBooks-service --- spring.profiles: blue eureka.instance.hostname: ticketBooks-service -blue.example.COM --- spring.profiles: green eureka.instance.hostname: ticketBooks-service -green.example.com Now the client app that needs to make api calls to books-service may look like below: @RestController @SpringBootApplication @EnableDiscoveryClient public class ClientApp { @BEAN @LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); } @RequestMapping("/hit-some-api") public Object hitSomeApi() { return restTemplate().getForObject("https://ticketBooks-service/some-uri", Object.class); } Now, when ticketBooks-service-green.example.com goes down for upgrade, it gracefully shuts down and delete its entry from Eureka registry. But these changes will not be reflected in the ClientApp until it fetches the registry again (which happens every 30 seconds). So for upto 30 seconds, ClientApp’s @LoadBalanced RestTemplate may send the requests to ticketBooks-service-green.example.com even if its down. To fix this, we can use Spring RETRY support in Ribbon client-side load balancer. To enable Spring Retry, we need to follow the below steps: Add spring-retry to build.gradle dependencies compile("org.springframework.boot:spring-boot-starter-aop") compile("org.springframework.retry:spring-retry") Now enable spring-retry mechanism in ClientApp using @EnableRetry annotation, as shown below: @EnableRetry @RestController @SpringBootApplication @EnableDiscoveryClient public class ClientApp { ... } Once this is done, Ribbon will automatically configure itself to use retry logic and any failed request to ticketBooks-service-green.example.com com will be retried to next available instance (in round-robins fashion) by Ribbon. You can customize this behaviour using the below properties: /src/main/resources/application.yml ribbon: MaxAutoRetries: 5 MaxAutoRetriesNextServer: 5 OkToRetryOnAllOperations: true OkToRetryOnAllErrors: true

Answer»

As the name suggests, zero-downtime deployments do not bring outage in a production environment. It is a clever way of deploying your changes to production, where at any given point in time, at least one service will remain available to customers.

Blue-green deployment

One way of achieving this is blue/green deployment. In this approach, two versions of a single microservice are deployed at a time. But only one version is taking real requests. Once the newer version is tested to the required satisfaction level, you can switch from older version to newer version.

You can run a smoke-test suite to verify that the functionality is running correctly in the newly deployed version. Based on the results of smoke-test, newer version can be released to BECOME the live version.

Changes required in CLIENT code to handle zero-downtime

Lets say you have two instances of a service running at the same time, and both are registered in Eureka registry. Further, both instances are deployed using two distinct hostnames:

/src/main/resources/application.yml spring.application.name: ticketBooks-service --- spring.profiles: blue eureka.instance.hostname: ticketBooks-service -blue.example.COM --- spring.profiles: green

eureka.instance.hostname: ticketBooks-service -green.example.com

Now the client app that needs to make api calls to books-service may look like below:

@RestController @SpringBootApplication @EnableDiscoveryClient public class ClientApp { @BEAN @LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); } @RequestMapping("/hit-some-api") public Object hitSomeApi() { return restTemplate().getForObject("https://ticketBooks-service/some-uri", Object.class); }

Now, when ticketBooks-service-green.example.com goes down for upgrade, it gracefully shuts down and delete its entry from Eureka registry. But these changes will not be reflected in the ClientApp until it fetches the registry again (which happens every 30 seconds). So for upto 30 seconds, ClientApp’s @LoadBalanced RestTemplate may send the requests to ticketBooks-service-green.example.com even if its down.

To fix this, we can use Spring RETRY support in Ribbon client-side load balancer. To enable Spring Retry, we need to follow the below steps:

Add spring-retry to build.gradle dependencies

compile("org.springframework.boot:spring-boot-starter-aop") compile("org.springframework.retry:spring-retry")

Now enable spring-retry mechanism in ClientApp using @EnableRetry annotation, as shown below:

@EnableRetry @RestController @SpringBootApplication @EnableDiscoveryClient public class ClientApp { ... }

Once this is done, Ribbon will automatically configure itself to use retry logic and any failed request to ticketBooks-service-green.example.com com will be retried to next available instance (in round-robins fashion) by Ribbon. You can customize this behaviour using the below properties:

/src/main/resources/application.yml ribbon: MaxAutoRetries: 5 MaxAutoRetriesNextServer: 5 OkToRetryOnAllOperations: true OkToRetryOnAllErrors: true

How to achieve zero-downtime during the deployments?

Discussion

No Comment Found

Related InterviewSolutions

Reply to Comment