これは AWS CDK v2 デベロッパーガイドです。古い CDKv1 は 2022 年 6 月 1 日にメンテナンスを開始し、2023 年 6 月 1 日にサポートを終了しました。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS CDK v1 から AWS CDK v2 への移行
のバージョン 2 AWS Cloud Development Kit (AWS CDK) は、任意のプログラミング言語でインフラストラクチャをコードとして簡単に記述できるように設計されています。このトピックでは、 の v1 と v2 の間の変更について説明します AWS CDK。
ヒント
AWS CDK v1 でデプロイされたスタックを特定するには、awscdk-v1-stack-finder
AWS CDK v1 から v2 CDK への主な変更点は次のとおりです。
-
AWS CDK v2 は、コアライブラリを含む AWS コンストラクトライブラリの安定した部分を 1 つのパッケージ に統合します
aws-cdk-lib
。デベロッパーは、使用する個々の AWS サービスに追加のパッケージをインストールする必要はありません。この単一パッケージアプローチは、さまざまなCDKライブラリパッケージのバージョンを同期する必要もないことも意味します。で利用可能な正確なリソースを表す L1 (Cfn XXXX) コンストラクトは AWS CloudFormation、常に安定していると見なされ、 に含まれます
aws-cdk-lib
。 -
コミュニティと協力して新しい L2 または L3 コンストラクト を開発している実験モジュールは、 には含まれていません
aws-cdk-lib
。代わりに、個々のパッケージとして配布されます。実験パッケージの名前にはalpha
、サフィックスとセマンティックバージョン番号が付きます。セマンティックバージョン番号は、互換性がある AWS コンストラクトライブラリの最初のバージョンと一致し、alpha
サフィックスが付いています。コンストラクトは安定して指定されたaws-cdk-lib
後、 に移動し、メインコンストラクトライブラリが厳密なセマンティックバージョニングに従うことを許可します。安定性はサービスレベルで指定されます。例えば、この書き込みで L1 コンストラクトのみを持つ Amazon の 1 つ以上の L2 コンストラクトの作成を開始すると、それらはまず という名前のモジュールに表示されます
@aws-cdk/aws-appflow-alpha
。 AppFlow L1 次に、新しいコンストラクトaws-cdk-lib
が顧客の基本的なニーズを満たすと、 に移行します。モジュールが安定していると指定され、 に組み込まれると
aws-cdk-lib
、次の箇条書きで説明するBetaN」規則を使用して新しい APIsが追加されます。各実験モジュールの新しいバージョンは、 のリリースごとにリリースされます AWS CDK。ただし、ほとんどの場合、同期しておく必要はありません。
aws-cdk-lib
または実験的なモジュールは、いつでもアップグレードできます。ただし、2 つ以上の関連する実験モジュールが相互に依存している場合、それらは同じバージョンである必要があります。 -
新機能が追加されている安定したモジュールの場合、新しい APIs (完全に新しいコンストラクトでも、既存のコンストラクトの新しいメソッドやプロパティでも)
Beta1
作業の進行中にサフィックスを受け取ります。(重大な変更が必要な場合Beta3
、、Beta2
などに続きます。) が安定しているとAPI指定されると、サフィックスAPIのない のバージョンが追加されます。その後、最新の (ベータ版か最終版かにかかわらず) を除くすべてのメソッドが廃止されます。例えば、コンストラクト
grantPower()
に新しいメソッドを追加すると、最初は と表示されますgrantPowerBeta1()
。重大な変更が必要な場合 (新しい必須パラメータやプロパティなど)grantPowerBeta2()
、メソッドの次のバージョンには という名前が付けられます。作業が完了し、 APIが確定されると、 メソッドgrantPower()
(サフィックスなし) が追加され、BetaN メソッドは廃止されます。すべてのベータ版は、次のメジャーバージョン (3.0) リリースまで コンストラクトライブラリにAPIs残り、署名は変更されません。非推奨の警告が表示されるので、APIできるだけ早く の最終バージョンに移動する必要があります。ただし、今後の AWS CDK 2.x リリースではアプリケーションが破損することはありません。
-
Construct
クラスは、関連するタイプとともに、 から別のライブラリ AWS CDK に抽出されています。これは、コンストラクトプログラミングモデルを他のドメインに適用する取り組みをサポートするために行われます。独自のコンストラクトを記述する場合、または関連する を使用する場合はAPIs、constructs
モジュールを依存関係として宣言し、インポートにわずかな変更を加える必要があります。CDK アプリケーションのライフサイクルへのフックなど、高度な機能を使用している場合は、さらに変更が必要になる場合があります。詳細については、「」を参照してくださいRFC。 -
AWS CDK v1.x とそのコンストラクトライブラリの非推奨のプロパティ、メソッド、タイプは v2 CDK から完全に削除されましたAPI。サポートされているほとんどの言語では、v1.x で警告APIsが表示されるため、代替 に既に移行している可能性がありますAPIs。v1.x で廃止された の完全なリストAPIs
は、 で入手できます GitHub。 CDK -
AWS CDK v1.x の機能フラグによってゲートされた動作は、v2 CDK ではデフォルトで有効になっています。以前の機能フラグは不要になり、ほとんどの場合、サポートされません。非常に特定の状況でも v1 CDK の動作に戻すことができるものもあります。詳細については、「機能フラグの更新」を参照してください。
-
CDK v2 では、デプロイ先の環境を最新のブートストラップスタックを使用してブートストラップする必要があります。レガシーブートストラップスタック (v1 のデフォルト) はサポートされなくなりました。CDK v2 では、最新のスタックの新しいバージョンがさらに必要になります。既存の環境をアップグレードするには、それらをリブートストラップします。最新のブートストラップスタックを使用するために、機能フラグや環境変数を設定する必要がなくなりました。
重要
最新のブートストラップテンプレートは、 が暗示するアクセス許可--cloudformation-execution-policies
を--trust
リスト内の任意の AWS アカウントに効果的に付与します。デフォルトでは、これにより、ブートストラップされたアカウントの任意のリソースに対する読み取りと書き込みのアクセス許可が拡張されます。ブートストラップスタックには、使い慣れたポリシーと信頼できるアカウントを設定してください。
新しい前提条件
AWS CDK v2 の要件のほとんどは AWS CDK v1.x の要件と同じです。その他の要件を以下に示します。
-
TypeScript デベロッパーの場合は、 TypeScript 3.8 以降が必要です。
-
v2 で使用するには、新しいバージョンの CDK Toolkit CDK が必要です。v2 CDK が一般公開されたので、 ツールキットのインストール時のデフォルトバージョンは v2 CDK です。CDK v1 プロジェクトとの下位互換性があるため、v1 CDK プロジェクトを作成しない限り、以前のバージョンをインストールしたままにする必要はありません。アップグレードするには、 を発行します
npm install -g aws-cdk
。
AWS CDK v2 デベロッパープレビューからのアップグレード
CDK v2 デベロッパープレビューを使用している場合、プロジェクトには AWS CDK、 などのリリース候補バージョンの への依存関係があります2.0.0-rc1
。これらを に更新し2.0.0
、プロジェクトにインストールされているモジュールを更新します。
依存関係を更新したら、 を発行npm update -g aws-cdk
して CDK Toolkit をリリースバージョンに更新します。
AWS CDK v1 から v2 CDK への移行
アプリケーションを AWS CDK v2 に移行するには、まず の機能フラグを更新しますcdk.json
。次に、アプリケーションの依存関係を更新し、記述されているプログラミング言語の必要に応じてインポートします。
最近の v1 への更新
古いバージョンの AWS CDK v1 から最新バージョンの v2 に 1 ステップでアップグレードしているお客様が多数います。そうすることは間違いありませんが、数年にわたる変更 (残念ながら、すべてに現在実施されている進化テストの量が同じではない可能性があります) をアップグレードするだけでなく、新しいデフォルトと別のコード組織でバージョンをまたいでアップグレードすることになります。
最も安全なアップグレードエクスペリエンスを実現し、予期しない変更の原因をより簡単に診断するには、次の 2 つのステップを分離することをお勧めします。まず最新の v1 バージョンにアップグレードしてから、後で v2 に切り替えることです。
機能フラグの更新
次の v1 機能フラグが存在するcdk.json
場合は、 から削除します。これらはすべて AWS CDK v2 でデフォルトでアクティブになっているためです。インフラストラクチャにとって古い影響が重要な場合は、ソースコードを変更する必要があります。詳細については、 のフラグのリストを参照してください 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
特定の v1 動作に戻すfalse
ために、数個の AWS CDK v1 機能フラグを に設定することができます。完全なリファレンスについては、v1 の動作に戻す「」または GitHub 「」のリストを参照してください。
どちらのタイプのフラグでも、 cdk diff
コマンドを使用して合成されたテンプレートの変更を検査し、これらのフラグのいずれかの変更がインフラストラクチャに影響するかどうかを確認します。
CDK ツールキットの互換性
CDK v2 には、 CDKツールキットの v2 以降が必要です。このバージョンは v1 CDK アプリケーションと下位互換性があります。したがって、グローバルにインストールされた 1 つのバージョンの CDK Toolkit を、v1 と v2 のどちらを使用するかにかかわらず、すべての AWS CDK プロジェクトで使用できます。例外として、CDKToolkit v2 は v2 CDK プロジェクトのみを作成します。
v1 プロジェクトと v2 CDKプロジェクトの両方を作成する必要がある場合は、CDKToolkit v2 をグローバルにインストールしないでください。(既にインストールされている場合は削除します: )npm remove -g aws-cdk
。Toolkit を呼び出すにはCDK、 npxを使用して、必要に応じて CDK Toolkit の v1 または v2 を実行します。
npx aws-cdk@1.x init app --language typescript npx aws-cdk@2.x init app --language typescript
ヒント
コマンドラインエイリアスを設定して、 cdkおよび cdk1 コマンドを使用して目的のバージョンの CDK Toolkit を呼び出すことができます。
依存関係とインポートの更新
アプリケーションの依存関係を更新し、新しいパッケージをインストールします。最後に、コードのインポートを更新します。
デプロイ前に移行したアプリケーションをテストする
スタックをデプロイする前に、 cdk diff
を使用してリソースに予期しない変更がないか確認します。論理IDs的 (リソースの置き換えの原因となる) への変更は想定されません。
予想される変更には以下が含まれますが、これらに限定されません。
-
CDKMetadata
リソースの変更。 -
アセットハッシュを更新しました。
-
新しいスタイルのスタック合成に関連する変更。アプリケーションが v1 でレガシースタックシンセサイザーを使用した場合に適用されます。(CDK v2 はレガシースタックシンセサイザーをサポートしていません)。
-
CheckBootstrapVersion
ルールの追加。
予期しない変更は、通常、 AWS CDK v2 自体へのアップグレードによって引き起こされることはありません。通常、これらは機能フラグによって以前に変更された非推奨の動作の結果です。これは、約 1.85.x よりCDK前のバージョンの からアップグレードする兆候です。同じ変更が最新の v1.x リリースにアップグレードされます。通常、これを解決するには、以下を実行します。
-
アプリケーションを最新の v1.x リリースにアップグレードする
-
機能フラグを削除する
-
必要に応じてコードを修正する
-
デプロイ
-
v2 へのアップグレード
注記
2 段階アップグレード後にアップグレードしたアプリがデプロイできない場合は、問題を報告し
アプリケーションにスタックをデプロイする準備ができたら、最初にコピーをデプロイしてテストできるようにすることを検討してください。これを行う最も簡単な方法は、別のリージョンにデプロイすることです。ただし、スタックIDsの を変更することもできます。テスト後、テストコピーは必ず で破棄してくださいcdk destroy。
トラブルシューティング
TypeScript 'from' expected
インポートの または ';' expected
エラー
を TypeScript 3.8 以降にアップグレードします。
「cdk ブートストラップ」を実行する
次のようなエラーが表示される場合:
❌ 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 には更新されたブートストラップスタックが必要であり、さらにすべての v2 デプロイにはブートストラップリソースが必要です。(v1 では、ブートストラップなしでシンプルなスタックをデプロイできます。) 詳細については、「AWS CDK ブートストラップ」を参照してください。
v1 スタックの検索
CDK アプリケーションを v1 から v2 に移行するときは、v1 を使用して作成されたデプロイされた AWS CloudFormation スタックを特定できます。これを行うには、次のコマンドを実行します。
npx awscdk-v1-stack-finder
使用の詳細については、awscdk-v1-stack-finder を参照してくださいREADME