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