Назад | Перейти на главную страницу

Не удается заставить CloudFormation AutoScalingGroup работать

Я пытаюсь создать AutoScalingGroup для EC2. Я получаю следующую ошибку:

Получено 0 сигналов УСПЕШНО из 1. Невозможно удовлетворить требование 100% MinSuccessfulInstancesPercent

Экземпляр EC2 создается, но он не получает общедоступный IP-адрес или DNS.

я нашел этот другой поток посвящен той же проблеме, и в одном из ответов упоминается: «Убедитесь, что подсети, в которых будут установлены экземпляры AutoScalingGroup, могут подключаться к Интернету с помощью шлюза NAT или шлюза Интернета». Я считаю, что это проблема, но не знаю, как ее решить.

В моем VPC уже есть интернет-шлюз, но я не знаю, как сказать моей группе AutoScaling использовать его.

  PrivateSubnetOne:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      MapPublicIpOnLaunch: false
      CidrBlock: !Ref PrivateSubnetOneCidr
      AvailabilityZone:
        Fn::Select:
        - '0'
        - Fn::GetAZs: ''

  PrivateSubnetTwo:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      MapPublicIpOnLaunch: false
      CidrBlock: !Ref PrivateSubnetTwoCidr
      AvailabilityZone:
        Fn::Select:
        - '1'
        - Fn::GetAZs: ''

  WebServerAutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    DependsOn:
    - Db
    - ElasticacheCluster
    Properties:
      AvailabilityZones:
      - !GetAtt PrivateSubnetOne.AvailabilityZone
      - !GetAtt PrivateSubnetTwo.AvailabilityZone
      DesiredCapacity: 1
      HealthCheckType: 'ELB'
      HealthCheckGracePeriod: '300'
      MinSize: '1'
      MaxSize: '10'
      LaunchConfigurationName: !Ref WebServer
      LoadBalancerNames:
      - !Ref WebServerElasticLoadBalancer
      VPCZoneIdentifier:
      - !Ref PrivateSubnetOne
      - !Ref PrivateSubnetTwo
      Tags:
      - Key: Name
        Value: Web Server
        PropagateAtLaunch: true
    CreationPolicy:
      ResourceSignal:
        Timeout: PT5M
        Count: 1
    UpdatePolicy:
      AutoScalingRollingUpdate:
        MinInstancesInService: 1
        MaxBatchSize: '1'
        PauseTime: PT5M
        WaitOnResourceSignals: 'true'

Когда вы не получаете сигнала об успехе, это может быть одной из двух причин:

  1. Сигнал успеха никогда не отправлялся из экземпляра EC2
  2. Проблемы с сетью не позволили получить сигнал

Самый простой способ отладить эту проблему - подключиться к серверу EC2, чтобы вы могли проверять файлы журналов и запускать ручные тесты. Когда я говорю «подключиться», я имею в виду SSH для экземпляров Linux, RDP для Windows и т. Д. Для этого требуется, чтобы экземпляр EC2 продолжал работать достаточно долго, чтобы устранить проблему.

Способы сохранить его работоспособность при отладке проблемы:

  1. Установите время ожидания в CreationPolicy, чтобы оно было больше.
  2. Удалите CreationPolicy, чтобы CloudFormation не выходил из строя, если не было отправлено сообщение об успешном завершении.
  3. Запустите свой стек с атрибутом OnFailure DO_NOTHING вместо значения по умолчанию ROLLBACK.

Существует несколько проблем, которые могут привести к сбою сетевого подключения и невозможности получения сигнала Success.

Скорее всего, в этом случае нет SubnetRouteTableAssociation. Если вы не связываете свою подсеть с таблицей маршрутов, то подсеть будет использовать таблицу маршрутов по умолчанию. Значение по умолчанию не будет связано с вашим интернет-шлюзом или шлюзом NAT, если вы не настроите его вручную. Я предполагаю, что вы не настраивали таблицу маршрутов по умолчанию вручную, поскольку пытаетесь использовать CloudFormation, чтобы избежать ручных изменений.

Вот еще несколько возможных причин, по которым не удалось установить сетевое соединение:

  1. Сетевые ACL настроены таким образом, что они блокируют либо исходящие, либо входящие пакеты для пытающегося соединения. Любой из них предотвратит отправку данных успешным TCP-соединением.
  2. Группа безопасности EC2 настроена для предотвращения исходящего сетевого трафика.
  3. Экземпляр EC2 использует jumbo-кадры (большой сетевой MTU), но сервер или маршрутизатор в сети не поддерживает его, и вы блокируете пакеты ICMP, которые сообщают вашему экземпляру EC2, что нужно изменить его MTU. (Вряд ли, но однажды случилось со мной)