Deploying AWS Elastic Beanstalk with Classic Load Balancer and Auto Scaling Group
Question
A DevOps engineer has used Elastic Beanstalk to create a new Java environment with a Classic Load Balancer and an Auto Scaling Group.
In the Load Balancer, a health check has been configured with a URL as the Health check path.
It also has a Rolling Deployment policy.
The development team just released a new feature that had several big changes to the application architecture.
During the deployment of the new feature, it has failed and rolled back as the health check did not pass.
However, the health check issue is known and as expected.
Which approach can be taken so that the deployment can be successful regardless of health status?
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D.Correct Answer - D.
Refer to https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html for the health check related settings in Elastic Beanstalk deployment policies.
For the Rolling deployment type, Elastic Beanstalk waits until all instances in a batch pass the health check before moving on to the next batch.
However, if the health check fails, the deployment fails, and this batch is rolled back.
Option A is incorrect: Because the health check still fails.
So this option does not help.
Option Bis incorrect: Because even if the threshold is set lower to Degraded, the health check and the deployment still fail.
Option Cis incorrect: Because for All at once deployment, it also needs a health check to pass.
So this option does not help the deployment to pass.
Option D is CORRECT: Because health check failures can be ignored during deployment.
The configuration is as below:
The correct answer is D. In Deployment preferences, specify the Ignore health check option.
Explanation:
Elastic Beanstalk is a service provided by AWS that helps DevOps engineers deploy and manage their applications on the cloud. It provides several deployment policies, including Rolling Deployment, All at Once, and Rolling with additional batch, to allow developers to deploy their applications with minimal downtime.
In this scenario, a DevOps engineer has used Elastic Beanstalk to create a new Java environment with a Classic Load Balancer and an Auto Scaling Group. A health check has been configured with a URL as the Health check path. A Rolling Deployment policy has also been configured.
The development team released a new feature with significant changes to the application architecture. During the deployment, the health check failed, and the deployment was rolled back. The health check issue is known and expected.
To successfully deploy the new feature regardless of health status, the DevOps engineer should select the Ignore health check option in the Deployment preferences. This option allows the deployment to proceed even if the health check fails.
Option A, enlarging the Health Check Command timeout, will not help in this scenario. The health check failed because the application's architecture changed significantly, not because it took too long to respond.
Option B, lowering the Healthy threshold from OK to Degraded, is also not the correct approach. The purpose of the health check is to ensure that the application is working correctly before traffic is routed to it. Lowering the threshold could result in traffic being routed to a partially functioning application, leading to a poor user experience.
Option C, modifying the deployment policy from Rolling to All at once, is not the best option because deploying all instances simultaneously could result in a significant amount of downtime. Rolling deployment minimizes downtime by gradually shifting traffic to the new instances.
In conclusion, the correct approach is to select the Ignore health check option in the Deployment preferences to allow the deployment to proceed despite the known health check issue.
