1

Wir prüfen derzeit, ob wir für einige unserer neuen AWS-Anwendungsinfrastruktur Serverless verwenden sollen. Wir verwenden stark Cloudformation (von Ansible implementiert), daher müssen wir in der Lage sein, die Ausgaben von bestehenden Cloudformations-Stacks sauber zu referenzieren - ein direktes Beispiel wäre, die Subnetz-IDs unserer bestehenden AWS-Netzwerkinfrastruktur für eine Lambda-Funktion zu erhalten .Referenz Vorhandene Cloudformations-Stack-Ausgaben im Serverless Framework

Nach viel Surfen, habe ich nicht einen out-of-the-box Weg gesehen, dies zu tun. Unsere bestehenden Cloudformations-Stacks sind so benannt, dass ich, wenn ich nur den Namen des Stacks und die gewünschte Output-Variable eingeben könnte, die gewünschten Outputs in verschiedenen Umgebungen zuverlässig erhalten könnte. Eine mögliche Lösung, die ich sehe, ist, die Variablen mit aws cli zu ziehen und sie als Umgebungsvariablen an serverless weiterzuleiten, aber ich würde, wenn möglich, einen saubereren Weg bevorzugen.

+0

Bitte klären Sie, ob Ihre Frage zum AWS [Serverless Application Model] (https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md) (SAM) oder das [Serverless Framework] (https://serverless.com/). – wjordan

Antwort

2

Wenn die Serverless Framework können Sie Intrinsic Functions in Ihren Cloudformation-Vorlagen verwenden, können Sie create cross-stack references innerhalb einer Cloudformation-Vorlage von exporting stack output values von einem Stapel (mit der Exports Eigenschaft im Outputs Abschnitt), und mit Hilfe der Fn::ImportValue eigene Funktion in einem anderen Stapel zu Referenzieren Sie den exportierten Wert.

+0

Dies ist definitiv die beste Antwort. Wir haben Kreuzstapelreferenzen vermieden 1) b/c sie existierten nur bis vor kurzem, und 2) Ich mag die lockerere Kopplung, die von der expliziten Übergabe der Ausgaben eines Stapels als Parameter an einen anderen Stapel kommt. Ich denke, wir haben uns entschieden, dass 'sls' für unsere Bedürfnisse etwas eingeschränkt ist, aber dies wäre definitiv der Weg, wenn wir es benutzen würden. – rumdrums

0

Der einfachste Weg, den ich denken kann, um Ihren Beispielfall zu behandeln, ist, dass der Lambda boto3 verwendet, um boto3.client('cloudformation', region_name=*specified region*).describe_stacks(StackName=*specified stack*)['Stacks'] zu rufen. Diese Liste enthält alle Stacks, die dem angegebenen StackName entsprechen. Wenn Ihre gesamte Netzwerkinfrastruktur eine Teilmenge ihrer Namen gemeinsam nutzt, können Sie alle auflisten, indem Sie StackName für diesen Teilstring angeben. Jedes Stack-Objekt enthält einen 'Outputs' Block. Siehe here.

Wenn Sie dies an einer beliebigen Stelle für die einfache Verwendung bereitstellen möchten, können Sie eine API-Gateway-Methode GET an das Lambda anhängen und es einem HTML-Formular zugänglich machen.

+0

Danke für die Antwort. Das Problem, das ich bei diesem Ansatz sehe, ist, dass ich im Idealfall die Werte der Variablen * vor * habe. Ich stelle sogar die Lambda-Funktion bereit. Da die von mir bereitgestellten Funktionen eine Verbindung zu einer RDS-Instanz herstellen müssen, benötigen sie Subnetz-IDs, um eine elastische Netzwerkschnittstelle zu erstellen und Zugriff auf unser Netzwerk zu erhalten. – rumdrums

+0

@rumdrums Gibt es einen Grund, warum Sie vor der Verbindung mit RDS nicht nach den Werten suchen können? – asdf

+0

Mein Verständnis ist, dass, wenn ich die Lambda-Funktion erstellen, muss ich ihm die Subnetz-IDs geben, die es verbinden wird, wie im VpcConfig-Parameter beschrieben [hier] (http://docs.aws.amazon.com/AWSCloudFormation /latest/UserGuide/aws-properties-lambda-function-vpcconfig.html). Ich dachte nicht, dass es möglich ist, dass die Lambda-Funktion die Subnetz-IDs erhält, nachdem sie bereits bereitgestellt wurde. – rumdrums

Verwandte Themen