Мой сценарий
В шаблоне CloudFormation у меня есть один VPC, общедоступная подсеть и частная подсеть. В публичной подсети у меня есть amazons NAT AMI в экземпляре. В частной подсети у меня есть группа автомасштабирования за внутренним LoadBalancer. Эта группа autoScaling имеет LaunchConfig для установки httpd с демонстрационной веб-страницей.
Эта проблема
Экземпляр EC2, запущенный в этой частной группе автомасштабирования подсети, не устанавливает веб-сервер. Это приводит к сбою моего ELB и откату всего стека облачной информации. Тем не менее, я могу использовать SSH после создания, где я могу успешно просматривать веб-страницы в Интернете и вручную использовать yum install httpd. Это исправляет мой стек cloudFormation, делая проверку ELB счастливой. /var/log/cloudinit-output.log сообщает, что экземпляр не смог разрешить репозиторий amazon yum во время его инициализации.
У меня есть ощущение, что это может быть вызвано запуском LaunchConfig в новом экземпляре EC2 до того, как экземпляр NAT будет полностью запущен и заработает. Я попытался добавить DependsOn: NATInstance в группу AutoScaling, но это не устранило проблему.
Вы можете помочь?
Есть несколько вещей, которые следует учитывать в отношении групп безопасности и подобных разрешений трафика. Но что касается конкретно NAT, убедитесь, что в конфигурации запуска NAT вы не выдаете
/opt/aws/bin/cfn-signal
пока ваши сценарии установки и сквозной передачи не будут завершены. Если вы являетесь «DependsOn» NAT, он не будет продолжать работу, пока стек CloudFormation не получит этот сигнал.
[РЕДАКТИРОВАТЬ] Если кто-то обратится к этому после сегодняшнего дня (18 декабря 2015 г.), вам действительно стоит подумать о переносе управляемого сервиса NAT, предоставляемого AWS. https://aws.amazon.com/about-aws/whats-new/2015/12/introduction-amazon-vpc-nat-gateway-a-managed-nat-service/
Cloudwatcher был прав со своим ответом, однако я хотел бы уточнить для всех, у кого в будущем возникнет аналогичная проблема.
Атрибут DependsOn в шаблоне CloudFormation выполняется, когда ресурс сигнализирует об этом. По умолчанию я считаю, что это именно тогда, когда Amazon создала ресурс. В моем примере экземпляр NAT был фактически создан, когда он передавал сигналы. Однако конфигурация и настройки внутри экземпляра не были завершены, поэтому NAT оставался неработающим до того, как другие экземпляры попытались его использовать. Затем другие экземпляры не смогли получить доступ к Интернету через экземпляр NAT.
Вы можете вручную переопределить сигнализацию по умолчанию. Это означает, что вы можете выполнять свои действия и ТОГДА сигнализировать, когда это будет сделано. Атрибут «DependsOn» для всех других ресурсов, которые на него полагаются, будет работать правильно. Вы делаете это с помощью некоторых вспомогательных скриптов Amazon внутри экземпляра EC2, в частности cfn-init и cfn-signal. В свойстве UserData для экземпляра EC2 (или группы автоматического масштабирования) вы yum устанавливаете aws-cfn-bootstrap, чтобы получить скрипты (или какой-либо менеджер пакетов, который вы используете). Затем вы можете выполнить шаги инициализации внутри UserData и после завершения сигнализировать о том, что ресурсы выполнены, с помощью cfn-signal. Вот мой пример:
"UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [
"#!/bin/bash -xe\n",
"yum update -y aws-cfn-bootstrap\n",
"wget <<URL FOR YOUR INIT BASH SCRIPT HERE>> -O - | bash\n",
"/opt/aws/bin/cfn-init -v ",
" --stack ", { "Ref" : "AWS::StackName" },
" --resource <RESOURCE TO SIGNAL HERE> ",
" --region ", { "Ref" : "AWS::Region" }, "\n",
"/opt/aws/bin/cfn-signal -e $? ",
" --stack ", { "Ref" : "AWS::StackName" },
" --resource <RESOURCE TO SIGNAL HERE> ",
" --region ", { "Ref" : "AWS::Region" }, "\n"
]]}}
Я надеюсь, что это поможет кому-то.