☰

AWS – LaunchConfig wird gestartet, bevor die NAT-Instanz initiiert wird (CloudFormation)

tag-icon • tag-icon amazon-web-services amazon-cloudformation
AWS – LaunchConfig wird gestartet, bevor die NAT-Instanz initiiert wird (CloudFormation)

Mein Szenario

In einer CloudFormation-Vorlage habe ich ein einzelnes VPC, ein öffentliches Subnetz und ein privates Subnetz. Im öffentlichen Subnetz habe ich Amazons NAT AMI in einer Instanz. Im privaten Subnetz habe ich eine Autoscaling-Gruppe hinter einem internen LoadBalancer. Diese AutoScaling-Gruppe hat eine LaunchConfig, um httpd mit einer Demo-Webseite zu installieren.

Das Problem

Die in dieser privaten Subnetz-Autoscaling-Gruppe gestartete EC2-Instanz installiert den Webserver nicht. Dies führt dazu, dass mein ELB fehlschlägt und den gesamten CloudFormation-Stack zurücksetzt. Ich kann mich jedoch nach der Erstellung per SSH anmelden, wo ich erfolgreich Internet-Webseiten abrufen und yum install httpd manuell verwenden kann. Dies repariert meinen CloudFormation-Stack, indem die ELB-Prüfung erfolgreich ausgeführt wird. /var/log/cloudinit-output.log besagt, dass die Instanz das Amazon-Yum-Repository während ihrer Initialisierung nicht auflösen konnte.

Ich habe das Gefühl, dass dies daran liegen könnte, dass LaunchConfig in einer neuen EC2-Instanz gestartet wird, bevor die NAT-Instanz vollständig hochgefahren und funktionsfähig ist. Ich habe versucht, „DependsOn“: „NATInstance“ zur AutoScaling-Gruppe hinzuzufügen, aber das hat das Problem nicht behoben.

Kannst du helfen?

Antwort1

Cloudwatcher hatte mit seiner Antwort recht, ich möchte sie jedoch für alle, die in Zukunft ein ähnliches Problem haben, näher erläutern.

Das Attribut „DependsOn“ in einer CloudFormation-Vorlage wird erfüllt, wenn eine Ressource signalisiert, dass sie fertig ist. Ich glaube, das ist standardmäßig der Fall, wenn Amazon die Ressource erstellt hat. In meinem Beispiel war die NAT-Instanz tatsächlich erstellt worden, und zwar zu dem Zeitpunkt, als die Instanz signalisierte. Die Konfiguration und Einstellungen innerhalb der Instanz waren jedoch noch nicht abgeschlossen, sodass das NAT nicht betriebsbereit blieb, bevor andere Instanzen versuchten, es zu nutzen. Die anderen Instanzen schlugen dann fehl, weil sie über die NAT-Instanz keine Internetverbindung herstellen konnten.

Sie können die Standardsignalisierung manuell selbst überschreiben. Das bedeutet, dass Sie Ihre Aktionen ausführen und DANN signalisieren können, wenn sie abgeschlossen sind. Das Attribut „DependsOn“ für alle anderen Ressourcen, die darauf angewiesen sind, funktioniert dann ordnungsgemäß. Sie tun dies, indem Sie einige Amazon-Hilfsskripte in einer EC2-Instanz verwenden, insbesondere „cfn-init“ und „cfn-signal“. In Ihrer „UserData“-Eigenschaft für eine EC2-Instanz (oder eine Auto-Scaling-Gruppe) installieren Sie aws-cfn-bootstrap mit yum, um die Skripte abzurufen (oder welchen Paketmanager Sie auch immer verwenden). Sie können dann Ihre Initialisierungsschritte in UserData ausführen und nach Abschluss signalisieren, dass die Ressourcen mit cfn-signal fertig sind. Hier ist mein Beispiel:

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

Ich hoffe, das hilft jemandem.

Antwort2

Es gibt mehrere Dinge, die man bei Sicherheitsgruppen und derartigen Zugriffsberechtigungen beachten muss. Aber speziell beim NAT sollten Sie darauf achten, dass Sie in der NAT-Startkonfiguration nicht den

/opt/aws/bin/cfn-signal

bis Ihre Setup- und Passthrough-Skripte abgeschlossen sind. Da Sie „DependsOn“ vom NAT sind, wird es nicht fortgesetzt, bis der CloudFormation-Stack dieses Signal empfängt.

[BEARBEITEN] Wenn sich das jemand nach heute (18.12.2015) ansieht, sollte er wirklich in Erwägung ziehen, den von AWS bereitgestellten verwalteten NAT-Dienst zu verschieben.https://aws.amazon.com/about-aws/whats-new/2015/12/introducing-amazon-vpc-nat-gateway-a-managed-nat-service/

verwandte Informationen