☰

AWS: LaunchConfig comienza antes de que se inicie la instancia NAT (CloudFormation)

tag-icon • tag-icon amazon-web-services amazon-cloudformation
AWS: LaunchConfig comienza antes de que se inicie la instancia NAT (CloudFormation)

Mi escenario

En una plantilla de CloudFormation tengo una única VPC, una subred pública y una subred privada. En la subred pública tengo una AMI NAT de Amazon en una instancia. En la subred privada tengo un grupo de escalado automático detrás de un LoadBalancer interno. Este grupo de autoScaling tiene un LaunchConfig para instalar httpd con una página web de demostración.

El problema

La instancia EC2 lanzada en este grupo de escalado automático de subred privada no instala el servidor web. Esto hace que mi ELB falle y revierta toda la pila de formación de nubes. Sin embargo, puedo acceder mediante SSH después de la creación, donde puedo obtener con éxito páginas web de Internet y usar yum install httpd manualmente. Esto soluciona mi pila de cloudFormation al hacer feliz la verificación de ELB. /var/log/cloudinit-output.log dice que la instancia no pudo resolver el repositorio de amazon yum durante su inicialización.

Tengo la sensación de que esto puede deberse a que LaunchConfig se inició en una nueva instancia EC2 antes de que la instancia NAT esté completamente operativa y en funcionamiento. Intenté agregar 'DependsOn': 'NATInstance' al grupo AutoScaling pero esto no solucionó el problema.

¿Puede usted ayudar?

Respuesta1

Cloudwatcher estuvo en lo cierto con su respuesta, sin embargo, me gustaría dar más detalles para cualquiera que tenga un problema similar en el futuro.

El atributo 'DependsOn' en una plantilla de CloudFormation se cumple cuando un recurso indica que ya está hecho. De forma predeterminada, creo que esto es cuando Amazon creó el recurso. En mi ejemplo, la instancia NAT realmente se creó, que es cuando la instancia estaba señalizando. Sin embargo, la configuración y los ajustes dentro de la instancia no se habían completado, por lo que la NAT permaneció no operativa antes de que otras instancias intentaran utilizarla. Luego, las otras instancias fallaron porque no pudieron obtener una conexión a Internet a través de la instancia NAT.

Puede anular manualmente la señalización predeterminada usted mismo. Esto significa que puede realizar sus acciones y LUEGO señalar una vez que esté hecho. El atributo 'DependsOn' para todos los demás recursos que dependen de él funcionará correctamente. Para ello, utilice algunos scripts auxiliares de Amazon dentro de una instancia EC2, específicamente 'cfn-init' y 'cfn-signal'. En su propiedad 'UserData' para una instancia EC2 (o un grupo de escalado automático), puede instalar aws-cfn-bootstrap para obtener los scripts (o cualquier administrador de paquetes que esté utilizando). Luego puede realizar los pasos de inicialización dentro de UserData y, una vez completados, indicar que los recursos están terminados mediante cfn-signal. Aquí está mi ejemplo:

"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 esto ayude a alguien.

Respuesta2

Hay varias cosas a considerar en torno a los grupos de seguridad y similares que permiten el tráfico. Pero con respecto a NAT específicamente, asegúrese de que en la configuración de inicio de NAT no esté emitiendo el

/opt/aws/bin/cfn-signal

hasta que se completen los scripts de configuración y paso a través. Dado que "depende de" la NAT, no continuará hasta que la pila de CloudFormation reciba esta señal.

[EDITAR] Si alguien está viendo esto después de hoy (2015-12-18), realmente debería considerar trasladar el servicio administrado NAT proporcionado por AWS.https://aws.amazon.com/about-aws/whats-new/2015/12/introduciendo-amazon-vpc-nat-gateway-a-managed-nat-service/

información relacionada