CDK-Funktionalität in CloudFormation missbrauchen

Jedes "Infrastructure as Code"-Framework hat Vor- und Nachteile. Mein Lieblingsframework ist CloudFormation, aber ich mag die Baumansicht von CDK, also habe ich darüber nachgedacht, sie mir auszuleihen.

Was ist die Baumansicht?

AWS hat diese Funktionalität am 14. September 2022 angekündigt.

Kunden, die CDK verwenden, wünschen sich eine einfache Möglichkeit, die in einer CloudFormation-Vorlage synthetisierten Ressourcen auf das ursprüngliche CDK-Konstrukt zurückzuführen.

Normalerweise sieht die Registerkarte Ressourcen in etwa so aus:

Aber wenn Sie einen CDK-Stack bereitstellen, erhalten Sie eine neue Option: die Baumansicht! Wenn Sie in der Konsole zu dem Stack navigieren, sehen Sie Folgendes:

Wie verwendet CDK es?

Wenn Sie Ihre Konstrukte schreiben, wird jede Ressource in dem Konstrukt verschachtelt. Sie können ein Konstrukt innerhalb eines Konstrukts verwenden. Dies führt zu einer verschachtelten Baumstruktur wie dieser:

Wie Sie vielleicht schon bemerkt haben, gibt es hier einige unnötige Verschachtelungen. Auf der Stammebene haben wir nur einen Eintrag, den Namen der Umgebung aus der Pipeline. Dann folgt der Name des Stacks, den wir verwenden. Um auf die Intention dieser Funktion zurückzukommen: Es macht Sinn, aber wir sehen uns eine Stack-Bereitstellung in CloudFormation an. Also ja, das wird in dem Entwicklungskonto sein, das wir bereits kennen, weil wir uns dort angemeldet haben. Als Nächstes der Stack-Name. Wir mussten auf den Stack-Namen klicken, um zu dieser Ansicht zu gelangen. So gesehen hat es keinen Sinn, ihn hier anzuzeigen.

Die dritte Ebene wird noch interessanter. Hier befinden sich die Konstrukte, die wir innerhalb des Stacks selbst verwenden. Auf dieser Ebene gelingt es CDK recht gut, die Ressourcen in logisch verschachtelten Gruppen zu organisieren. Eine Bucket-Policy bezieht sich auf einen Bucket, ist also beispielsweise unter dem Bucket selbst verschachtelt.

Wie können wir sie missbrauchen?

Wenn Sie sich die Ressourcendefinitionen in der synthetisierten Version ansehen, können Sie sehen, wie das gemacht wird. Der Bucket enthält einige zusätzliche Metadaten wie diese:

ApplicationBucketPolicy:
 Type: AWS::S3::BucketPolicy
 Metadata:
   aws:cdk:path: Development/AppStack/StaticWebsiteConstruct/Bucket/BucketPolicy/Resource
 Properties:

Sie können damit herumspielen und die Ressourcen so organisieren, wie Sie möchten. Hier ist ein Beispiel, mit dem ich experimentiert habe:

Wie Sie sehen können, ist dies logischer aufgebaut. Wir haben die folgenden Hauptkomponenten:

• Datenbank
• DNS
• Authentifizierung
• API

Wenn Sie sich die Authentifizierung ansehen, sehen Sie, dass ich einige Auslöser habe. Wenn Sie tiefer gehen, können Sie sehen, welche Art von Auslösern. Dort finden Sie die für die Operation benötigten Ressourcen, wie Berechtigungen, Protokollgruppen und die Funktion selbst.

Bekannte Anforderungen

Als ich mit der Organisation dieser Baumansicht herumspielte, entdeckte ich die folgenden Anforderungen:

• Der Wert in aws:cdk:path muss in der verarbeiteten Vorlage eindeutig sein!
• Wenn Sie das AWS Serverless Application Model verwenden, müssen Sie sicherstellen, dass die Ressourcendefinition nicht zu mehreren Ressourcen führt. (Dies würde dazu führen, dass mehrere Werte gleich sind, was die Darstellung der Baumansicht stört).
• Wenn Sie das /Resource am Ende weglassen, wird die LogicalId in der Vorlage verwendet. Dies kann zu hässlichen Namen in der Strukturansicht führen.

Fazit

Wenn Sie Ihre CloudFormation-Vorlagen gerne organisieren, sollten Sie sich die Baumansicht ansehen. Sie wurde zwar für CDK entwickelt, aber Sie können sie auch direkt in Ihren CloudFormation-Vorlagen verwenden.

Foto von Pixabay