これは AWS CDK v2 デベロッパーガイドです。古い CDK v1 は 2022 年 6 月 1 日にメンテナンスを開始し、2023 年 6 月 1 日にサポートを終了しました。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS CDK アプリ
AWS Cloud Development Kit (AWS CDK) アプリケーションは、1 つ以上の CDK スタックのコレクションです。スタックは、 AWS リソースとプロパティを定義する 1 つ以上のコンストラクトのコレクションです。したがって、スタックとコンストラクトの全体的なグループ化は CDK アプリと呼ばれます。
アプリケーションの定義
プロジェクト のアプリケーションファイルでアプリケーションインスタンスを定義して、アプリケーションを作成しますAWS CDK プロジェクト。これを行うには、 App
コンストラクトライブラリから AWS コンストラクトをインポートして使用します。App
コンストラクトには初期化引数は必要ありません。ルートとして使用できるコンストラクトはこれだけです。
Construct Library の AWS App
および Stack
クラスは、一意のコンストラクトです。他のコンストラクトと比較すると、リソース AWS は単独で設定されません。代わりに、他のコンストラクトのコンテキストを提供するために使用されます。 AWS リソースを表すすべてのコンストラクトは、Stack
コンストラクトの範囲内で直接または間接的に定義する必要があります。 Stack
コンストラクトはコンストラクトの範囲内で定義されますApp
。
その後、アプリケーションが合成され、スタックの AWS CloudFormation テンプレートが作成されます。以下に例を示します。
1 つのアプリケーション内のスタックは、相互のリソースとプロパティを簡単に参照できます。は、スタック間の依存関係を AWS CDK 推測して、正しい順序でデプロイできるようにします。1 つのcdk deploy
コマンドで、アプリケーション内の一部またはすべてのスタックをデプロイできます。
コンストラクトツリー
コンストラクトは、すべてのコンストラクトに渡される scope
引数を使用して他のコンストラクトの内部で定義され、 App
クラスをルートとして使用します。このようにして、 AWS CDK アプリケーションはコンストラクトツリー と呼ばれるコンストラクトの階層を定義します。
このツリーのルートは、 App
クラスのインスタンスであるアプリです。アプリ内で、1 つ以上のスタックをインスタンス化します。スタック内では、 コンストラクトをインスタンス化します。それ自体がリソースやその他のコンストラクトをインスタンス化する場合などに、ツリーの下に置かれます。
コンストラクトは、常に別のコンストラクトの範囲内で明示的に定義され、コンストラクト間の関係を作成します。ほとんどの場合、スコープとして this
(Python では self
) を渡し、新しいコンストラクトが現在のコンストラクトの子であることを示します。意図したパターンは、 からコンストラクトを導き出しConstruct
、コンストラクターで使用するコンストラクトをインスタンス化することです。
スコープを明示的に渡すと、各コンストラクトはツリーにそれ自体を追加でき、この動作はConstruct
基本クラス に完全に含まれています。これは、 でサポートされているすべての言語で同じように機能 AWS CDK し、追加のカスタマイズは必要ありません。
重要
厳密には、コンストラクトをインスタンス化this
するときに 以外のスコープを渡すことができます。ツリー内の任意の場所、または同じアプリ内の別のスタックにコンストラクトを追加できます。例えば、引数として渡されたスコープにコンストラクトを追加する混合形式の関数を記述できます。ここでの実用的な難点は、コンストラクトに選択した IDs が他のユーザーのスコープ内で一意であることを簡単に保証できないことです。また、このプラクティスにより、コードの理解、保守、再利用が難しくなります。引scope
数を悪用することなく、インテントを表現する方法を見つけるのがほとんどの場合です。
AWS CDK は、ツリーのルートから各子コンストラクトへのパス内のすべてのコンストラクトの IDs を使用して、 に必要な一意の IDs を生成します AWS CloudFormation。このアプローチでは、コンストラクト IDsは、ネイティブ のようにスタック全体ではなく、スコープ内で一意である必要があるだけです AWS CloudFormation。ただし、コンストラクトを別のスコープに移動すると、生成されたスタック固有の ID が変更され、同じリソースと見な AWS CloudFormation されません。
コンストラクトツリーは、 AWS CDK コードで定義したコンストラクトとは別のものです。ただし、ツリー内のそのコンストラクトを表すノードへの参照である任意のコンストラクトの node
属性からアクセスできます。各ノードは、ツリーのルートとノードの親スコープおよび子へのアクセスを提供する の属性であるNode
インスタンスです。
-
node.children
– コンストラクトの直接の子。 -
node.id
– スコープ内のコンストラクトの識別子。 -
node.path
– すべての親の IDs を含むコンストラクトのフルパス。 -
node.root
– コンストラクトツリー (アプリ) のルート。 -
node.scope
– コンストラクトのスコープ (親)。ノードがルートの場合は未定義。 -
node.scopes
- ルートまでのコンストラクトのすべての親。 -
node.uniqueId
– ツリー内のこのコンストラクトの一意の英数字識別子 (デフォルトでは、node.path
とハッシュから生成されます)。
コンストラクトツリーは、コンストラクトが最終的な AWS CloudFormation テンプレートのリソースに合成される暗黙的な順序を定義します。あるリソースを別のリソースの前に作成する必要がある場合、 AWS CloudFormation または Construct Library AWS は一般的に依存関係を推測します。次に、リソースが正しい順序で作成されていることを確認します。
を使用して、2 つのノード間に明示的な依存関係を追加することもできますnode.addDependency()
。詳細については、 AWS CDK API リファレンスの「依存関係」を参照してください。
AWS CDK は、コンストラクトツリー内のすべてのノードにアクセスし、各ノードに対してオペレーションを実行する簡単な方法を提供します。詳細については、「側面」を参照してください。
アプリケーションのライフサイクル
CDK アプリをデプロイすると、次のフェーズが実行されます。これは、アプリケーションライフサイクル と呼ばれます。
![](images/Lifecycle.png)
AWS CDK アプリケーションは、ライフサイクルの次のフェーズを実行します。
-
構成 (または初期化) — コードは、定義されたすべての構成をインスタンス化し、それらをリンクします。この段階では、すべてのコンストラクト (アプリケーション、スタック、子コンストラクト) がインスタンス化され、コンストラクターチェーンが実行されます。アプリコードのほとんどはこの段階で実行されます。
-
準備 —
prepare
メソッドを実装したすべてのコンストラクトは、最終状態をセットアップするための最終変更ラウンドに参加します。準備フェーズは自動的に行われます。ユーザーとして、このフェーズからのフィードバックは表示されません。「prepare」フックを使用する必要はほとんどなく、通常はお勧めしません。オペレーションの順序が動作に影響を与える可能性があるため、このフェーズでコンストラクトツリーをミューテーションする場合は注意が必要です。 -
検証 —
validate
メソッドを実装したすべてのコンストラクトは、それらが正しくデプロイされる状態であることを確認するために、自分自身を検証できます。このフェーズで検証に失敗した場合は、通知を受け取ります。通常、できるだけ早く (通常は入力を取得するとすぐに) 検証を行い、できるだけ早く例外をスローすることをお勧めします。検証を早期に実行すると、スタックトレースがより正確になり、コードを安全に実行し続けることができるため、信頼性が向上します。 -
Synthesis – これは、 AWS CDK アプリケーションの実行の最終段階です。これは への呼び出しによってトリガーされ
app.synth()
、コンストラクトツリーを横断して、すべてのコンストラクトでsynthesize
メソッドを呼び出します。を実装するコンストラクトsynthesize
は合成に参加し、結果のクラウドアセンブリにデプロイアーティファクトを出力できます。これらのアーティファクトには、 AWS CloudFormation テンプレート、 AWS Lambda アプリケーションバンドル、ファイルとDockerイメージアセット、およびその他のデプロイアーティファクトが含まれます。 はこのフェーズの出力クラウドアセンブリについて説明します。ほとんどの場合、synthesize
メソッドを実装する必要はありません。 -
デプロイ — このフェーズでは AWS CDK CLI、 は合成フェーズによって生成されたデプロイアーティファクトクラウドアセンブリを取得し、 AWS 環境にデプロイします。アセットを Amazon S3 と Amazon ECR にアップロードするか、必要な場所にアップロードします。次に、 AWS CloudFormation デプロイを開始してアプリケーションをデプロイし、リソースを作成します。
AWS CloudFormation デプロイフェーズが開始されるまでに、 AWS CDK アプリケーションはすでに終了し、終了しています。これにより、以下の影響があります。
-
AWS CDK アプリケーションは、作成中のリソースやデプロイ全体の終了など、デプロイ中に発生するイベントに対応できません。デプロイフェーズでコードを実行するには、カスタムリソース として AWS CloudFormation テンプレートにコードを挿入する必要があります。アプリケーションへのカスタムリソースの追加の詳細については、AWS CloudFormation モジュール または custom-resource
の例を参照してください。 -
AWS CDK アプリは、実行時に認識できない値を操作する必要がある場合があります。例えば、アプリケーションが AWS CDK 自動生成された名前で Amazon S3 バケットを定義し、
bucket.bucketName
(Python:bucket_name
) 属性を取得した場合、その値はデプロイされたバケットの名前ではありません。代わりに、Token
値を取得します。特定の値が使用可能かどうかを判断するには、cdk.isUnresolved(value)
(Python: ) を呼び出しますis_unresolved
。詳細については、「トークン」を参照してください。
クラウドアセンブリ
への呼び出しapp.synth()
は、アプリケーションからクラウドアセンブリを合成 AWS CDK するように に指示するものです。通常、クラウドアセンブリと直接やり取りすることはありません。これらは、アプリケーションをクラウド環境にデプロイするために必要なすべてを含むファイルです。例えば、アプリケーション内の各スタックの AWS CloudFormation テンプレートが含まれています。また、アプリで参照するファイルアセットや Docker イメージのコピーも含まれます。
クラウドアセンブリのフォーマット方法の詳細については、クラウドアセンブリ仕様
AWS CDK アプリケーションが作成するクラウドアセンブリを操作するには、通常 を使用します AWS CDK CLI。ただし、クラウドアセンブリ形式を読み取ることができる任意のツールを使用してアプリケーションをデプロイできます。
アプリケーションの実行
CDK は、 AWS CDK アプリの実行方法を知るCLI必要があります。cdk init
コマンドを使用してテンプレートからプロジェクトを作成した場合、アプリケーションの cdk.json
ファイルには app
キーが含まれます。このキーは、アプリケーションが書き込まれる言語に必要なコマンドを指定します。言語にコンパイルが必要な場合、コマンドラインはアプリケーションを実行する前にこのステップを実行するため、忘れることはありません。
CDK を使用してプロジェクトを作成しなかった場合CLI、または で指定されたコマンドラインを上書きする場合はcdk.json
、cdk
コマンドを発行するときに --appオプションを使用できます。
$
cdk --app 'executable
'cdk-command
...
コマンドの実行可能な
部分は、CDK アプリケーションを実行するために実行する必要があるコマンドを示します。示されているように引用符を使用します。このようなコマンドにはスペースが含まれているためです。cdk-command
は、アプリでCLI何をするかを CDK に指示deployする synthまたは のようなサブコマンドです。これに従い、そのサブコマンドに必要な追加オプションを指定します。
AWS CDK CLI は、既に合成されたクラウドアセンブリと直接やり取りすることもできます。そのためには、クラウドアセンブリが保存されているディレクトリを に渡します--app。次の例では、 に保存されているクラウドアセンブリで定義されたスタックを一覧表示します./my-cloud-assembly
。
$
cdk --app./my-cloud-assembly
ls