- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
Thanks to everyone! Your answers helped me a lot
I review the problem described here and realized that the main problem was actually with the EBS volumes, the EBS encryptions were enabled by default and somehow my current EB applications version cannot support encrypted EBS.
That's where the "client error on launch" comes from.
Consider temporarily suspending and resuming a process for an Auto Scaling group. Be aware it can prevent other processes from functioning properly but it may give you an avenue to investigate what is going on and track down the source of the issue.
I was able to get into one of the EC2 before it was terminated, and I got the following warning
Failed to describe volume 'vol-015a..': The volume 'vol-015a..' does not exist
Looking at the IAM role attached to Beanstalk I realize I didn't have specific allow permission for:
DescribeVolumes, AttachVolume, CreateVolume, DeleteVolume, DetachVolume
Could be this the reason why the ASG set as unhealthy almost in an immediate way those instances?
When I saw behavior like this, I extended how long the Auto scalinggroup waited after the deploy to check for HealthCheck. in my case, the instances simply needed more time.
in .ebextensions/00_autoscaling.config
Resources:
AWSEBAutoScalingGroup:
Type: "AWS::AutoScaling::AutoScalingGroup"
Properties:
HealthCheckType: ELB
HealthCheckGracePeriod: 600 # wait 2x the default before checking
This doc has a section on HealthCheckGracePeriod https://docs.aws.amazon.com/autoscaling/ec2/userguide/healthcheck.html
Also, grab the logs from the server: in some cases the nginx / access logs can help to understand if the healthcheck is reaching your instance, but is returning non 200s.
Contenuto pertinente
- AWS UFFICIALEAggiornata 9 mesi fa
- AWS UFFICIALEAggiornata 8 mesi fa
- AWS UFFICIALEAggiornata 8 mesi fa
Here's the process for allowing customer managed keys to run on an ASG: https://docs.aws.amazon.com/autoscaling/ec2/userguide/key-policy-requirements-EBS-encryption.html
Alternatively, use an AWS Managed KMS key for the encryption and no additional configuration will be needed