☰

AWS — запуск LaunchConfig до инициализации экземпляра NAT (CloudFormation)

tag-icon • tag-icon amazon-web-services amazon-cloudformation
AWS — запуск LaunchConfig до инициализации экземпляра NAT (CloudFormation)

Мой сценарий

В шаблоне CloudFormation у меня есть один VPC, публичная подсеть и частная подсеть. В публичной подсети у меня есть Amazon NAT AMI в экземпляре. В частной подсети у меня есть группа автомасштабирования за внутренним LoadBalancer. Эта группа автомасштабирования имеет LaunchConfig для установки httpd с демонстрационной веб-страницей.

Проблема

Экземпляр EC2, запущенный в этой частной группе автомасштабирования подсети, не устанавливает веб-сервер. Это приводит к сбою моего ELB и откату всего стека cloudformation. Однако я могу войти по SSH после создания, где я могу успешно получить веб-страницы интернета и вручную использовать yum install httpd. Это исправляет мой стек cloudFormation, делая проверку ELB успешной. /var/log/cloudinit-output.log сообщает, что экземпляр не смог разрешить репозиторий amazon yum во время инициализации.

У меня есть ощущение, что это может быть вызвано тем, что LaunchConfig был запущен в новом экземпляре EC2 до того, как экземпляр NAT полностью запущен и работает. Я пробовал добавлять 'DependsOn' : 'NATInstance' в группу AutoScaling, но это не решило проблему.

Вы можете помочь?

решение1

Cloudwatcher был прав в своем ответе, однако я хотел бы дать более развернутый ответ для тех, у кого в будущем возникнет похожая проблема.

Атрибут 'DependsOn' в шаблоне CloudFormation выполняется, когда ресурс подает сигнал о завершении. По умолчанию я считаю, что это происходит, когда Amazon создает ресурс. В моем примере экземпляр NAT был фактически создан, что соответствует моменту, когда экземпляр подает сигнал. Однако конфигурация и настройки внутри экземпляра не были завершены, поэтому NAT оставался неработоспособным до того, как другие экземпляры попытались его использовать. Затем другие экземпляры вышли из строя, поскольку не смогли получить подключение к Интернету через экземпляр NAT.

Вы можете вручную переопределить сигнализацию по умолчанию самостоятельно. Это означает, что вы можете выполнить свои действия и ПОТОМ подать сигнал, как только они будут выполнены. Атрибут «DependsOn» для всех других ресурсов, зависящих от него, будет работать правильно. Вы делаете это, используя некоторые вспомогательные скрипты Amazon внутри экземпляра EC2, в частности «cfn-init» и «cfn-signal». В свойстве «UserData» для экземпляра EC2 (или группы автоматического масштабирования) вы устанавливаете yum install 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"
            ]]}}

Я надеюсь, что это помогает кому-то.

решение2

Есть несколько вещей, которые следует учитывать в отношении групп безопасности и таких, как разрешение трафика. Но что касается конкретно NAT, убедитесь, что в конфигурации запуска NAT вы не выдаете

/opt/aws/bin/cfn-signal

пока не будут завершены ваши сценарии настройки и сквозного прохождения. Учитывая, что вы "DependsOn" NAT, он не продолжит работу, пока стек CloudFormation не получит этот сигнал.

[ПРАВКА] Если кто-то смотрит на это после сегодняшнего дня (18.12.2015), вам действительно следует рассмотреть возможность переноса управляемой службы NAT, предоставляемой AWS.https://aws.amazon.com/about-aws/whats-new/2015/12/introducing-amazon-vpc-nat-gateway-a-managed-nat-service/

Связанный контент