Dies ist der AWS CDK v2-Entwicklerhandbuch. Das ältere CDK v1 wurde am 1. Juni 2022 in die Wartung aufgenommen und der Support wurde am 1. Juni 2023 eingestellt.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bewährte Methoden für die Entwicklung und Bereitstellung einer Cloud-Infrastruktur mit der AWS CDK

Mit der können AWS CDK Entwickler oder Administratoren ihre Cloud-Infrastruktur mithilfe einer unterstützten Programmiersprache definieren. CDK-Anwendungen sollten in logische Einheiten wie API-, Datenbank- und Überwachungsressourcen organisiert werden und optional über eine Pipeline für automatisierte Bereitstellungen verfügen. Die logischen Einheiten sollten als Konstrukte implementiert werden, einschließlich der folgenden:

Stacks definieren das Bereitstellungsmodell dieser logischen Einheiten. Eine detailliertere Einführung in die Konzepte hinter dem CDK finden Sie unter Erste Schritte mit dem AWS CDK.

Die AWS CDK spiegelt die sorgfältige Berücksichtigung der Anforderungen unserer Kunden und internen Teams sowie der Fehlermuster wider, die sich häufig während der Bereitstellung und laufenden Wartung komplexer Cloud-Anwendungen ergeben. Wir haben festgestellt, dass Fehler häufig mit „out-of-band“-Änderungen an einer Anwendung zusammenhängen, die nicht vollständig getestet wurden, z. B. Konfigurationsänderungen. Daher haben wir die AWS CDK um ein Modell herum entwickelt, in dem Ihre gesamte Anwendung im Code definiert ist, nicht nur in der Geschäftslogik, sondern auch in der Infrastruktur und Konfiguration. Auf diese Weise können vorgeschlagene Änderungen sorgfältig überprüft, in Umgebungen, die der Produktion ähneln, in unterschiedlichem Umfang umfassend getestet und im Falle eines Fehlers vollständig rückgängig gemacht werden.

Zum Zeitpunkt der Bereitstellung AWS CDK synthetisiert die eine Cloud-Baugruppe, die Folgendes enthält:

Mit dem CDK kann jeder Commit im Hauptversionsverwaltungszweig Ihrer Anwendung eine vollständige, konsistente, bereitstellbare Version Ihrer Anwendung darstellen. Ihre Anwendung kann dann automatisch bereitgestellt werden, wenn eine Änderung vorgenommen wird.

Der Rückstand hinter den AWS CDK führt zu unseren empfohlenen bewährten Methoden, die wir in vier große Kategorien unterteilt haben.

Bewährte Methoden für Organisationen

In den Anfangsphasen der AWS CDK Einführung ist es wichtig zu überlegen, wie Sie Ihre Organisation erfolgreich einrichten können. Es ist eine bewährte Methode, ein Team von Experten zu haben, das für die Schulung und Unterstützung des restlichen Unternehmens verantwortlich ist, wenn es das CDK übernimmt. Die Größe dieses Teams kann variieren, von einer oder zwei Personen in einem kleinen Unternehmen bis hin zu einem vollwertigen Cloud-Kompetenzzentrum (CCoE) in einem größeren Unternehmen. Dieses Team ist für die Festlegung von Standards und Richtlinien für die Cloud-Infrastruktur in Ihrem Unternehmen sowie für das Training und die Unterstützung von Entwicklern verantwortlich.

Das CCoE bietet möglicherweise Anleitungen dazu, welche Programmiersprachen für die Cloud-Infrastruktur verwendet werden sollten. Die Details variieren von Organisation zu Organisation, aber eine gute Richtlinie hilft sicherzustellen, dass Entwickler die Cloud-Infrastruktur des Unternehmens verstehen und verwalten können.

Das CCoE erstellt auch eine „Landing Zone“, die Ihre Organisationseinheiten innerhalb von definiert AWS. Eine Landing Zone ist eine vorkonfigurierte, sichere, skalierbare AWS Umgebung mit mehreren Konten, die auf bewährten Methoden basiert. Um die Services zu verknüpfen, aus denen Ihre Landing Zone besteht, können Sie verwendenAWS Control Tower, das Ihr gesamtes System mit mehreren Konten von einer einzigen Benutzeroberfläche aus konfiguriert und verwaltet.

Entwicklungsteams sollten in der Lage sein, ihre eigenen Konten zum Testen und Bereitstellen neuer Ressourcen in diesen Konten nach Bedarf zu verwenden. Einzelne Entwickler können diese Ressourcen als Erweiterungen ihrer eigenen Entwicklungsarbeitsstation behandeln. Mithilfe von CDK Pipelines können die AWS CDK Anwendungen dann über ein CI/CD-Konto in Test-, Integrations- und Produktionsumgebungen (jeweils isoliert in einer eigenen AWS Region oder einem eigenen Konto) bereitgestellt werden. Dazu wird der Code der Entwickler mit dem kanonischen Repository Ihrer Organisation zusammengeführt.

Bewährte Methoden für die Codierung

In diesem Abschnitt werden bewährte Methoden für die Organisation Ihres AWS CDK Codes vorgestellt. Das folgende Diagramm zeigt die Beziehung zwischen einem Team und den Code-Repositorys, Paketen, Anwendungen und Konstruktbibliotheken dieses Teams.

Starten Sie einfach und fügen Sie Komplexität nur hinzu, wenn Sie sie benötigen

Das Leitprinzip für die meisten unserer bewährten Methoden besteht darin, die Dinge so einfach wie möglich zu halten – aber nicht einfacher. Fügen Sie Komplexität nur hinzu, wenn Ihre Anforderungen eine kompliziertere Lösung vorgeben. Mit der können Sie Ihren Code nach Bedarf umgestalten AWS CDK, um neue Anforderungen zu unterstützen. Sie müssen nicht für alle möglichen Szenarien im Voraus entwerfen.

Abstimmung mit dem AWS Well-Architected Framework

Das AWS Well-Architected Framework definiert eine Komponente als Code, Konfiguration und AWS Ressourcen, die zusammen eine Anforderung erfüllen. Eine Komponente ist oft die Einheit des technischen Eigentums und ist von anderen Komponenten entkoppelt. Der Begriff Workload wird verwendet, um eine Reihe von Komponenten zu identifizieren, die zusammen einen Geschäftswert bieten. Ein Workload ist in der Regel der Detaillierungsgrad, über den Geschäfts- und Technologieleiter kommunizieren.

Eine AWS CDK Anwendung ist einer Komponente zugeordnet, wie sie vom AWS Well-Architected Framework. AWS CDK apps definiert ist, ein Mechanismus zur Kodifizierung und Bereitstellung bewährter Methoden für Well-Architected-Cloud-Anwendungen. Sie können Komponenten auch als wiederverwendbare Codebibliotheken über Artefakt-Repositorys wie erstellen und freigeben AWS CodeArtifact.

Jede Anwendung beginnt mit einem einzigen Paket in einem einzigen Repository

Ein einzelnes Paket ist der Eintrittspunkt Ihrer AWS CDK App. Hier definieren Sie, wie und wo die verschiedenen logischen Einheiten Ihrer Anwendung bereitgestellt werden sollen. Sie definieren auch die CI/CD-Pipeline, um die Anwendung bereitzustellen. Die Konstrukte der App definieren die logischen Einheiten Ihrer Lösung.

Verwenden Sie zusätzliche Pakete für Konstrukte, die Sie in mehr als einer Anwendung verwenden. (Gemeinsame Konstrukte sollten auch ihren eigenen Lebenszyklus und ihre eigene Teststrategie haben.) Abhängigkeiten zwischen Paketen im selben Repository werden von den Build-Tools Ihres Repo verwaltet.

Obwohl dies möglich ist, empfehlen wir nicht, mehrere Anwendungen in dasselbe Repository zu legen, insbesondere wenn automatisierte Bereitstellungspipelines verwendet werden. Dadurch wird der „Explosionsradius“ der Änderungen während der Bereitstellung erhöht. Wenn mehrere Anwendungen in einem Repository vorhanden sind, lösen Änderungen an einer Anwendung die Bereitstellung der anderen aus (auch wenn sich die anderen nicht geändert haben). Darüber hinaus verhindert eine Unterbrechung in einer Anwendung, dass die anderen Anwendungen bereitgestellt werden.

Verschieben von Code in Repositorys basierend auf dem Codelebenszyklus oder der Teameigentümerschaft

Wenn Pakete in mehreren Anwendungen verwendet werden, verschieben Sie sie in ein eigenes Repository. Auf diese Weise können die Pakete von Anwendungsentwicklungssystemen referenziert werden, die sie verwenden, und sie können unabhängig von den Anwendungslebenszyklen auch in Abständen aktualisiert werden. Es könnte jedoch zunächst sinnvoll sein, alle freigegebenen Konstrukte in einem Repository abzulegen.

Verschieben Sie Pakete außerdem in ein eigenes Repository, wenn verschiedene Teams an ihnen arbeiten. Dies trägt dazu bei, die Zugriffskontrolle durchzusetzen.

Um Pakete über Repository-Grenzen hinweg zu verwenden, benötigen Sie ein privates Paket-Repository – ähnlich wie NPM PyPi, oder Maven Central, aber intern in Ihrer Organisation. Sie benötigen auch einen Release-Prozess, der das Paket erstellt, testet und im privaten Paket-Repository veröffentlicht. CodeArtifact kann Pakete für die gängigsten Programmiersprachen hosten.

Abhängigkeiten von Paketen im Paket-Repository werden vom Paketmanager Ihrer Sprache verwaltet, z. B. NPM für - TypeScript oder - JavaScript Anwendungen. Ihr Paketmanager hilft sicherzustellen, dass Builds wiederholbar sind. Dazu werden die spezifischen Versionen jedes Pakets aufgezeichnet, von dem Ihre Anwendung abhängt. Außerdem können Sie diese Abhängigkeiten kontrolliert aktualisieren.

Freigegebene Pakete benötigen eine andere Teststrategie. Für eine einzelne Anwendung reicht es möglicherweise aus, die Anwendung in einer Testumgebung bereitzustellen und zu bestätigen, dass sie weiterhin funktioniert. Freigegebene Pakete müssen jedoch unabhängig von der verbrauchenden Anwendung getestet werden, als ob sie öffentlich veröffentlicht würden. (Ihre Organisation könnte sich dafür entscheiden, tatsächlich einige freigegebene Pakete für die Öffentlichkeit freizugeben.)

Beachten Sie, dass ein Konstrukt beliebig einfach oder komplex sein kann. Ein Bucket ist ein Konstrukt, CameraShopWebsite könnte aber auch ein Konstrukt sein.

Infrastruktur- und Laufzeitcode live im selben Paket

Zusätzlich zur Generierung von AWS CloudFormation Vorlagen für die Bereitstellung der Infrastruktur bündelt die AWS CDK auch Laufzeitressourcen wie Lambda-Funktionen und Docker-Images und stellt sie zusammen mit Ihrer Infrastruktur bereit. Dadurch ist es möglich, den Code, der Ihre Infrastruktur definiert, und den Code, der Ihre Laufzeitlogik implementiert, zu einem einzigen Konstrukt zu kombinieren. Dies ist eine bewährte Methode. Diese beiden Arten von Code müssen sich nicht in separaten Repositorys oder sogar in separaten Paketen befinden.

Um die beiden Arten von Code gemeinsam weiterzuentwickeln, können Sie ein eigenständiges Konstrukt verwenden, das eine Funktionalität, einschließlich seiner Infrastruktur und Logik, vollständig beschreibt. Mit einem eigenständigen Konstrukt können Sie die beiden Arten von Code isoliert testen, den Code projektübergreifend freigeben und wiederverwenden und den gesamten Code synchron versionieren.

Bewährte Methoden für die Erstellung von

Dieser Abschnitt enthält bewährte Methoden für die Entwicklung von Konstrukten. Konstrukte sind wiederverwendbare, zusammensetzbare Module, die Ressourcen kapseln. Sie sind die Bausteine von AWS CDK Apps.

Modell mit Konstrukten, Bereitstellung mit Stacks

Stacks sind die Bereitstellungseinheit: alles in einem Stack wird zusammen bereitgestellt. Wenn Sie also die übergeordneten logischen Einheiten Ihrer Anwendung aus mehreren AWS Ressourcen erstellen, stellen Sie jede logische Einheit als darConstruct, nicht als Stack. Verwenden Sie Stacks nur, um zu beschreiben, wie Ihre Konstrukte für Ihre verschiedenen Bereitstellungsszenarien zusammengestellt und verbunden werden sollen.

Wenn es sich bei einer Ihrer logischen Einheiten beispielsweise um eine Website handelt, sollten die Konstrukte, aus denen sie besteht (z. B. ein Amazon S3-Bucket, API Gateway, Lambda-Funktionen oder Amazon-RDS-Tabellen), in einem einzigen übergeordneten Konstrukt zusammengesetzt werden. Dann sollte dieses Konstrukt zur Bereitstellung in einem oder mehreren Stacks instanziiert werden.

Durch die Verwendung von Konstrukten für die Erstellung und Stacks für die Bereitstellung verbessern Sie das Wiederverwendungsmöglichkeiten Ihrer Infrastruktur und geben Ihnen mehr Flexibilität bei der Bereitstellung.

Konfigurieren mit Eigenschaften und Methoden, nicht mit Umgebungsvariablen

Suchen nach Umgebungsvariablen innerhalb von Konstrukten und Stacks sind ein gängiges Anti-Muster. Sowohl Konstrukte als auch Stacks sollten ein Eigenschaftenobjekt akzeptieren, um eine vollständige Konfiguration vollständig im Code zu ermöglichen. Andernfalls führt dies zu einer Abhängigkeit von der Maschine, auf der der Code ausgeführt wird, wodurch noch mehr Konfigurationsinformationen erstellt werden, die Sie verfolgen und verwalten müssen.

Im Allgemeinen sollten Umgebungsvariablen-Lookups auf die oberste Ebene einer AWS CDK App beschränkt sein. Sie sollten auch verwendet werden, um Informationen zu übergeben, die für die Ausführung in einer Entwicklungsumgebung benötigt werden. Weitere Informationen finden Sie unter Umgebungen.

Komponententest Ihrer Infrastruktur

Um in allen Umgebungen konsistent eine vollständige Suite von Einheitentests zur Erstellungszeit durchzuführen, vermeiden Sie Netzwerk-Lookups während der Synthetisierung und modellieren Sie alle Ihre Produktionsphasen im Code. (Diese bewährten Methoden werden später behandelt.) Wenn ein einzelner Commit immer zu derselben generierten Vorlage führt, können Sie den von Ihnen geschriebenen Einheitentests vertrauen, um zu bestätigen, dass die generierten Vorlagen wie erwartet aussehen. Weitere Informationen finden Sie unter Konstrukte testen.

Ändern Sie die logische ID von zustandsbehafteten Ressourcen nicht

Das Ändern der logischen ID einer Ressource führt dazu, dass die Ressource bei der nächsten Bereitstellung durch eine neue ersetzt wird. Bei statusbehafteten Ressourcen wie Datenbanken und S3-Buckets oder einer persistenten Infrastruktur wie einer Amazon VPC ist dies selten, was Sie möchten. Seien Sie vorsichtig bei einem Faktorwechsel Ihres AWS CDK Codes, der dazu führen könnte, dass sich die ID ändert. Schreiben Sie Einheitentests, die bestätigen, dass die logischen IDs Ihrer statusbehafteten Ressourcen statisch bleiben. Die logische ID wird von der abgeleitet, die id Sie angeben, wenn Sie das Konstrukt instanziieren, und von der Position des Konstrukts in der Konstruktstruktur. Weitere Informationen finden Sie unter Logische IDs.

Konstrukte reichen für Compliance nicht aus

Viele Unternehmenskunden schreiben ihre eigenen Wrapper für L2-Konstrukte (die „kuratierten“ Konstrukte, die einzelne AWS Ressourcen mit integrierten verzweigten Standardeinstellungen und bewährten Methoden darstellen). Diese Wrapper setzen bewährte Sicherheitsmethoden wie statische Verschlüsselung und spezifische IAM-Richtlinien durch. Sie können beispielsweise eine erstellen, MyCompanyBucket die Sie dann in Ihren Anwendungen anstelle des üblichen Amazon S3-BucketKonstrukts verwenden. Dieses Muster ist nützlich, um zu Beginn des Lebenszyklus der Softwareentwicklung Sicherheitsempfehlungen zu erhalten, aber verlassen Sie sich nicht darauf als einzige Möglichkeit der Durchsetzung.

Verwenden Sie stattdessen AWS Funktionen wie Service-Kontrollrichtlinien und Berechtigungsgrenzen, um Ihre Sicherheitsvorkehrungen auf Organisationsebene durchzusetzen. Verwenden Sie - Aspekte oder -Tools wie CloudFormation Guard, um vor der Bereitstellung Aussagen über die Sicherheitseigenschaften von Infrastrukturelementen zu treffen. Verwenden Sie AWS CDK für das, was es am besten macht.

Beachten Sie schließlich, dass das Schreiben Ihrer eigenen „L2+“-Konstrukte Ihre Entwickler daran hindern kann, AWS CDK Pakete wie AWS Lösungskonstrukte oder Konstrukte von Drittanbietern aus dem Construct Hub zu nutzen. Diese Pakete basieren in der Regel auf AWS CDK Standardkonstrukten und können Ihre Wrapper-Konstrukte nicht verwenden.

Bewährte Methoden für Anwendungen

In diesem Abschnitt wird beschrieben, wie Sie Ihre AWS CDK Anwendungen schreiben und Konstrukte kombinieren, um zu definieren, wie Ihre AWS Ressourcen verbunden sind.

Treffen Sie Entscheidungen zur Generierungszeit

Obwohl es Ihnen AWS CloudFormation ermöglicht{ Fn::If }, Entscheidungen zur Bereitstellungszeit zu treffen (mit Conditions, und Parameters), und Ihnen einen gewissen Zugriff auf diese Mechanismen AWS CDK bietet, empfehlen wir, sie nicht zu verwenden. Die Arten von Werten, die Sie verwenden können, und die Arten von Operationen, die Sie für sie ausführen können, sind im Vergleich zu den verfügbaren Werten in einer Programmiersprache für allgemeine Zwecke begrenzt.

Versuchen Sie stattdessen, alle Entscheidungen, z. B. welches Konstrukt instanziiert werden soll, in Ihrer AWS CDK Anwendung unter Verwendung der if Anweisungen und anderen Funktionen Ihrer Programmiersprache zu treffen. Beispielsweise ist ein häufiger CDK-Ausdruck, der über eine Liste iteriert und ein Konstrukt mit Werten aus jedem Element in der Liste instanziiert, einfach nicht möglich, AWS CloudFormation Ausdrücke zu verwenden.

Behandeln Sie AWS CloudFormation als Implementierungsdetail, das die für robuste Cloud-Bereitstellungen AWS CDK verwendet, nicht als Sprachziel. Sie schreiben keine AWS CloudFormation Vorlagen in TypeScript oder Python, Sie schreiben CDK-Code, der zufällig CloudFormation für die Bereitstellung verwendet wird.

Verwenden Sie generierte Ressourcennamen, keine physischen Namen

Namen sind eine wertvolle Ressource. Jeder Name kann nur einmal verwendet werden. Wenn Sie also einen Tabellennamen oder Bucket-Namen in Ihrer Infrastruktur und Anwendung fest codieren, können Sie diesen Infrastrukturbereich nicht zweimal im selben Konto bereitstellen. (Der Name, über den wir hier sprechen, ist der Name, der beispielsweise durch die bucketName Eigenschaft auf einem Amazon S3-Bucket-Konstrukt angegeben wird.)

Schlimmer noch, Sie können keine Änderungen an der Ressource vornehmen, die eine Ersetzung erfordert. Wenn eine Eigenschaft nur bei der Ressourcenerstellung festgelegt werden kann, z. B. bei KeySchema einer Amazon-DynamoDB-Tabelle, ist diese Eigenschaft unveränderlich. Um diese Eigenschaft zu ändern, ist eine neue Ressource erforderlich. Die neue Ressource muss jedoch denselben Namen haben, um ein echter Ersatz zu sein. Es darf jedoch nicht denselben Namen haben, während die vorhandene Ressource diesen Namen noch verwendet.

Ein besserer Ansatz besteht darin, so wenige Namen wie möglich anzugeben. Wenn Sie Ressourcennamen weglassen, AWS CDK generiert die sie für Sie auf eine Weise, die keine Probleme verursacht. Angenommen, Sie haben eine Tabelle als Ressource. Anschließend können Sie den generierten Tabellennamen als Umgebungsvariable an Ihre AWS Lambda Funktion übergeben. In Ihrer AWS CDK Anwendung können Sie den Tabellennamen als referenzierentable.tableName. Alternativ können Sie beim Start eine Konfigurationsdatei auf Ihrer Amazon EC2-Instance generieren oder den tatsächlichen Tabellennamen in den AWS Systems Manager Parameter Store schreiben, damit Ihre Anwendung ihn von dort aus lesen kann.

Wenn es sich bei dem benötigten Stack um einen anderen AWS CDK Stack handelt, ist das noch einfacher. Angenommen, ein Stack definiert die Ressource und ein anderer Stack muss sie verwenden, gilt Folgendes:

Definieren von Entfernungsrichtlinien und Protokollaufbewahrung

Der AWS CDK versucht, Sie daran zu hindern, Daten zu verlieren, indem er standardmäßig Richtlinien verwendet, die alles enthalten, was Sie erstellen. Die standardmäßige Entfernungsrichtlinie für Ressourcen, die Daten enthalten (z. B. Amazon S3-Buckets und Datenbanktabellen), besteht beispielsweise darin, die Ressource nicht zu löschen, wenn sie aus dem Stack entfernt wird. Stattdessen ist die Ressource aus dem Stack verwaist. In ähnlicher Weise ist die Standardeinstellung des CDK, alle Protokolle dauerhaft beizubehalten. In Produktionsumgebungen können diese Standardwerte schnell zur Speicherung großer Datenmengen, die Sie nicht wirklich benötigen, und zu einer entsprechenden AWS Rechnung führen.

Überlegen Sie sorgfältig, was diese Richtlinien für jede Produktionsressource sein sollen, und geben Sie sie entsprechend an. Verwenden Sie Aspekte, um die Entfernungs- und Protokollierungsrichtlinien in Ihrem Stack zu validieren.

Trennen Sie Ihre Anwendung gemäß den Bereitstellungsanforderungen in mehrere Stacks

Es gibt keine feste und schnelle Regel für die Anzahl der Stacks, die Ihre Anwendung benötigt. In der Regel treffen Sie die Entscheidung zu Ihren Bereitstellungsmustern. Beachten Sie die folgenden Richtlinien:

Bekennen Sie sichcdk.context.json, um nicht deterministisches Verhalten zu vermeiden

Determinismus ist der Schlüssel zu erfolgreichen AWS CDK Bereitstellungen. Eine AWS CDK App sollte bei jeder Bereitstellung in einer bestimmten Umgebung im Wesentlichen dasselbe Ergebnis haben.

Da Ihre AWS CDK App in einer Programmiersprache für allgemeine Zwecke geschrieben ist, kann sie beliebigen Code ausführen, beliebige Bibliotheken verwenden und beliebige Netzwerkaufrufe tätigen. Sie könnten beispielsweise ein AWS SDK verwenden, um einige Informationen aus Ihrem AWS Konto abzurufen, während Sie Ihre App synthetisieren. Beachten Sie, dass dies zu zusätzlichen Einrichtungsanforderungen für Anmeldeinformationen, einer erhöhten Latenz und einer Wahrscheinlichkeit eines Fehlers führt, wenn Sie ausführencdk synth.

Ändern Sie niemals Ihr AWS Konto oder Ihre Ressourcen während der Generierung. Das Synthetisieren einer App sollte keine Nebenwirkungen haben. Änderungen an Ihrer Infrastruktur sollten erst in der Bereitstellungsphase erfolgen, nachdem die AWS CloudFormation Vorlage generiert wurde. Auf diese Weise AWS CloudFormation kann bei einem Problem die Änderung automatisch rückgängig machen. Um Änderungen vorzunehmen, die nicht einfach innerhalb des AWS CDK Frameworks vorgenommen werden können, verwenden Sie benutzerdefinierte Ressourcen, um bei der Bereitstellung beliebigen Code auszuführen.

Selbst strikt schreibgeschützte Aufrufe sind nicht unbedingt sicher. Überlegen Sie, was passiert, wenn sich der von einem Netzwerkaufruf zurückgegebene Wert ändert. Welchen Teil Ihrer Infrastruktur wird sich dies auswirken? Was passiert mit bereits bereitgestellten Ressourcen? Im Folgenden finden Sie zwei Beispielsituationen, in denen eine plötzliche Änderung der Werte ein Problem verursachen kann.

Diese Situationen können unheimlich sein, da die AWS-seitige Änderung nach Monaten oder Jahren erfolgreicher Bereitstellungen auftreten kann. Plötzlich schlagen Ihre Bereitstellungen „ohne Grund“ fehl und Sie haben lange vergessen, was Sie getan haben und warum.

Glücklicherweise AWS CDK enthält das einen Mechanismus namens Kontextanbieter, um einen Snapshot nicht deterministischer Werte aufzuzeichnen. Auf diese Weise können zukünftige Synthetisierungsvorgänge genau dieselbe Vorlage erzeugen wie bei der ersten Bereitstellung. Die einzigen Änderungen in der neuen Vorlage sind die Änderungen, die Sie in Ihrem Code vorgenommen haben. Wenn Sie die .fromLookup() Methode eines Konstrukts verwenden, wird das Ergebnis des Aufrufs in zwischengespeichertcdk.context.json. Sie sollten dies zusammen mit dem Rest Ihres Codes an die Versionskontrolle übergeben, um sicherzustellen, dass zukünftige Ausführungen Ihrer CDK-App denselben Wert verwenden. Das CDK Toolkit enthält Befehle zur Verwaltung des Kontext-Caches, sodass Sie bei Bedarf bestimmte Einträge aktualisieren können. Weitere Informationen finden Sie unter Laufzeitkontext.

Wenn Sie einen Wert (von AWS oder anderswo) benötigen, für den es keinen nativen CDK-Kontextanbieter gibt, empfehlen wir, ein separates Skript zu schreiben. Das Skript sollte den Wert abrufen und in eine Datei schreiben und diese Datei dann in Ihrer CDK-App lesen. Führen Sie das Skript nur aus, wenn Sie den gespeicherten Wert aktualisieren möchten, nicht im Rahmen Ihres regulären Build-Prozesses.

Lassen Sie die Rollen und Sicherheitsgruppen AWS CDK verwalten

Mit den grant() Convenience-Methoden der AWS-CDK-Konstruktbibliothek können Sie AWS Identity and Access Management Rollen erstellen, die Zugriff auf eine Ressource durch eine andere gewähren, indem Sie minimal begrenzte Berechtigungen verwenden. Betrachten Sie beispielsweise eine Zeile wie die folgende:

myBucket.grantRead(myLambda)

Diese einzelne Zeile fügt der Rolle der Lambda-Funktion (die auch für Sie erstellt wird) eine Richtlinie hinzu. Diese Rolle und ihre Richtlinien umfassen mehr als ein Dutzend Zeilen, CloudFormation die Sie nicht schreiben müssen. Die AWS CDK gewährt nur die Mindestberechtigungen, die die Funktion zum Lesen aus dem Bucket benötigt.

Wenn Entwickler immer vordefinierte Rollen verwenden müssen, die von einem Sicherheitsteam erstellt wurden, wird die AWS CDK Codierung viel komplizierter. Ihre Teams verlieren möglicherweise viel Flexibilität bei der Entwicklung ihrer Anwendungen. Eine bessere Alternative besteht darin, Service-Kontrollrichtlinien und Berechtigungsgrenzen zu verwenden, um sicherzustellen, dass Entwickler innerhalb des Integritätsschutzes bleiben.

Modellieren aller Produktionsphasen im Code

In herkömmlichen AWS CloudFormation Szenarien besteht Ihr Ziel darin, ein einzelnes Artefakt zu erzeugen, das parametrisiert ist, damit es in verschiedenen Zielumgebungen bereitgestellt werden kann, nachdem Konfigurationswerte angewendet wurden, die für diese Umgebungen spezifisch sind. Im CDK können und sollten Sie diese Konfiguration in Ihren Quellcode integrieren. Erstellen Sie einen Stack für Ihre Produktionsumgebung und einen separaten Stack für jede Ihrer anderen Phasen. Geben Sie dann die Konfigurationswerte für jeden Stack in den Code ein. Verwenden Sie -Services wie Secrets Manager und Systems Manager Parameter Store für sensible Werte, die Sie nicht bei der Quellsteuerung anmelden möchten, indem Sie die Namen oder ARNs dieser Ressourcen verwenden.

Wenn Sie Ihre Anwendung synthetisieren, enthält die im cdk.out Ordner erstellte Cloud-Baugruppe für jede Umgebung eine separate Vorlage. Ihr gesamter Build ist deterministisch. Es gibt keine out-of-band Änderungen an Ihrer Anwendung, und jeder bestimmte Commit führt immer zu genau derselben AWS CloudFormation Vorlage und denselben zugehörigen Komponenten. Dadurch werden Komponententests viel zuverlässiger.

Alles messen

Um das Ziel einer vollständigen kontinuierlichen Bereitstellung ohne menschliche Eingriffe zu erreichen, ist ein hohes Maß an Automatisierung erforderlich. Diese Automatisierung ist nur mit umfangreichen Überwachungsmengen möglich. Um alle Aspekte Ihrer bereitgestellten Ressourcen zu messen, erstellen Sie Metriken, Alarme und Dashboards. Halten Sie nicht an, um Dinge wie CPU-Auslastung und Festplattenspeicher zu messen. Zeichnen Sie auch Ihre Geschäftsmetriken auf und verwenden Sie diese Messungen, um Bereitstellungsentscheidungen wie Rollbacks zu automatisieren. Die meisten L2-Konstrukte in AWS CDK verfügen über praktische Methoden, die Ihnen beim Erstellen von Metriken helfen, z. B. die metricUserErrors() Methode in der Klasse dynamodb.Table.