CDK for Terraform
CDKTF のアーキテクチャについて
Appクラス
App クラスの中にいくつかの Stack があります
Stack クラス
インフラリソースの集まり
Resource クラス
Construct
Resource
リソースのリネーム
既存のリソースのインポート
Module
プロジェクトを超えてライブラリを共有する場合
DataSource
他のterraformプロジェクトからデータを引っ張って来れる
これは Terraform の説明っぽくて、CDKTF ではそんなに気にしなくていいように思える
Terraform Cloud 使いたい場合に役に立つらしい
Terraform Cloud を使わない場合は、プログラミング言語の書き方に従って引数を受け取ればいいらしい
Functions
ビルドイン関数(あらかじめ用意されている関数)
AWS の region から AZ 一覧を取得する関数など
Iterators
for 文とかでいい気がする
Remote Backends
tfstate をどこで管理するかの話
Aspects
あんまり使わなさそうではある
たとえば、作成したリソースのうち特定のものには自動で hogehoge する、というのを実装するのに使えそう
Assets
特定のファイルを S3 にアップロードしたり(lambda の実行ファイルなど)できる
Tokens
token とは、Terraform が実行されて初めて確定する変数のこと
Stack
CDKTF の Stack と、 Terraform の Stack はコンセプトが異なるので注意
Scope について
同じ Stack の中にあれば、同じ Scope にあるといえる
同じ Scope の中にあるものには同じ name をつけることはできない
Cross-stack References
Stack Dependencies
cdktf.out/manifest.json の dependencies にスタックの依存関係を定義できる
デフォルトだと自動で依存関係を計算してくれる
依存関係を無視してスタックを deploy しようとするとエラーになる
リファクタリング
リソースのリネームについて
デフォルトだと、リソースの名前を変えた場合に、リソースを削除して作成しなおしてしまうが、moveTo() を使えばそれを回避できる
CDKTF のベストプラクティス
以下のような場合は Stack を分けるべき
development / staging / production ではスタックを分けるべき
アプリケーションの目的が異なるならスタックを分けるべき
リージョンが異なるなら分けるべき
ソフトウェアのコンポーネントごとに分けるべき
network, db, conpute
これはなぜ...?
デプロイメント(更新)サイクルが異なるなら分けるべき
CDKTF コマンドから参照される環境変数
Deployment patterns
デプロイ方法が何パターンかある
CDKTF コマンドを使ってデプロイする場合
cdktf synth を使って terraform のコマンドでデプロイする場合
デフォルトの cdktf deploy はこの挙動になっている気がする...?