Используйте группу автоматического масштабирования приложений с ELB Healthchecks

Question

Кто-нибудь смог использовать группу автоматического масштабирования приложения с проверкой работоспособности ELB?Он заменяет экземпляры снова и снова.Есть ли способ предотвратить это?

Мой шаблон выглядит так:

Resources:
  ECSAutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      AvailabilityZones:
        - Fn::Select:
          - '0'
          - Fn::GetAZs:
            Ref: AWS::Region
        - Fn::Select:
         - '1'
         - Fn::GetAZs:
             Ref: AWS::Region
      - Fn::Select:
         - '2'
         - Fn::GetAZs:
             Ref: AWS::Region
     VPCZoneIdentifier:
       - Fn::ImportValue: !Sub ${EnvironmentName}-PrivateEC2Subnet1
       - Fn::ImportValue: !Sub ${EnvironmentName}-PrivateEC2Subnet2
       - Fn::ImportValue: !Sub ${EnvironmentName}-PrivateEC2Subnet3
    HealthCheckGracePeriod: !Ref ASGHealthCheckGracePeriod
    HealthCheckType: !Ref ASGHealthCheckType
    LaunchTemplate:
      LaunchTemplateId: !Ref ECSLaunchTemplate
      Version: 1
    MetricsCollection:
      - Granularity: 1Minute
    ServiceLinkedRoleARN:
     !Sub arn:aws:iam::${AWS::AccountId}:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling
    DesiredCapacity: !Ref ASGDesiredCapacity
    MinSize: !Ref ASGMinSize
    MaxSize: !Ref ASGMaxSize
    TargetGroupARNs:
    - Fn::ImportValue: !Sub ${EnvironmentName}-WebTGARN
      Fn::ImportValue: !Sub ${EnvironmentName}-DataTGARN
      Fn::ImportValue: !Sub ${EnvironmentName}-GeneratorTGARN
    TerminationPolicies:
    - OldestInstance

шаблон запуска выглядит так:

ECSLaunchTemplate:
  Type: AWS::EC2::LaunchTemplate
  Properties:
    LaunchTemplateName: ECSLaunchtemplate
    LaunchTemplateData:
      ImageId: !FindInMap [AWSRegionToAMI, !Ref "AWS::Region", AMI]
      InstanceType: !Ref InstanceType
      SecurityGroupIds:
      - Fn::ImportValue: !Sub ${EnvironmentName}-ECSInstancesSecurityGroupID
    IamInstanceProfile:
        Arn:
          Fn::ImportValue:
            !Sub ${EnvironmentName}-ecsInstanceProfileARN
    Monitoring:
      Enabled: true
    CreditSpecification:
      CpuCredits: standard
    TagSpecifications:
     - ResourceType: instance
       Tags:
       - Key: "keyname1"
         Value: "value1"
    KeyName:
      Fn::ImportValue:
        !Sub ${EnvironmentName}-ECSKeyPairName
    UserData:
      "Fn::Base64": !Sub
        - |
          #!/bin/bash
          yum update -y
          yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
          yum update -y aws-cfn-bootstrap hibagent
          /opt/aws/bin/cfn-init -v --region ${AWS::Region} --stack ${AWS::StackName} --resource ECSLaunchTemplate --region ${AWS::Region}
          /opt/aws/bin/cfn-signal -e $? --region ${AWS::Region} --stack ${AWS::StackName} --resource ECSAutoScalingGroup
          /usr/bin/enable-ec2-spot-hibernation
          echo ECS_CLUSTER=${ECSCluster} >> /etc/ecs/ecs.config
         PATH=$PATH:/usr/local/bin
        - ECSCluster:
            Fn::ImportValue:
              !Sub ${EnvironmentName}-ECSClusterName

Конфигурация балансировщика нагрузки выглядит следующим образомthis:

ApplicationLoadBalancerInternet:
   Type: AWS::ElasticLoadBalancingV2::LoadBalancer
   Properties:
     Name: !Sub ${EnvironmentName}-${Project}-ALB-Internet
     IpAddressType: !Ref ELBIpAddressType
     Type: !Ref ELBType
     Scheme: internet-facing
     Subnets:
     - Fn::ImportValue:
        !Sub ${EnvironmentName}-PublicSubnet1
     - Fn::ImportValue:
        !Sub ${EnvironmentName}-PublicSubnet2
     - Fn::ImportValue:
        !Sub ${EnvironmentName}-PublicSubnet3
     SecurityGroups:
     - Fn::ImportValue:
        !Sub ${EnvironmentName}-ALBInternetSecurityGroupID

Как уже говорилось, все работает нормально с проверками здоровья EC2, но когда я переключаюсь на проверки здоровья ELB, экземпляры истощаются, и ASG запускает новый экземпляр.

Merci A

Answer 1

• Я бы решил это следующим образом:
  1. Удалите этот стек.
  2. Отредактируйте шаблон и измените тип проверки работоспособности ASG на ELB (пока).
  3. Создать новый стек либо из CLI, либо из консоли.Я рекомендую CLI, поскольку вам, возможно, придется воссоздать его, и он намного проще / быстрее, чем консольный. Наиболее важным шагом является включение функции «Отключить откат» при сбое стека, в противном случае вы не сможете выяснить причину сбоя
  4. Я полагаю, вы также будете создаватьнекоторые ресурсы IAM как часть этого шаблона, поэтому примерная команда CLI будет для вашей краткой справки: aws cloudformation create-stack --stack-name Name-of-your-stack --template-body file://template.json --tags Key=Name,Value=Your_Tag_Value --profile default --region region --capabilities CAPABILITY_NAMED_IAM --disable-rollback yes
  5. Для получения дополнительной информации о требовании CAPABILITY_NAMED_IAM см. this SOответ.
  6. Теперь, когда вы создаете стек, он все равно не будет работать, но теперь мы можем устранить его.Причина, по которой мы сохранили тип проверки работоспособности на ELB на шаге 2, заключается в том, что мы на самом деле хотим, чтобы ASG заменила экземпляры при неудачных проверках работоспособности, и мы можем выяснить причину на вкладке «Журнал активности» ASG с консоли.
  7. Скорее всего, вы увидите гораздо более значимое сообщение, чем то, которое было возвращено CloudFormation.
  8. Теперь, когда у вас появилось это сообщение об ошибке, измените тип проверки работоспособности ASG.из консоли в EC2, потому что мы не хотим, чтобы ASG запускала цикл «запуска и завершения» для экземпляров EC2 .
  9. Теперь войдите в свой экземпляр EC2 и найдите журналы доступа,для хитов от вашей проверки здоровья ELB.В httpd успешная проверка работоспособности получает HTTP 408.
  10. Также обратите внимание, что если тип проверки ELB - TCP: 80, то на вашем сервере нет конфликтов портов, и если вы выбрали HTTP: 80, тоВы указали путь / файл, а также свою цель проверки связи.
  11. Поскольку в вашем сценарии также есть некоторые пользовательские данные, просмотрите также /var/log/cfn-init.log и другие записи на предмет ошибок.сообщение.Простым вариантом будет: grep error /var/log/*
  12. Теперь на этом этапе вам просто нужно убедиться, что вы успешно прошли проверку работоспособности ELB и экземпляр "в работе" за ELB, и самый важный шаг - задокументируйте все шаги по устранению неполадок, потому что вы никогда не знаете, какой из многих попыток на самом деле исправил эту проверку работоспособности.
  13. Как только вы сможете найти причину, просто поместите ее в шаблони тебе должно быть хорошо идти.На 8 шаге я видел, как много шаблонов работает неправильно.
  14. Кроме того, не забудьте еще раз изменить проверку здоровья ASG на ELB.