Dies ist der AWS CDK v2-Entwicklerhandbuch. Die ältere CDK Version 1 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 dem AWS CDK können Entwickler oder Administratoren ihre Cloud-Infrastruktur mithilfe einer unterstützten Programmiersprache definieren. CDKAnwendungen sollten in logische Einheiten wie API Datenbank- und Überwachungsressourcen unterteilt sein und optional über eine Pipeline für automatisierte Bereitstellungen verfügen. Die logischen Einheiten sollten als Konstrukte implementiert werden, die Folgendes beinhalten:

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

Dies AWS CDK spiegelt die sorgfältige Berücksichtigung der Bedürfnisse unserer Kunden und internen Teams sowie der Fehlermuster wider, die häufig bei der Bereitstellung und laufenden Wartung komplexer Cloud-Anwendungen auftreten. Wir haben festgestellt, dass Fehler häufig auf "out-of-band" Änderungen an einer Anwendung zurückzuführen sind, die nicht vollständig getestet wurden, wie z. B. Konfigurationsänderungen. Aus diesem Grund haben wir ein AWS CDK Modell entwickelt, in dem Ihre gesamte Anwendung im Code definiert ist, und zwar nicht nur die Geschäftslogik, sondern auch die Infrastruktur und Konfiguration. Auf diese Weise können vorgeschlagene Änderungen sorgfältig geprüft, in Umgebungen, die in unterschiedlichem Maße der Produktion ähneln, umfassend getestet und vollständig rückgängig gemacht werden, falls etwas schief geht.

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

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

Die Philosophie dahinter AWS CDK führt zu unseren empfohlenen Best Practices, die wir in vier große Kategorien unterteilt haben.

Bewährte Methoden für Organisationen

In der Anfangsphase der AWS CDK Einführung ist es wichtig, darüber nachzudenken, wie Sie Ihr Unternehmen auf Erfolgskurs bringen können. Es hat sich bewährt, ein Expertenteam zu haben, das dafür verantwortlich ist, den Rest des Unternehmens bei der Einführung zu schulen und zu begleitenCDK. Die Größe dieses Teams kann variieren, von ein oder zwei Personen in einem kleinen Unternehmen bis hin zu einem vollwertigen Cloud Center of Excellence (CCoE) in einem größeren Unternehmen. Dieses Team ist verantwortlich für die Festlegung von Standards und Richtlinien für die Cloud-Infrastruktur in Ihrem Unternehmen sowie für die Schulung und Betreuung von Entwicklern.

Sie CCoE könnten Hinweise dazu geben, welche Programmiersprachen für die Cloud-Infrastruktur verwendet werden sollten. Die Einzelheiten werden von Organisation zu Organisation unterschiedlich sein, aber eine gute Richtlinie trägt dazu bei, dass Entwickler die Cloud-Infrastruktur des Unternehmens verstehen und verwalten können.

Dadurch wird CCoE auch eine „landing zone“ erstellt, die Ihre Organisationseinheiten innerhalb definiert AWS. Eine landing zone ist eine vorkonfigurierte, sichere, skalierbare AWS Umgebung mit mehreren Konten, die auf Best-Practice-Blueprints basiert. Um die Dienste, aus denen sich Ihre Landing Zone zusammensetzt, miteinander zu verbinden, können Sie das Programm verwenden AWS Control Tower, das Ihr gesamtes Multi-Account-System über eine einzige Benutzeroberfläche konfiguriert und verwaltet.

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

Bewährte Methoden beim Programmieren

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.

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

Das Leitprinzip für die meisten unserer Best Practices ist, die Dinge so einfach wie möglich zu halten — aber nicht einfacher. Erhöhen Sie die Komplexität nur dann, wenn Ihre Anforderungen eine kompliziertere Lösung erfordern. Mit dem können Sie Ihren Code nach Bedarf umgestalten AWS CDK, um neuen Anforderungen gerecht zu werden. Sie müssen nicht im Voraus eine Architektur für alle möglichen Szenarien erstellen.

Passen Sie sich an das AWS Well-Architected Framework an

Das AWS Well-Architected Framework definiert eine Komponente als Code, Konfiguration und AWS Ressourcen, die zusammen eine Anforderung erfüllen. Eine Komponente ist häufig die Einheit technischen Eigentums und von anderen Komponenten losgelöst. Der Begriff Workload wird für zusammengehörige Komponenten, die geschäftlichen Mehrwert darstellen, verwendet. Eine Workload ist in vielen Fällen der Detaillierungsgrad, von dem Führungskräfte aus Wirtschaft und Technik häufig sprechen.

Eine AWS CDK Anwendung wird einer Komponente zugeordnet, wie sie im AWS Well-Architected Framework definiert ist. AWS CDK Apps sind ein Mechanismus zur Kodifizierung und Bereitstellung von Best Practices für Well-Architected-Cloud-Anwendungen. Sie können Komponenten auch als wiederverwendbare Codebibliotheken über Artefakt-Repositorys erstellen und gemeinsam nutzen, z. B. AWS CodeArtifact

Jede Anwendung beginnt mit einem einzelnen Paket in einem einzigen Repository

Ein einzelnes Paket ist der Einstiegspunkt 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 für die Bereitstellung der Anwendung. 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. (Gemeinsam genutzte Konstrukte sollten auch ihren eigenen Lebenszyklus und ihre eigene Teststrategie haben.) Abhängigkeiten zwischen Paketen im selben Repository werden von den Build-Tools Ihres Repositorys verwaltet.

Obwohl dies möglich ist, empfehlen wir nicht, mehrere Anwendungen im selben Repository abzulegen, insbesondere bei der Verwendung automatisierter Deployment-Pipelines. Dadurch wird der „Explosionsradius“ der Änderungen während der Bereitstellung vergrößert. Wenn sich mehrere Anwendungen in einem Repository befinden, 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 Sie Code je nach Codelebenszyklus oder Teambesitz in Repositorys

Wenn Pakete in mehreren Anwendungen verwendet werden, verschieben Sie sie in ihr eigenes Repository. Auf diese Weise können die Pakete von Anwendungsentwicklungssystemen, die sie verwenden, referenziert werden, und sie können auch unabhängig von den Anwendungslebenszyklen in regelmäßigen Abständen aktualisiert werden. Zunächst könnte es jedoch sinnvoll sein, alle gemeinsam genutzten Konstrukte in einem Repository abzulegen.

Verschieben Sie Pakete außerdem in ihr eigenes Repository, wenn verschiedene Teams daran arbeiten. Dies hilft, die Zugriffskontrolle durchzusetzen.

Um Pakete über Repository-Grenzen hinweg nutzen zu können, benötigen Sie ein privates Paket-Repository — ähnlich wieNPM, PyPi, oder Maven Central, aber unternehmensintern. Sie benötigen außerdem einen Release-Prozess, der das Paket erstellt, testet und im privaten Paket-Repository veröffentlicht. CodeArtifactkann 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 applications. Ihr Paketmanager hilft sicherzustellen, dass Builds wiederholbar sind. Dazu zeichnet er die spezifischen Versionen jedes Pakets auf, von dem Ihre Anwendung abhängt. Außerdem können Sie diese Abhängigkeiten auf kontrollierte Weise aktualisieren.

Gemeinsam genutzte Pakete benötigen eine andere Teststrategie. Für eine einzelne Anwendung kann es ausreichend sein, die Anwendung in einer Testumgebung bereitzustellen und zu bestätigen, dass sie weiterhin funktioniert. Gemeinsam genutzte Pakete müssen jedoch unabhängig von der Anwendung getestet werden, die sie nutzt, als ob sie der Öffentlichkeit zugänglich gemacht würden. (Ihre Organisation könnte sich dafür entscheiden, einige gemeinsam genutzte Pakete tatsächlich der Öffentlichkeit zugänglich zu machen.)

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

Infrastruktur und Laufzeitcode befinden sich im selben Paket

Neben der Generierung von AWS CloudFormation Vorlagen für die Bereitstellung der Infrastruktur werden AWS CDK auch Laufzeitressourcen wie Lambda-Funktionen und Docker-Images gebündelt und zusammen mit Ihrer Infrastruktur bereitgestellt. Dadurch ist es möglich, den Code, der Ihre Infrastruktur definiert, und den Code, der Ihre Laufzeitlogik implementiert, in einem einzigen Konstrukt zu kombinieren. Es ist eine bewährte Methode, dies zu tun. 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 ihrer 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 gemeinsam nutzen und wiederverwenden und den gesamten Code synchron versionieren.

Entwickeln Sie bewährte Methoden

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 Apps. AWS CDK

Modellieren Sie mit Konstrukten, implementieren Sie sie mit Stacks

Stacks sind die Bereitstellungseinheit: Alles in einem Stapel wird zusammen bereitgestellt. Wenn Sie also die übergeordneten logischen Einheiten Ihrer Anwendung aus mehreren AWS Ressourcen erstellen, stellen Sie jede logische Einheit als eine und nicht als eine Constructdar. Stack Verwenden Sie Stacks nur, um zu beschreiben, wie Ihre Konstrukte für Ihre verschiedenen Einsatzszenarien zusammengesetzt und miteinander verbunden werden sollten.

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 S3-Bucket, API Gateway, Lambda-Funktionen oder RDS Amazon-Tabellen), zu einem einzigen übergeordneten Konstrukt zusammengesetzt werden. Dann sollte dieses Konstrukt zur Bereitstellung in einem oder mehreren Stacks instanziiert werden.

Indem Sie Konstrukte für den Aufbau und Stacks für die Bereitstellung verwenden, verbessern Sie das Wiederverwendungspotenzial Ihrer Infrastruktur und gewinnen mehr Flexibilität bei der Bereitstellung.

Konfigurieren Sie mit Eigenschaften und Methoden, nicht mit Umgebungsvariablen

Die Suche nach Umgebungsvariablen innerhalb von Konstrukten und Stacks ist ein gängiges Anti-Muster. Sowohl Konstrukte als auch Stacks sollten ein Eigenschaftenobjekt akzeptieren, um eine vollständige Konfigurierbarkeit im Code zu ermöglichen. Andernfalls entsteht eine Abhängigkeit von dem Computer, auf dem der Code ausgeführt wird, wodurch noch mehr Konfigurationsinformationen erzeugt werden, die Sie verfolgen und verwalten müssen.

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

Testen Sie Ihre Infrastruktur in Einheiten

Um bei der Erstellung in allen Umgebungen konsistent eine vollständige Suite von Komponententests durchzuführen, vermeiden Sie Netzwerksuchen während der Synthese und modellieren Sie alle Produktionsphasen im Code. (Diese bewährten Methoden werden später behandelt.) Wenn ein einziger Commit immer zu derselben generierten Vorlage führt, können Sie den Komponententests vertrauen, die Sie schreiben, um zu bestätigen, dass die generierten Vorlagen so aussehen, wie Sie es erwarten. Weitere Informationen finden Sie unter AWS CDK Anwendungen testen.

Ändern Sie nicht die logische ID von Stateful-Ressourcen

Das Ändern der logischen ID einer Ressource führt dazu, dass die Ressource bei der nächsten Bereitstellung durch eine neue ersetzt wird. Für statusbehaftete Ressourcen wie Datenbanken und S3-Buckets oder persistente Infrastrukturen wie Amazon ist dies selten dasVPC, was Sie wollen. Seien Sie vorsichtig bei jeder Umgestaltung Ihres AWS CDK Codes, die dazu führen könnte, dass sich die ID ändert. Schreiben Sie Komponententests, die bestätigen, dass die Logik IDs Ihrer zustandsbehafteten Ressourcen statisch bleibt. Die logische ID wird von der, die id Sie bei der Instanziierung des Konstrukts angeben, und der Position des Konstrukts im Konstruktbaum abgeleitet. Weitere Informationen finden Sie unter Logisch IDs.

Konstrukte reichen für die Einhaltung der Vorschriften nicht aus

Viele Unternehmenskunden schreiben ihre eigenen Wrapper für L2-Konstrukte (die „kuratierten“ Konstrukte, die einzelne AWS Ressourcen mit integrierten, vernünftigen Standardeinstellungen und bewährten Methoden darstellen). Diese Wrapper setzen bewährte Sicherheitsverfahren wie statische Verschlüsselung und spezifische Richtlinien durch. IAM Sie könnten beispielsweise eine erstellen, MyCompanyBucket die Sie dann in Ihren Anwendungen anstelle des üblichen Amazon S3 Bucket S3-Konstrukts verwenden. Dieses Muster ist nützlich, um Sicherheitsleitlinien zu Beginn des Softwareentwicklungszyklus zu veröffentlichen, aber verlassen Sie sich nicht darauf als alleiniges Mittel zur Durchsetzung.

Verwenden Sie stattdessen AWS Funktionen wie Richtlinien zur Servicesteuerung und Berechtigungsgrenzen, um Ihre Sicherheitsvorkehrungen auf Unternehmensebene durchzusetzen. Verwenden Sie Aspekte und die AWS CDK Tools wie CloudFormation Guard, um vor der Bereitstellung Aussagen über die Sicherheitseigenschaften von Infrastrukturelementen zu treffen. Verwenden Sie es AWS CDK für das, was es am besten kann.

Denken Sie schließlich daran, dass das Schreiben Ihrer eigenen „L2+“ -Konstrukte Ihre Entwickler möglicherweise daran hindern kann, AWS CDK Pakete wie AWS Solutions Constructs oder Konstrukte von Drittanbietern von 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 besprechen wir, wie Sie Ihre AWS CDK Anwendungen schreiben und dabei Konstrukte kombinieren, um zu definieren, wie Ihre AWS Ressourcen miteinander verbunden sind.

Treffen Sie Entscheidungen zur Synthesezeit

Es AWS CloudFormation ermöglicht Ihnen zwar, Entscheidungen bei der Bereitstellung zu treffen (mit Conditions{ Fn::If }, undParameters) und AWS CDK gibt Ihnen Zugriff auf diese Mechanismen, wir raten jedoch davon ab, sie zu verwenden. Die Typen von Werten, die Sie verwenden können, und die Arten von Operationen, die Sie mit ihnen ausführen können, sind im Vergleich zu dem, was in einer allgemeinen Programmiersprache verfügbar ist, begrenzt.

Versuchen Sie stattdessen, alle Entscheidungen, z. B. welches Konstrukt instanziiert werden soll, in Ihrer AWS CDK Anwendung zu treffen, indem Sie die if Anweisungen und andere Funktionen Ihrer Programmiersprache verwenden. Beispielsweise ist ein gängiges CDK Idiom, bei dem über eine Liste iteriert und ein Konstrukt mit Werten aus jedem Element in der Liste instanziiert wird, mit Ausdrücken einfach nicht möglich. AWS CloudFormation

Behandeln Sie AWS CloudFormation es als Implementierungsdetail, das er für robuste Cloud-Bereitstellungen AWS CDK verwendet, und nicht als sprachliches Ziel. 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 Tabellen- oder Bucket-Namen in Ihrer Infrastruktur und Anwendung fest codieren, können Sie diese Infrastruktur nicht zweimal in demselben Konto bereitstellen. (Der Name, über den wir hier sprechen, ist der Name, der beispielsweise durch die bucketName Eigenschaft in einem Amazon S3 S3-Bucket-Konstrukt angegeben wird.)

Schlimmer noch, Sie können keine Änderungen an der Ressource vornehmen, die einen Austausch erfordern. Wenn eine Eigenschaft nur bei der Erstellung einer Ressource festgelegt werden kann, z. B. die KeySchema einer Amazon DynamoDB-Tabelle, dann ist diese Eigenschaft unveränderlich. Das Ändern dieser Eigenschaft erfordert eine neue Ressource. Die neue Ressource muss jedoch denselben Namen haben, um ein echter Ersatz zu sein. Sie kann jedoch nicht denselben Namen haben, solange die vorhandene Ressource diesen Namen weiterhin verwendet.

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

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

Definieren Sie Richtlinien zur Entfernung und zur Aufbewahrung von Protokollen

Die AWS CDK Versuche, Sie vor dem Verlust von Daten zu schützen, indem standardmäßig Richtlinien verwendet werden, die alles, was Sie erstellen, beibehalten. Die Standard-Entfernungsrichtlinie für Ressourcen, die Daten enthalten (wie Amazon S3 S3-Buckets und Datenbanktabellen), sieht beispielsweise nicht vor, die Ressource zu löschen, wenn sie aus dem Stack entfernt wird. Stattdessen wird die Ressource aus dem Stapel verwaist. In ähnlicher Weise CDK ist es standardmäßig so, dass alle Protokolle für immer aufbewahrt werden. In Produktionsumgebungen können diese Standardeinstellungen schnell zur Speicherung großer Datenmengen führen, die Sie eigentlich nicht benötigen, und zu einer entsprechenden AWS Rechnung.

Überlegen Sie sich genau, wie diese Richtlinien für die einzelnen Produktionsressourcen aussehen sollen, und spezifizieren Sie sie entsprechend. Wird verwendetAspekte und die AWS CDK, um die Entfernungs- und Protokollierungsrichtlinien in Ihrem Stack zu validieren.

Teilen Sie Ihre Anwendung gemäß den Bereitstellungsanforderungen in mehrere Stapel auf

Es gibt keine feste Regel dafür, wie viele Stacks Ihre Anwendung benötigt. In der Regel werden Sie die Entscheidung auf der Grundlage Ihrer Bereitstellungsmuster treffen. Beachten Sie die folgenden Richtlinien:

Verpflichten Sie sich, nicht cdk.context.json deterministisches Verhalten zu vermeiden

Determinismus ist der Schlüssel zu erfolgreichen Implementierungen. AWS CDK Eine AWS CDK App sollte im Wesentlichen das gleiche Ergebnis erzielen, wenn sie in einer bestimmten Umgebung bereitgestellt wird.

Da Ihre AWS CDK App in einer Allzweck-Programmiersprache geschrieben ist, kann sie beliebigen Code ausführen, beliebige Bibliotheken verwenden und beliebige Netzwerkaufrufe tätigen. Sie könnten beispielsweise eine verwenden, AWS SDK um einige Informationen von Ihrem AWS Konto abzurufen, während Sie Ihre App synthetisieren. Beachten Sie, dass dies zu zusätzlichen Anforderungen für die Einrichtung der Anmeldeinformationen, zu einer erhöhten Latenz und zu einer, auch wenn geringen, Wahrscheinlichkeit eines Fehlers bei jeder Ausführung führt. cdk synth

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

Selbst Aufrufe, die ausschließlich lesbar sind, sind nicht unbedingt sicher. Überlegen Sie, was passiert, wenn sich der von einem Netzwerkanruf zurückgegebene Wert ändert. Auf welchen Teil Ihrer Infrastruktur wird sich das auswirken? Was passiert mit den bereits eingesetzten Ressourcen? Im Folgenden finden Sie zwei Beispielsituationen, in denen eine plötzliche Änderung der Werte zu Problemen führen kann.

Diese Situationen können schädlich sein, da die Änderung auf der AWS Seite nach Monaten oder Jahren erfolgreicher Bereitstellungen erfolgen kann. Plötzlich schlagen Ihre Bereitstellungen „ohne Grund“ fehl und Sie haben vor langer Zeit vergessen, was Sie getan haben und warum.

Zum Glück AWS CDK beinhaltet das einen Mechanismus namens Kontext-Provider, mit dem eine Momentaufnahme nicht deterministischer Werte aufgezeichnet werden kann. Auf diese Weise können future Synthesevorgänge genau das gleiche Template erzeugen wie bei der ersten Bereitstellung. Die einzigen Änderungen in der neuen Vorlage sind die Änderungen, die Sie an Ihrem Code vorgenommen haben. Wenn Sie die .fromLookup() Methode eines Konstrukts verwenden, wird das Ergebnis des Aufrufs cdk.context.json zwischengespeichert. Sie sollten dies zusammen mit dem Rest Ihres Codes der Versionskontrolle übergeben, um sicherzustellen, dass future Ausführungen Ihrer CDK App denselben Wert verwenden. Das CDK Toolkit enthält Befehle zur Verwaltung des Kontext-Caches, sodass Sie bestimmte Einträge bei Bedarf aktualisieren können. Weitere Informationen finden Sie unter Kontextwerte und AWS CDK.

Wenn Sie einen Wert (von AWS oder woanders) benötigen, für den es keinen systemeigenen 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 als Teil Ihres regulären Build-Prozesses.

Lassen Sie sie Rollen und Sicherheitsgruppen AWS CDK verwalten

Mit den grant() praktischen Methoden der AWS CDK Construct-Bibliothek können Sie AWS Identity and Access Management Rollen erstellen, die mithilfe von Berechtigungen mit minimalem Umfang Zugriff auf eine Ressource gewähren. Stellen Sie sich zum Beispiel eine Zeile wie die folgende vor:

amzn-s3-demo-bucket.grantRead(myLambda)

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

Wenn Sie von Entwicklern verlangen, immer vordefinierte Rollen zu verwenden, die von einem Sicherheitsteam erstellt wurden, wird die AWS CDK Codierung erheblich komplizierter. Ihre Teams könnten viel Flexibilität bei der Gestaltung ihrer Anwendungen verlieren. Eine bessere Alternative besteht darin, Richtlinien zur Dienstkontrolle und Rechtegrenzen zu verwenden, um sicherzustellen, dass Entwickler sich an die Vorgaben halten.

Modellieren Sie alle Produktionsphasen im Code

In herkömmlichen AWS CloudFormation Szenarien besteht Ihr Ziel darin, ein einzelnes Artefakt zu erzeugen, das so parametrisiert ist, dass es in verschiedenen Zielumgebungen bereitgestellt werden kann, nachdem Sie für diese Umgebungen spezifische Konfigurationswerte angewendet haben. In der CDK können und sollten Sie diese Konfiguration in Ihren Quellcode einbauen. Erstellen Sie einen Stack für Ihre Produktionsumgebung und erstellen Sie einen separaten Stapel für jede Ihrer anderen Phasen. Fügen Sie dann die Konfigurationswerte für jeden Stapel in den Code ein. Verwenden Sie Dienste wie Secrets Manager und Systems Manager Parameter Store für sensible Werte, die Sie nicht in die Quellcodeverwaltung einchecken möchten, und verwenden Sie dabei die Namen oder ARNs der Ressourcen.

Wenn Sie Ihre Anwendung synthetisieren, enthält die im cdk.out Ordner erstellte Cloud-Assembly eine separate Vorlage für jede Umgebung. Ihr gesamter Build ist deterministisch. Es gibt keine out-of-band Änderungen an Ihrer Anwendung, und jeder Commit ergibt immer genau dieselbe AWS CloudFormation Vorlage und die zugehörigen Assets. Das macht Unit-Tests wesentlich zuverlässiger.

Messen Sie alles

Um das Ziel einer vollständigen kontinuierlichen Bereitstellung ohne menschliches Eingreifen zu erreichen, ist ein hohes Maß an Automatisierung erforderlich. Diese Automatisierung ist nur mit umfassender Überwachung möglich. Erstellen Sie Metriken, Alarme und Dashboards, um alle Aspekte Ihrer eingesetzten Ressourcen zu messen. Hören Sie nicht damit auf, Dinge wie CPU Nutzung und Speicherplatz zu messen. Erfassen Sie auch Ihre Geschäftskennzahlen und verwenden Sie diese Messungen, um Bereitstellungsentscheidungen wie Rollbacks zu automatisieren. Die meisten L2-Konstrukte AWS CDK verfügen über praktische Methoden, mit denen Sie Metriken erstellen können, z. B. die metricUserErrors() Methode in der Klasse DynamoDB.Table.