5章 CDK詳説

cdk init -l typescriptで初期化
cdk.jsonを読む
- 先頭の"app": "npx ts-node --prefer-ts-exts bin/sqs.ts",
  - cdkコマンド実行時に毎度typescriptアプリを実行しているという意味で良い
リソースの記述はlib/sqs-stack.tsに書いていく
StackはCFnスタックのこと
- CFnテンプレートひとつ（分割しない場合）にできるリソースの集まりのこと
newするときの引数は基本的に3つ
- scope
  - Constructを渡す
  - 大抵はthis
  - 親ノードのコンストラクタ
- id
  - this内でユニークである必要がある。synth時点でエラーが出る
    - 特にループで生成する時には適当なsuffix足したりする。indexとか
  - StackNameを指定しない限りスタック名に使われるぽい
- props
  - コンストラクタごとに違う
IAMなんかのセキュリティ関連の変更がある時にはデプロイ目に確認が入る
- yを押すあれ
cdk deployとかのデプロイ先を指定するのは、cdk bootstrap時にリージョン指定する
- AWS_REGION=ap-northeast-1 cdk bootstrap --profile sandbox
コンストラクタのツリー構造
- Node.jsアプリの中でコンストラクタを呼び出す順番みたいなもの
- 依存関係を把握することでノード配下のノードに共通の属性を設定するのに使ったりする
- tree.jsonでわかる
コンストラクタの種類
- L1コンストラクタ
  - 接頭辞にCfnがつく
  - propsにキャメルケースでCloudFormationのリソース属性を渡す
- L2コンストラクタ
  - 楽に作れる代表例がVPC
  - いい感じに抽象化されている
  - リソースによってはIAMロールとかセキュリティグループも自動生成してくれる
  - 指定できない属性もあるので、L2コンストラクタをL1コンストラクタに渡す感じで工夫する
  - まだ用意されてないこともある。今だとReadShiftとか
- L3コンストラクタ
  - アプリケーションレベルの抽象化
  - 超定番の構成でたまに用意されてる
コンストラクタツリー
- Metadata: "aws:cdk:path": "SqsStack/MyQueue/Resource"だとApp->SqsStack->MyQueue->Resourceの順でコンストラクタが呼ばれていることがわかる
VPCだと1個作るのにすごいツリー構造になっててキモい
- サブネット2種類とかルートテーブルとかIGWとかSGとかを作っている
cdk lsでプロジェクト内のスタック一覧
cdk synth {スタック名}で特定のスタックだけ合成
cdk deploy {スタック名}で特定のスタックだけデプロイ
- というか複数スタックある時には指定必須
- もしくは–allオプション
cdk destroy {スタック名}で特定のスタックだけ削除
- –allも可能
分割粒度（公式のベストプラクティスを噛み砕くと…）
- デプロイパターンに基づいて柔軟に検討する
- リソースを分離したいニーズがない限り1スタックにまとめるのが簡単で推奨
- ステートフルリソースはステートレスリソースと分けることを検討
  - ステートフルリソースはDBが代表
yamlのCFnテンプレートがほしい時
- cdk synth {StackName} > template.yaml
- スタック名していない時はcdk.out配下にjsonが出力されるが読みづらい
new ec2.Vpc()してるだけでプライベートサブネットとパブリックサブネットと色々作られる

環境変数

デプロイ先の初期値
- コンストラクタのpropsでenv.regionを指定する
propsのenvを指定しないスタックは’Environtment-agnostic’スタックと呼ばれる
- こういうスタックだと使えない静的メソッドとか、配置できるAZ数とかで制限がある
envへの渡し方
- 【非推奨】props.envに環境変数から渡す（process.envを使う）
  - .envとかの値の不足で意図せずにagnosticスタックになるリスクがある
- おすすめは明示的に指定するらしい

複数環境にデプロイするには

dev, stg, prod的な環境ごとにデプロイするには？
AWSアカウントIDをcdkコード内に書く方法が進められている
- environments.tsファイルに書いてる
cdk.jsonに環境依存パラメータを書いてtryGetContext()で取得する方法もあるけど、型の支援が受けられないので読んだ本では推奨されていない
複数環境にデプロイするときの方法は大きく2通り
- ①全ての環境のスタックを記述する
  - AWSドキュメントでも書いてある
  - 全環境分毎度作る作りだと時間かかりすぎる
  - AWS環境のNode.jsアプリとしてやりたい時には不要な情報が多いかも
- ②cdkコマンドの実行時に環境を指定する
  - 環境変数とかで指定する？
  - STAGE=dev AWS_PROFILE=sandbox cdk deploy dev-*
CDKにStageコンストラクタが用意されている
- new cdk.Stageしたやつをappの代わりに使う感じ
- スタック名にStageの第二引数を使ってくれるので同じアカウントに複数環境デプロイする時に楽
リソースへのタグ付
- スタック全体に一律でつけたかったらTags.of()の引数にできるだけ上のコンストラクタを渡す
- ルートノード（app）の子ノードでStageを使ってる時にはTags.of(app)でもタグ付できない
  - Stageでcdk.out配下でディレクトリ切られるみたいだけど、ディレクトリを跨いでタグ付できないみたいな言い方
L2コンストラクタで属性が足りない時に、L1と組み合わせたい
- エスケープハッチ
  - L2コンストラクタの抽象化から一時的に脱出するみたいな意味合いらしい
- rawオーバーライド
  - K1コンストラクタにもないCFn属性の上書き？
- すごいわかりづらくなるらしいので注釈はしたがいい

スタック間での参照

CFn

CFnだと、OutputsセクションでExport属性内に書くと、他のスタックでImportValueできるようになる
スタック間の依存関係が複雑かしやすいので無闇に多用しない方がええ
- 削除更新でめんどくさい

# エクスポートする側
Outputs:
  MyBucketName:
    Value: !Ref MyBucket # 出力する値
    Export:
      Name: MyBucketNameExport # 他スタックから参照するときの値。ユニークじゃないといけない

# インポートして使う側（別スタック）
Resources:
  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      Environment:
        Variables:
          BUCKET_NAME: !ImportValue MyBucketNameExport

CDK

2通り紹介されている
- CFnのOutputsセクションに当たる処理をコードに書く
  - vpcスタックのコンストラクタ内で、new cdk.CfnOutput(this, 'VpcIdOutput', { value: vpc.vpcId, exportName: 'MyVpcId' });みたいに書く
  - インポート側はcdk.Fn.importValue(exportName)
- コンストラクタのインスタンス変数をスタック間で参照する
  - vpcスタックのインスタンス変数に持っておく
  - 参照側はコンストラクタの引数で受け取れるようにしておく
  - 実態としてはCFnのOutputs/ImportValueに変換されている
  - cdkがよしなに依存関係を把握してくれた結果なので、注意が必要なケースもある
    - 依存関係の下流（importValueする方）のスタックを指定してデプロイしたいのに、上流までデプロイされることがある。特定スタックだけデプロイしたい時には--exclusivelyオプションを使うのが安全
    - cdk.Fn.importValueの方だと発生しない

インポート/エクスポートがある依存関係があるスタックを使うときの留意点

更新削除でエラーがでがち
- エクスポートしてる値の更新
- スタック削除
- これを考えると、インポート・エクスポートを使う基準は「基本的にエクスポート値が変更しないもの」？
例として、スタックAでエクスポートして、スタックBでインポートしているケース
- Aのエクスポートしている値を更新したいとき
  - BがAを参照していない状態にする
    - インポート記述をFn::ImportValueから具体的な値に変えてスタック更新
  - Aを更新してエクスポート値を更新
  - Bのインポート記述を戻して更新

CDKで生成されるCFn

Resources
Parameters
- CDKだとコード内で書くのであんまり絡みがない
- SMS Parameter Storeで取る値はParametersに書いて生成されることもあるぽい
組み込み関数
- CDK内でもaws-cdk-libモジュールのFn.subとかで使える
cdk.jsonを編集して生成するCFnテンプレートの内容を幾らか制御できる
- versionReporting
- pathMetadata
- assetMetadata

CDKでの単体テスト

cdk initした時にはjestがセットアップされている
- テスト観点多いので、メンテコストの観点から読んだ本では推奨されてなかった
テンプレートのスナップショットテストが進められている
- 生成したCFnテンプレートが期待するテンプレートと一致するか
- スナップショットは初回のnpm test時に自動生成されるらしい
  - test/__snapshots__/配下に保存される
  - これもgit管理対象
- コード修正時のテストの変更フロー
  - テストで落ちた内容を吟味→差分が妥当ならスナップショット差し替え
  - npx jest -uでスナップショット更新
- テキストのp187あたり
- 環境やスタックごとにスナップショットテストするには
  - テキストに書いてある

cdk bootstrap時に何が起こっているか

s3バケット、ECRリポジトリ、IAMロール、SSM パラメータストアとか
S3
- アセットの格納先
ECR
- lambda関数のコンテナイメージの格納
IAMロール
- CDK CLIがassume roleするのに5つくらい作ってるぽい
- CDK CLIがCFnテンプレートにpassRoleしてる
CDKを実行するのに最小の許可ポリシー
- 厳密にはブートストラップ時に作られる5ロールのうちプリンシパルがユーザーのものがあれば良い
- ただこれを付与すると結構強力な権限なので結局使えるリソース単位のポリシーみたいな制御をする

スタック操作失敗時のトラブルシュート

削除失敗
- たいていは削除しようとしたリソースが他のリソースから参照されているとか、
  - S3バケットだと空じゃないと削除できない
- セキュリティグループをマネコンで別のリソースにアタッチしちゃったとか
- 削除ポリシーでRetainにすれば一旦消せるだけ消せる
  - 削除できなかったものは手動で頑張れ
更新時に削除失敗
- テンプレートから対応するリソース記述がなくなったとか、リソース置換とかがあると、リソース削除を試みる
- 削除失敗の原因は上記と同じ
- 3回再施行するらしい
- 削除失敗しても更新は続行する
  - 削除失敗したりリソースが残って課金されることもあるので注意
  - 削除に失敗したリソースは特別報告されない？
更新に失敗して、ロールバックにも失敗する
- 基本的には起こらない
  - リソースが手動操作もされたことがあった
  - EOSとかで、起動し続けてても良いけど新規では起動できないバージョンとか
    - RDS、lambdaランタイム
- CFnステータスはUPODATE_ROLLBACK_FAILED
  - 更新を再実行はできない
  - 「更新ロールバックを続ける」を実行してUPDATE_COMPLETEになったら再度更新ができるように戻る
  - イベントタブにロールバックの失敗原因が書いてある
    - その原因を手動で除く
    - 除けないなら「スキップするリソース」欄にチェックしたら良い

5章 CDK詳説

new ec2.Vpc()してるだけでプライベートサブネットとパブリックサブネットと色々作られる

環境変数

複数環境にデプロイするには

スタック間での参照

CFn

CDK

インポート/エクスポートがある依存関係があるスタックを使うときの留意点

CDKで生成されるCFn

CDKでの単体テスト

cdk bootstrap時に何が起こっているか

スタック操作失敗時のトラブルシュート

除けないなら「スキップするリソース」欄にチェックしたら良い