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. # Migration von AWS CDK v1 zu AWS CDK v2 Version 2 des AWS Cloud Development Kit (AWS CDK) wurde entwickelt, um das Schreiben von Infrastruktur als Code in Ihrer bevorzugten Programmiersprache zu vereinfachen. In diesem Thema werden die Änderungen zwischen Version 1 und Version 2 des AWS CDK beschrieben. **Tipp** [Verwenden Sie das Hilfsprogramm awscdk-v1-stack-finder, um Stacks zu identifizieren, die mit AWS CDK v1 bereitgestellt wurden.](https://www.npmjs.com/package/awscdk-v1-stack-finder) Die wichtigsten Änderungen von CDK v1 zu CDK v2 sind wie folgt. AWS + AWS CDK v2 konsolidiert die stabilen Teile der AWS Construct Library, einschließlich der Kernbibliothek, in einem einzigen Paket. `aws-cdk-lib` Entwickler müssen keine zusätzlichen Pakete mehr für die einzelnen AWS Dienste installieren, die sie verwenden. Dieser Einzelpaket-Ansatz bedeutet auch, dass Sie die Versionen der verschiedenen CDK-Bibliothekspakete nicht synchronisieren müssen. L1-Konstrukte (CFNxxxx), die genau die verfügbaren Ressourcen in darstellen, gelten immer als stabil AWS CloudFormation und sind daher in enthalten. `aws-cdk-lib` + Experimentelle Module, in denen wir immer noch mit der Community zusammenarbeiten, um neue [L2- oder L3-Konstrukte](constructs.md#constructs-lib-levels) zu entwickeln, sind darin nicht enthalten. `aws-cdk-lib` Stattdessen werden sie als einzelne Pakete verteilt. Experimentelle Pakete werden mit einem `alpha` Suffix und einer semantischen Versionsnummer benannt. Die semantische Versionsnummer entspricht der ersten Version der AWS Construct Library, mit der sie kompatibel sind, ebenfalls mit einem Suffix. `alpha` Konstrukte werden in den Ordner verschoben, `aws-cdk-lib` nachdem sie als stabil eingestuft wurden, sodass sich die Haupt-Construct-Bibliothek an die strikte semantische Versionierung halten kann. Die Stabilität wird auf der Serviceebene spezifiziert. Wenn wir beispielsweise damit beginnen, ein oder mehrere [L2-Konstrukte](constructs.md#constructs-lib-levels) für Amazon zu erstellen AppFlow, die zum jetzigen Zeitpunkt nur L1-Konstrukte haben, erscheinen sie zuerst in einem Modul mit dem Namen. `@aws-cdk/aws-appflow-alpha` Dann gehen sie zu dem `aws-cdk-lib` Zeitpunkt über, zu dem wir der Meinung sind, dass die neuen Konstrukte den grundlegenden Bedürfnissen der Kunden entsprechen. Sobald ein Modul als stabil eingestuft und integriert wurde, APIs werden neue hinzugefügt`aws-cdk-lib`, wobei die im nächsten Punkt beschriebene „betAN“ -Konvention verwendet bullet. Eine neue Version jedes experimentellen Moduls wird mit jeder Veröffentlichung des AWS CDK veröffentlicht. In den meisten Fällen müssen sie jedoch nicht synchron gehalten werden. Sie können das experimentelle Modul jederzeit aktualisieren`aws-cdk-lib`. Die Ausnahme ist, dass, wenn zwei oder mehr verwandte experimentelle Module voneinander abhängen, sie dieselbe Version haben müssen. + Bei stabilen Modulen, denen neue Funktionen hinzugefügt werden, erhalten neue Module APIs (unabhängig davon, ob es sich um völlig neue Konstrukte oder neue Methoden oder Eigenschaften eines bestehenden Konstrukts handelt) während der Bearbeitung ein `Beta1` Suffix. (Gefolgt von `Beta2``Beta3`, usw., 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 der neuesten (ob Beta oder Final) sind dann veraltet. Wenn wir beispielsweise einem Konstrukt eine neue Methode `grantPower()` hinzufügen, erscheint sie zunächst als. `grantPowerBeta1()` Wenn grundlegende Änderungen erforderlich sind (z. B. ein neuer erforderlicher Parameter oder eine neue Eigenschaft), wird die nächste Version der Methode benannt `grantPowerBeta2()` usw. Wenn die Arbeit abgeschlossen und die API fertiggestellt ist, wird die Methode `grantPower()` (ohne Suffix) hinzugefügt, und die BetAN-Methoden sind veraltet. Alle Betaversionen APIs bleiben bis zur nächsten Hauptversion (3.0) in der Construct-Bibliothek, und ihre Signaturen werden sich nicht ändern. Wenn Sie sie verwenden, werden Warnmeldungen zu veralteten Versionen angezeigt. Sie sollten daher so bald wie möglich zur endgültigen Version der API wechseln. Allerdings werden future AWS CDK 2.x-Versionen Ihre Anwendung nicht beschädigen. + Die `Construct` Klasse wurde zusammen mit verwandten Typen aus dem AWS CDK in eine separate Bibliothek extrahiert. Dies geschieht, um die Bemühungen zu unterstützen, das Construct-Programmiermodell auf andere Bereiche anzuwenden. Wenn Sie Ihre eigenen Konstrukte schreiben oder verwandte Konstrukte verwenden APIs, müssen Sie das `constructs` Modul als Abhängigkeit deklarieren und geringfügige Änderungen an Ihren Importen vornehmen. Wenn Sie erweiterte Funktionen verwenden, z. B. die Einbindung in den CDK-App-Lebenszyklus, sind möglicherweise weitere Änderungen erforderlich. Vollständige Informationen finden [Sie](https://github.com/aws/aws-cdk-rfcs/blob/master/text/0192-remove-constructs-compat.md#release-notes) im RFC. + Veraltete Eigenschaften, Methoden und Typen in AWS CDK v1.x und seiner Construct-Bibliothek wurden vollständig aus der CDK v2-API entfernt. In den meisten unterstützten Sprachen APIs erzeugen diese unter v1.x Warnungen, sodass Sie möglicherweise bereits auf die Ersatzversion migriert sind. APIs Eine vollständige [Liste der APIs in CDK v1.x veralteten Versionen](https://github.com/aws/aws-cdk/blob/master/DEPRECATED_APIs.md) finden Sie unter. GitHub + Verhalten, das in AWS CDK v1.x durch Feature-Flags eingeschränkt 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, mit denen Sie unter ganz bestimmten Umständen zum Verhalten von CDK v1 zurückkehren können. Weitere Informationen finden Sie unter [Feature-Flags aktualisieren](#migrating-v2-v1-upgrade-cdk-json). + Bei CDK v2 müssen die Umgebungen, in denen Sie die Bereitstellung durchführen, mithilfe des modernen Bootstrap-Stacks gebootet werden. Der ältere Bootstrap-Stack (der Standard unter Version 1) wird nicht mehr unterstützt. CDK v2 benötigt außerdem eine neue Version des modernen Stacks. Um Ihre bestehenden 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 jedem AWS Konto in der Liste die `--cloudformation-execution-policies` damit verbundenen Berechtigungen. `--trust` Standardmäßig werden dadurch die Lese- und Schreibberechtigungen für alle Ressourcen im Bootstrap-Konto erweitert. Stellen Sie sicher, dass [Sie den Bootstrapping-Stack mit Richtlinien und vertrauenswürdigen Konten konfigurieren](bootstrapping-customizing.md), 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 Version 3.8 oder höher erforderlich. + Für die Verwendung mit CDK v2 ist eine neue Version des CDK Toolkits erforderlich. Da CDK v2 nun 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 nicht installiert lassen müssen, es sei denn, Sie möchten CDK v1-Projekte erstellen. Um ein Upgrade durchzuführen, geben Sie es ein. `npm install -g aws-cdk` ## Aktualisierung von AWS CDK v2 Developer Preview Wenn Sie die CDK v2 Developer Preview verwenden, besteht 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. **Example** `npm install` oder `yarn install` `npm install` oder `yarn install` ``` python -m pip install -r requirements.txt ``` ``` mvn package ``` ``` dotnet restore ``` ``` go get ``` Nachdem Sie Ihre Abhängigkeiten aktualisiert haben, geben Sie `npm update -g aws-cdk` an, das CDK Toolkit auf die Release-Version zu aktualisieren. ## Migration von AWS CDK v1 zu CDK v2 Um Ihre App auf 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 wurde. ### Aktualisierung auf eine aktuelle Version 1 Wir beobachten, dass eine Reihe von Kunden in einem Schritt von einer alten Version von AWS CDK v1 auf die neueste Version von v2 umsteigen. Das ist sicherlich möglich, aber Sie würden sowohl ein Upgrade über mehrere Jahre an Änderungen durchführen (die leider nicht alle denselben Umfang an Entwicklungstests hatten wie heute) als auch ein Upgrade auf mehrere Versionen mit neuen Standardeinstellungen und einer anderen Code-Organisation durchführen würden. Für das sicherste Upgrade-Erlebnis und um die Ursachen unerwarteter Änderungen einfacher zu diagnostizieren, empfehlen wir, diese beiden Schritte voneinander zu trennen: zuerst auf die neueste Version v1 aktualisieren und anschließend auf v2 umsteigen. ### Feature-Flags werden aktualisiert Entfernen Sie die folgenden v1-Feature-Flags, `cdk.json` falls sie existieren, da diese in AWS CDK v2 standardmäßig alle 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 Flaggen auf GitHub](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/cx-api/FEATURE_FLAGS.md). + `@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 `false` gesetzt werden, um zu bestimmten AWS CDK v1-Verhaltensweisen [zurückzukehren. Eine vollständige Referenz finden Sie unter Zurück zum v1-Verhalten](featureflags.md#featureflags-disabling) oder in der Liste unter GitHub . Verwenden Sie für beide Arten von Flags den `cdk diff` Befehl, um die Änderungen an Ihrer synthetisierten Vorlage zu überprüfen und festzustellen, ob sich die Änderungen an einem dieser Flags auf Ihre Infrastruktur auswirken. ### Kompatibilität mit dem CDK Toolkit CDK v2 erfordert Version 2 oder höher des CDK Toolkits. Diese Version ist abwärtskompatibel mit CDK v1-Apps. Daher können Sie eine einzige global installierte Version von CDK Toolkit für all Ihre AWS CDK-Projekte verwenden, unabhängig davon, ob sie v1 oder v2 verwenden. Eine Ausnahme ist, 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**. (Entferne es, falls du es bereits installiert hast:.) `npm remove -g aws-cdk` Um das CDK-Toolkit aufzurufen, verwenden Sie, `npx` um Version 1 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, sodass Sie die `cdk1` Befehle `cdk` und verwenden können, um die gewünschte Version des CDK Toolkits aufzurufen. ``` alias cdk1="npx aws-cdk@1.x" alias cdk="npx aws-cdk@2.x" ``` ``` doskey cdk1=npx aws-cdk@1.x $* doskey cdk=npx aws-cdk@2.x $* ``` ### Abhängigkeiten und Importe aktualisieren Aktualisieren Sie die Abhängigkeiten Ihrer App und installieren Sie dann die neuen Pakete. Aktualisieren Sie abschließend die Importe in Ihrem Code. **Example** **Anwendungen** Aktualisieren Sie CDK-Apps `package.json` wie folgt. Entfernen Sie Abhängigkeiten von einzelnen stabilen Modulen im v1-Stil und richten Sie die niedrigste Version ein, die `aws-cdk-lib` Sie für Ihre Anwendung benötigen (2.0.0 hier). Experimentelle Konstrukte werden in separaten, unabhängig versionierten Paketen bereitgestellt, deren Namen auf `alpha` und einer Alpha-Versionsnummer enden. Die Alpha-Versionsnummer entspricht der ersten Version, `aws-cdk-lib` mit der sie kompatibel sind. Hier haben wir an v2.0.0-alpha.1 `aws-codestar` gepinnt. ``` { "dependencies": { "aws-cdk-lib": "^2.0.0", "@aws-cdk/aws-codestar-alpha": "2.0.0-alpha.1", "constructs": "^10.0.0" } } ``` **Konstruieren Sie Bibliotheken** Stellen Sie für Construct-Bibliotheken die niedrigste Version fest, die `aws-cdk-lib` Sie für Ihre Anwendung benötigen (2.0.0 hier), und aktualisieren Sie `package.json` sie wie folgt. Beachten Sie, dass dies sowohl als Peer-Abhängigkeit als auch als Dev-Abhängigkeit `aws-cdk-lib` angezeigt wird. ``` { "peerDependencies": { "aws-cdk-lib": "^2.0.0", "constructs": "^10.0.0" }, "devDependencies": { "aws-cdk-lib": "^2.0.0", "constructs": "^10.0.0", "typescript": "~3.9.0" } } ``` Sie sollten bei der Veröffentlichung einer v2-kompatiblen Bibliothek eine größere Versionserhöhung an der Versionsnummer Ihrer Bibliothek vornehmen, da dies eine bahnbrechende Änderung für Bibliotheksnutzer ist. Es ist nicht möglich, sowohl CDK v1 als auch CDK v2 mit einer einzigen Bibliothek zu unterstützen. Um Kunden, die immer noch Version 1 verwenden, weiterhin zu unterstützen, könnten Sie die frühere Version parallel verwalten oder ein neues Paket für Version 2 erstellen. Es liegt an Ihnen, wie lange Sie AWS CDK v1-Kunden weiterhin unterstützen möchten. Sie könnten sich am Lebenszyklus von CDK v1 selbst orientieren, das am 1. Juni 2022 in die Wartung aufgenommen wurde und end-of-life am 1. Juni 2023 enden wird. Vollständige Informationen finden Sie in der [AWS CDK-Wartungsrichtlinie](https://github.com/aws/aws-cdk-rfcs/blob/master/text/0079-cdk-2.0.md#aws-cdk-maintenance-policy). **Sowohl Bibliotheken als auch Apps** Installieren Sie die neuen Abhängigkeiten, indem Sie `npm install` oder ausführen`yarn install`. Ändern Sie Ihre Importe so, dass sie `Construct` aus dem neuen `constructs` Modul, Kerntypen wie `App` und `Stack` aus der obersten Ebene von und stabilen Construct-Library-Modulen für die Dienste`aws-cdk-lib`, die Sie aus den Namespaces unter verwenden, importieren. `aws-cdk-lib` ``` import { Construct } from 'constructs'; import { App, Stack } from 'aws-cdk-lib'; // core constructs import { aws_s3 as s3 } from 'aws-cdk-lib'; // stable module import * as codestar from '@aws-cdk/aws-codestar-alpha'; // experimental module ``` Aktualisieren Sie `package.json` wie folgt. Entfernen Sie Abhängigkeiten von einzelnen stabilen Modulen im v1-Stil und richten Sie die niedrigste Version ein, die `aws-cdk-lib` Sie für Ihre Anwendung benötigen (2.0.0 hier). Experimentelle Konstrukte werden in separaten, unabhängig versionierten Paketen bereitgestellt, deren Namen auf `alpha` und einer Alpha-Versionsnummer enden. Die Alpha-Versionsnummer entspricht der ersten Version, `aws-cdk-lib` mit der sie kompatibel sind. Hier haben wir an v2.0.0-alpha.1 `aws-codestar` gepinnt. ``` { "dependencies": { "aws-cdk-lib": "^2.0.0", "@aws-cdk/aws-codestar-alpha": "2.0.0-alpha.1", "constructs": "^10.0.0" } } ``` Installieren Sie die neuen Abhängigkeiten, indem Sie oder ausführen. `npm install` `yarn install` Ändern Sie die Importe Ihrer App wie folgt: + `Construct`Aus dem neuen `constructs` Modul importieren + Importieren Sie Kerntypen wie `App` und `Stack` von der obersten Ebene von `aws-cdk-lib` + Importieren Sie AWS Construct Library-Module aus Namespaces unter `aws-cdk-lib` ``` const { Construct } = require('constructs'); const { App, Stack } = require('aws-cdk-lib'); // core constructs const s3 = require('aws-cdk-lib').aws_s3; // stable module const codestar = require('@aws-cdk/aws-codestar-alpha'); // experimental module ``` Aktualisieren Sie `requirements.txt` die `install_requires` Definition wie folgt. `setup.py` Entfernen Sie Abhängigkeiten von einzelnen stabilen Modulen im v1-Stil. Experimentelle Konstrukte werden in separaten, unabhängig versionierten Paketen bereitgestellt, deren Namen auf `alpha` und einer Alpha-Versionsnummer enden. Die Alpha-Versionsnummer entspricht der ersten Version, `aws-cdk-lib` mit der sie kompatibel sind. Hier haben wir an v2.0.0alpha1 `aws-codestar` gepinnt. ``` install_requires=[ "aws-cdk-lib>=2.0.0", "constructs>=10.0.0", "aws-cdk.aws-codestar-alpha>=2.0.0alpha1", # ... ], ``` Deinstallieren Sie alle anderen Versionen von AWS CDK-Modulen, die bereits in der virtuellen Umgebung Ihrer App installiert sind, mit. `pip uninstall` Installieren Sie dann die neuen Abhängigkeiten mit`python -m pip install -r requirements.txt`. Ändern Sie die Importe Ihrer App wie folgt: + `Construct`Aus dem neuen `constructs` Modul importieren + Importieren Sie Kerntypen wie `App` und `Stack` von der obersten Ebene von `aws_cdk` + Importieren Sie AWS Construct Library-Module aus Namespaces unter `aws_cdk` ``` from constructs import Construct from aws_cdk import App, Stack # core constructs from aws_cdk import aws_s3 as s3 # stable module import aws_cdk.aws_codestar_alpha as codestar # experimental module # ... class MyConstruct(Construct): # ... class MyStack(Stack): # ... s3.Bucket(...) ``` Entfernen Sie unter alle `software.amazon.awscdk` Abhängigkeiten für stabile Module und ersetzen Sie sie durch Abhängigkeiten von `software.constructs` (für`Construct`) und. `pom.xml` `software.amazon.awscdk` Experimentelle Konstrukte werden in separaten, unabhängig versionierten Paketen bereitgestellt, deren Namen auf `alpha` und einer Alpha-Versionsnummer enden. Die Alpha-Versionsnummer entspricht der ersten Version, `aws-cdk-lib` mit der sie kompatibel sind. Hier haben wir an v2.0.0-alpha.1 `aws-codestar` gepinnt. ``` software.amazon.awscdk aws-cdk-lib 2.0.0 software.amazon.awscdk code-star-alpha 2.0.0-alpha.1 software.constructs constructs 10.0.0 ``` Installieren Sie die neuen Abhängigkeiten, indem Sie Folgendes ausführen. `mvn package` Ändern Sie Ihren Code so, dass er wie folgt funktioniert: + `Construct`Aus der neuen `software.constructs` Bibliothek importieren + Importiert Kernklassen wie `Stack` `App` und aus `software.amazon.awscdk` + Importieren Sie Dienstkonstrukte von `software.amazon.awscdk.services` ``` import software.constructs.Construct; import software.amazon.awscdk.Stack; import software.amazon.awscdk.StackProps; import software.amazon.awscdk.App; import software.amazon.awscdk.services.s3.Bucket; import software.amazon.awscdk.services.codestar.alpha.GitHubRepository; ``` Die einfachste Methode, die Abhängigkeiten einer C\$1-CDK-Anwendung zu aktualisieren, besteht darin, die `.csproj` Datei manuell zu bearbeiten. Entfernen Sie alle stabilen `Amazon.CDK.*` Paketverweise und ersetzen Sie sie durch Verweise auf die Pakete `Amazon.CDK.Lib` und`Constructs`. Experimentelle Konstrukte werden in separaten, unabhängig versionierten Paketen bereitgestellt, deren Namen auf `alpha` und einer Alpha-Versionsnummer enden. Die Alpha-Versionsnummer entspricht der ersten Version, `aws-cdk-lib` mit der sie kompatibel sind. Hier haben wir an v2.0.0-alpha.1 `aws-codestar` gepinnt. ``` ``` Installieren Sie die neuen Abhängigkeiten, indem Sie Folgendes ausführen. `dotnet restore` Ändern Sie die Importe in Ihren Quelldateien wie folgt. ``` using Constructs; // for Construct class using Amazon.CDK; // for core classes like App and Stack using Amazon.CDK.AWS.S3; // for stable constructs like Bucket using Amazon.CDK.Codestar.Alpha; // for experimental constructs ``` Problem`go get`, um Ihre Abhängigkeiten auf die neueste Version zu aktualisieren und die `.mod` Datei Ihres Projekts zu aktualisieren. ## Testen Sie Ihre migrierte App vor der Bereitstellung Verwenden Sie diese Option, um vor der Bereitstellung Ihrer Stacks `cdk diff` nach unerwarteten Änderungen an den Ressourcen zu suchen. Logische Änderungen IDs (die zum Austausch von Ressourcen führen) sind **nicht** zu erwarten. Zu den erwarteten Änderungen gehören unter anderem: + Änderungen an der `CDKMetadata` Ressource. + Asset-Hashes wurden aktualisiert. + Änderungen im Zusammenhang mit der Stack-Synthese im neuen Stil. Gilt, wenn Ihre App den alten Stack-Synthesizer in Version 1 verwendet hat. + Das Hinzufügen einer `CheckBootstrapVersion` Regel. Unerwartete Änderungen werden in der Regel nicht durch das Upgrade auf AWS CDK v2 an sich verursacht. In der Regel sind sie das Ergebnis eines veralteten Verhaltens, das zuvor durch Feature-Flags geändert wurde. Dies ist ein Symptom für ein Upgrade von einer CDK-Version vor etwa 1.85.x. Bei einem Upgrade auf die neueste Version v1.x würden Sie dieselben Änderungen feststellen. In der Regel können Sie dieses Problem wie folgt lösen: 1. Aktualisieren Sie Ihre App auf die neueste Version v1.x 1. Entfernen Sie Feature-Flags 1. Überarbeiten Sie Ihren Code nach Bedarf 1. Bereitstellen 1. Führen Sie ein Upgrade auf v2 durch **Anmerkung** Wenn Ihre aktualisierte App nach dem zweistufigen Upgrade nicht bereitgestellt werden kann, [melden](https://github.com/aws/aws-cdk/issues/new/choose) Sie das Problem. Wenn Sie bereit sind, die Stacks in Ihrer App bereitzustellen, sollten Sie erwägen, zunächst eine Kopie bereitzustellen, 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 Anzahl Ihrer Stacks ändern. Stellen Sie nach dem Testen sicher, dass Sie die Testkopie mit `cdk destroy` vernichten. ## Fehlerbehebung **TypeScript `'from' expected`oder `';' expected` Fehler bei Importen** Führen Sie ein Upgrade auf TypeScript 3.8 oder höher durch. **Führen Sie 'cdk bootstrap' aus** 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 Version 1 könnten Sie einfache Stacks ohne Bootstrapping bereitstellen.) [Vollständige Informationen finden Sie unter CDK-Bootstrapping AWS .](bootstrapping.md) ## V1-Stacks finden Wenn Sie Ihre CDK-Anwendung von Version 1 auf Version 2 migrieren, möchten Sie möglicherweise die bereitgestellten AWS CloudFormation Stacks identifizieren, die mit Version 1 erstellt wurden. Führen Sie dazu den folgenden Befehl aus: ``` npx awscdk-v1-stack-finder ``` [Einzelheiten zur Verwendung finden Sie in der README-Datei awscdk-v1-stack-finder.](https://github.com/cdklabs/awscdk-v1-stack-finder/blob/main/README.md)