Dies ist der AWS CDK v2-Entwicklerhandbuch. Das ältere CDK v1 wurde am 1. Juni 2022 gewartet 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.
Migrieren von AWS CDK v1 zu AWS CDK v2
Version 2 von AWS Cloud Development Kit (AWS CDK) ist darauf ausgelegt, das Schreiben von Infrastruktur als Code in Ihrer bevorzugten Programmiersprache zu erleichtern. In diesem Thema werden die Änderungen zwischen v1 und v2 des beschrieben AWS CDK.
Tipp
Um Stacks zu identifizieren, die mit AWS CDK v1 bereitgestellt werden, verwenden Sie das Dienstprogramm awscdk-v1-stack-
Die wichtigsten Änderungen von AWS CDK v1 zu CDK v2 sind die folgenden.
-
AWS CDK v2 konsolidiert die stabilen Teile der AWS Construct Library, einschließlich der Core-Bibliothek, in einem einzigen Paket,
aws-cdk-lib
. Entwickler müssen keine zusätzlichen Pakete mehr für die einzelnen AWS Services installieren, die sie verwenden. Dieser Single-Package-Ansatz bedeutet auch, dass Sie die Versionen der verschiedenen CDK-Bibliothekspakete nicht synchronisieren müssen.L1-Konstrukte (CfnXXXX), die die genauen Ressourcen darstellen, die in verfügbar sind AWS CloudFormation, gelten immer als stabil und sind daher in enthalten
aws-cdk-lib
. -
Experimentelle Module, bei denen wir noch mit der Community zusammenarbeiten, um neue L2- oder L3-Konstrukte zu entwickeln, sind nicht in enthalten
aws-cdk-lib
. Stattdessen werden sie als einzelne Pakete verteilt. Experimentelle Pakete werden mit einemalpha
Suffix und einer semantischen Versionsnummer benannt. Die semantische Versionsnummer entspricht der ersten Version der AWS Konstruktbibliothek, mit der sie kompatibel sind, auch mit einemalpha
Suffix. Konstrukte werden in verschoben,aws-cdk-lib
nachdem sie als stabil eingestuft wurden, sodass die Construct Library die strenge semantische Versionsverwaltung einhalten kann.Die Stabilität wird auf Serviceebene angegeben. Wenn wir beispielsweise mit der Erstellung eines oder mehrerer L2-Konstrukte für Amazon beginnen AppFlow, die bei diesem Schreiben nur L1-Konstrukte enthält, werden diese zuerst in einem Modul namens angezeigt
@aws-cdk/aws-appflow-alpha
. Dann wechseln sie zu ,aws-cdk-lib
wenn wir der Meinung sind, dass die neuen Konstrukte den grundlegenden Anforderungen der Kunden entsprechen.Sobald ein Modul als stabil eingestuft und in integriert wurde
aws-cdk-lib
, werden neue APIs unter Verwendung der im nächsten Aufzählungspunkt beschriebenen „BetaN“-Konvention hinzugefügt.Mit jeder Version des wird eine neue Version jedes experimentellen Moduls veröffentlicht AWS CDK. In den meisten Fällen müssen sie jedoch nicht synchron gehalten werden. Sie können
aws-cdk-lib
oder das experimentelle Modul jederzeit aktualisieren. Die Ausnahme besteht darin, dass zwei oder mehr verwandte experimentelle Module dieselbe Version haben müssen, wenn sie voneinander abhängen. -
Bei stabilen Modulen, denen neue Funktionen hinzugefügt werden, erhalten neue APIs (unabhängig davon, ob es sich um vollständig neue Konstrukte oder neue Methoden oder Eigenschaften auf einem vorhandenen
Beta1
Konstrukt handelt) ein Suffix, während die Arbeit läuft. (VonBeta2
, usw. befolgtBeta3
, wenn grundlegende Änderungen erforderlich sind.) Eine Version der API ohne das Suffix wird hinzugefügt, wenn die API als stabil eingestuft wird. Alle Methoden außer den neuesten (ob Beta oder Final) sind dann veraltet.Wenn wir beispielsweise
grantPower()
einem Konstrukt eine neue Methode hinzufügen, erscheint sie zunächst alsgrantPowerBeta1()
. Wenn grundlegende Änderungen erforderlich sind (z. B. ein neuer erforderlicher Parameter oder eine neue Eigenschaft), würde die nächste Version der Methode den NamengrantPowerBeta2()
usw. haben. Wenn die Arbeit abgeschlossen ist und die API abgeschlossen ist, wird die MethodegrantPower()
(ohne Suffix) hinzugefügt und die BetaN-Methoden sind veraltet.Alle Beta-APIs verbleiben bis zur nächsten Hauptversion (3.0) in der Construct Library, und ihre Signaturen werden sich nicht ändern. Wenn Sie sie verwenden, werden Warnungen zur Veralterung angezeigt. Sie sollten daher so schnell wie möglich zur endgültigen Version der API wechseln. Keine zukünftigen AWS CDK 2.x-Versionen werden Ihre Anwendung jedoch beeinträchtigen.
-
Die
Construct
Klasse wurde aus dem AWS CDK in eine separate Bibliothek zusammen mit verwandten Typen extrahiert. Dies geschieht, um die Bemühungen zur Anwendung des Construct Programming Model auf andere Domains zu unterstützen. Wenn Sie Ihre eigenen Konstrukte schreiben oder verwandte APIs verwenden, müssen Sie dasconstructs
Modul als Abhängigkeit deklarieren und geringfügige Änderungen an Ihren Importen vornehmen. Wenn Sie erweiterte Funktionen verwenden, wie z. B. das Anbinden des CDK-App-Lebenszyklus, sind möglicherweise weitere Änderungen erforderlich. Ausführliche Informationen finden Sie unter RFC. -
Veraltete Eigenschaften, Methoden und Typen in AWS CDK v1.x und seiner Construct Library wurden vollständig aus der CDK-v2-API entfernt. In den meisten unterstützten Sprachen erzeugen diese APIs Warnungen unter v1.x, sodass Sie möglicherweise bereits zu den Ersatz-APIs migriert haben. Eine vollständige Liste der veralteten APIs
in CDK v1.x ist auf verfügbar GitHub. -
Verhalten, das durch Feature-Flags in AWS CDK v1.x ausgelöst wurde, ist in CDK v2 standardmäßig aktiviert. Die früheren Feature-Flags werden nicht mehr benötigt und werden in den meisten Fällen nicht unterstützt. Einige sind immer noch verfügbar, damit Sie unter sehr spezifischen Umständen zum CDK-v1-Verhalten zurückkehren können. Weitere Informationen finden Sie unter Aktualisieren von Feature-Flags.
-
Mit CDK v2 müssen die Umgebungen, in denen Sie bereitstellen, mit dem modernen Bootstrap-Stack bootstrappt werden. Der Legacy-Bootstrap-Stack (Standard unter v1) wird nicht mehr unterstützt. CDK v2 erfordert außerdem eine neue Version des modernen Stacks. Um Ihre vorhandenen Umgebungen zu aktualisieren, starten Sie sie neu. Es ist nicht mehr erforderlich, Feature-Flags oder Umgebungsvariablen festzulegen, um den modernen Bootstrap-Stack zu verwenden.
Wichtig
Die moderne Bootstrap-Vorlage gewährt effektiv die Berechtigungen--cloudformation-execution-policies
, die von der für jedes AWS Konto in der --trust
Liste impliziert werden. Standardmäßig erweitert dies die Berechtigungen zum Lesen und Schreiben in jede Ressource im Bootstrapped-Konto. Stellen Sie sicher, dass Sie den Bootstrapping-Stack mit Richtlinien und vertrauenswürdigen Konten konfigurieren, mit denen Sie vertraut sind.
Neue Voraussetzungen
Die meisten Anforderungen für AWS CDK v2 sind dieselben wie für AWS CDK v1.x. Zusätzliche Anforderungen sind hier aufgeführt.
-
Für TypeScript Entwickler ist TypeScript 3.8 oder höher erforderlich.
-
Eine neue Version des CDK Toolkits ist für die Verwendung mit CDK v2 erforderlich. Da CDK v2 jetzt allgemein verfügbar ist, ist v2 die Standardversion bei der Installation des CDK Toolkits. Es ist abwärtskompatibel mit CDK-v1-Projekten, sodass Sie die frühere Version nur installiert lassen müssen, wenn Sie CDK-v1-Projekte erstellen möchten. Um ein Upgrade durchzuführen, geben Sie aus
npm install -g aws-cdk
.
Upgrade von der AWS CDK v2-Entwicklervorschau
Wenn Sie die CDK-v2-Entwicklervorschau verwenden, haben Sie in Ihrem Projekt Abhängigkeiten von einer Release-Candidate-Version des AWS CDK, z. B. 2.0.0-rc1
. Aktualisieren Sie diese auf 2.0.0
und aktualisieren Sie dann die in Ihrem Projekt installierten Module.
Nachdem Sie Ihre Abhängigkeiten aktualisiert haben, geben Sie ein, npm update -g aws-cdk
um das CDK Toolkit auf die Release-Version zu aktualisieren.
Migrieren von AWS CDK v1 zu CDK v2
Um Ihre App zu AWS CDK v2 zu migrieren, aktualisieren Sie zunächst die Feature-Flags in cdk.json
. Aktualisieren Sie dann die Abhängigkeiten und Importe Ihrer App nach Bedarf für die Programmiersprache, in der sie geschrieben ist.
Aktualisieren auf ein aktuelles v1
Wir sehen in einem Schritt eine Reihe von Kunden, die von einer alten Version von AWS CDK v1 auf die neueste Version von v2 aktualisieren. Es ist zwar durchaus möglich, dies zu tun, aber Sie würden sowohl ein Upgrade über mehrere Jahre hinweg vornehmen (was möglicherweise nicht alle die gleiche Menge an Entwicklungstests hatten, die wir heute haben), als auch ein Upgrade auf Versionen mit neuen Standardeinstellungen und einer anderen Codeorganisation durchführen.
Um ein sicheres Upgrade zu ermöglichen und die Quellen unerwarteter Änderungen leichter zu diagnostizieren, empfehlen wir Ihnen, diese beiden Schritte zu trennen: zuerst auf die neueste Version aktualisieren und anschließend den Wechsel zu v2 durchführen.
Aktualisieren von Feature-Flags
Entfernen Sie die folgenden v1-Feature-Flags aus , cdk.json
wenn sie vorhanden sind, da diese alle standardmäßig in AWS CDK v2 aktiv sind. Wenn ihr alter Effekt für Ihre Infrastruktur wichtig ist, müssen Sie Änderungen am Quellcode vornehmen. Weitere Informationen finden Sie in der Liste der Flags auf GitHub
-
@aws-cdk/core:enableStackNameDuplicates
-
aws-cdk:enableDiffNoFail
-
@aws-cdk/aws-ecr-assets:dockerIgnoreSupport
-
@aws-cdk/aws-secretsmanager:parseOwnedSecretName
-
@aws-cdk/aws-kms:defaultKeyPolicies
-
@aws-cdk/aws-s3:grantWriteWithoutAcl
-
@aws-cdk/aws-efs:defaultEncryptionAtRest
Eine Handvoll v1-Feature-Flags können auf gesetzt werden, false
um zu bestimmten AWS CDK v1-Verhaltensweisen zurückzukehren. Eine vollständige Referenz finden Sie unter Zurücksetzen auf das Verhalten v1 oder in der Liste GitHub auf .
Verwenden Sie für beide Arten von Flags den cdk diff
Befehl , um die Änderungen an Ihrer synthetisierten Vorlage zu überprüfen, um festzustellen, ob sich die Änderungen an einem dieser Flags auf Ihre Infrastruktur auswirken.
Kompatibilität mit CDK Toolkit
CDK v2 erfordert v2 oder höher des CDK Toolkits. Diese Version ist abwärtskompatibel mit CDK-v1-Apps. Daher können Sie eine einzelne global installierte Version des CDK Toolkits mit all Ihren AWS CDK Projekten verwenden, unabhängig davon, ob sie v1 oder v2 verwenden. Eine Ausnahme besteht darin, dass CDK Toolkit v2 nur CDK-v2-Projekte erstellt.
Wenn Sie sowohl v1- als auch v2-CDK-Projekte erstellen müssen, installieren Sie CDK Toolkit v2 nicht global. (Entfernen Sie es, wenn Sie es bereits installiert haben: npm remove -g aws-cdk
.) Um das CDK Toolkit aufzurufen, verwenden Sie , npx um v1 oder v2 des CDK Toolkits wie gewünscht auszuführen.
npx aws-cdk@1.x init app --language typescript npx aws-cdk@2.x init app --language typescript
Tipp
Richten Sie Befehlszeilen-Aliase ein, damit Sie die cdk1 Befehle cdk und verwenden können, um die gewünschte Version des CDK Toolkits aufzurufen.
Aktualisieren von Abhängigkeiten und Importen
Aktualisieren Sie die Abhängigkeiten Ihrer App und installieren Sie dann die neuen Pakete. Aktualisieren Sie abschließend die Importe in Ihrem Code.
Testen Ihrer migrierten App vor der Bereitstellung
Bevor Sie Ihre Stacks bereitstellen, verwenden Sie , cdk diff
um nach unerwarteten Änderungen an den Ressourcen zu suchen. Änderungen an logischen IDs (wodurch Ressourcen ersetzt werden) werden nicht erwartet.
Zu den erwarteten Änderungen gehören unter anderem:
-
Änderungen an der
CDKMetadata
Ressource. -
Aktualisierte Komponenten-Hashes.
-
Änderungen im Zusammenhang mit der Stack-Synthetik im neuen Stil. Gilt, wenn Ihre App den Legacy-Stack-Syntheizer in v1 verwendet hat. (CDK v2 unterstützt den Legacy-Stack-Syntheizer nicht.)
-
Das Hinzufügen einer
CheckBootstrapVersion
Regel.
Unerwartete Änderungen werden in der Regel nicht durch ein Upgrade auf AWS CDK v2 selbst verursacht. In der Regel sind sie das Ergebnis veralteten Verhaltens, das zuvor durch Feature-Flags geändert wurde. Dies ist ein Problem des Upgrades von einer Version von CDK vor etwa 1.85.x. Sie würden dieselben Änderungen sehen, die auf die neueste Version v1.x aktualisiert wurden. Sie können dies normalerweise wie folgt lösen:
-
Aktualisieren Sie Ihre App auf die neueste Version v1.x
-
Entfernen von Feature-Flags
-
Überarbeiten Sie Ihren Code nach Bedarf
-
Bereitstellen
-
Upgrade auf v2
Anmerkung
Wenn Ihre aktualisierte App nach dem zweistufigen Upgrade nicht bereitgestellt werden kann, melden Sie das Problem
Wenn Sie bereit sind, die Stacks in Ihrer App bereitzustellen, sollten Sie zuerst eine Kopie bereitstellen, damit Sie sie testen können. Der einfachste Weg, dies zu tun, besteht darin, es in einer anderen Region bereitzustellen. Sie können jedoch auch die IDs Ihrer Stacks ändern. Stellen Sie nach dem Testen sicher, dass Sie die Testkopie mit löschencdk destroy.
Fehlerbehebung
TypeScript 'from' expected
- oder -';' expected
Fehler bei Importen
Aktualisieren Sie auf TypeScript 3.8 oder höher.
Ausführen von „cdk bootstrap“
Wenn Sie einen Fehler wie den folgenden sehen:
❌ MyStack failed: Error: MyStack: SSM parameter /cdk-bootstrap/hnb659fds/version not found. Has the environment been bootstrapped? Please run 'cdk bootstrap' (see https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html) at CloudFormationDeployments.validateBootstrapStackVersion (.../aws-cdk/lib/api/cloudformation-deployments.ts:323:13) at processTicksAndRejections (internal/process/task_queues.js:97:5) MyStack: SSM parameter /cdk-bootstrap/hnb659fds/version not found. Has the environment been bootstrapped? Please run 'cdk bootstrap' (see https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html)
AWS CDK v2 erfordert einen aktualisierten Bootstrap-Stack, und außerdem benötigen alle v2-Bereitstellungen Bootstrap-Ressourcen. (Mit v1 können Sie einfache Stacks ohne Bootstrapping bereitstellen.) Vollständige Details finden Sie unter Bootstrapping.
Suchen von v1-Stacks
Bei der Migration Ihrer CDK-Anwendung von v1 zu v2 möchten Sie möglicherweise die bereitgestellten AWS CloudFormation Stacks identifizieren, die mit v1 erstellt wurden. Führen Sie dazu den folgenden Befehl aus:
npx awscdk-v1-stack-finder
Einzelheiten zur Verwendung finden Sie unter awscdk-v1-stack- README