☰

AWS - LaunchConfig iniciado antes do início da instância NAT (CloudFormation)

tag-icon • tag-icon amazon-web-services amazon-cloudformation
AWS - LaunchConfig iniciado antes do início da instância NAT (CloudFormation)

Meu cenário

Em um modelo CloudFormation, tenho uma única VPC, uma sub-rede pública e uma sub-rede privada. Na sub-rede pública tenho amazons NAT AMI em uma instância. Na sub-rede privada, tenho um grupo de escalonamento automático atrás de um LoadBalancer interno. Este grupo de autoScaling possui um LaunchConfig para instalar o httpd com uma página de demonstração.

O problema

A instância do EC2 iniciada neste grupo de escalonamento automático de sub-rede privada não instala o servidor web. Isso faz com que meu ELB falhe e reverta toda a pilha do CloudFormation. No entanto, posso fazer SSH após a criação, onde posso wget páginas da web com sucesso e usar yum install httpd manualmente. Isso corrige minha pilha cloudFormation, tornando a verificação do ELB feliz. /var/log/cloudinit-output.log diz que a instância não conseguiu resolver o repositório amazon yum durante sua inicialização.

Tenho a sensação de que isso pode ser causado pelo lançamento do LaunchConfig em uma nova instância do EC2 antes que a instância NAT esteja totalmente instalada e funcionando. Tentei adicionar 'DependsOn' : 'NATINstance' ao grupo AutoScaling, mas isso não resolveu o problema.

Você pode ajudar?

Responder1

Cloudwatcher estava correto em sua resposta, mas gostaria de explicar melhor para qualquer pessoa que tenha um problema semelhante no futuro.

O atributo 'DependsOn' em um modelo CloudFormation é atendido quando um recurso sinaliza que isso foi concluído. Por padrão, acredito que é quando a Amazon cria o recurso. No meu exemplo, a instância NAT foi realmente criada, quando a instância estava sinalizando. No entanto, a configuração e as configurações dentro da instância não foram concluídas, portanto o NAT permaneceu inoperante antes que outras instâncias tentassem usá-lo. As outras instâncias falharam porque não conseguiram uma conexão com a Internet por meio da instância NAT.

Você mesmo pode substituir manualmente a sinalização padrão. Isso significa que você pode executar suas ações e ENTÃO sinalizar quando terminar. O atributo 'DependsOn' para todos os outros recursos que dependem dele funcionará corretamente. Você faz isso usando alguns scripts auxiliares da Amazon dentro de uma instância EC2, especificamente 'cfn-init' e 'cfn-signal'. Na sua propriedade 'UserData' para uma instância EC2 (ou um grupo de escalonamento automático), você instala o aws-cfn-bootstrap para obter os scripts (ou qualquer gerenciador de pacotes que você está usando). Você pode então executar suas etapas de inicialização dentro de UserData e, uma vez concluído, sinalizar que os recursos foram concluídos usando cfn-signal. Aqui está meu exemplo:

"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"
            ]]}}

Espero que isso ajude alguém.

Responder2

Há várias coisas a serem consideradas em relação aos grupos de segurança e à permissão de tráfego. Mas com relação ao NAT especificamente, certifique-se de que na configuração de inicialização do NAT você não esteja emitindo o

/opt/aws/bin/cfn-signal

até que seus scripts de configuração e passagem sejam concluídos. Dado que você é "DependsOn", o NAT não continuará até que a pilha do CloudFormation receba este sinal.

[EDITAR] Se alguém estiver olhando para isso depois de hoje (18/12/2015), você realmente deveria considerar migrar o serviço gerenciado NAT fornecido pela AWS.https://aws.amazon.com/about-aws/whats-new/2015/12/introduzindo-amazon-vpc-nat-gateway-a-administrado-nat-service/

informação relacionada