こんにちは、ちゃりおです。
「The CDK Book」読んでみました。
CDKは比較的新しいIaCツールのため、実践的な内容については他のツールに比べてノウハウが少ない印象でした。
本書では、CDKの使い方だけではなく、Configの管理やデプロイ戦略、テストなど業務で使う際に役立つ情報が盛り込まれています。
CDK WorkShopをやった後のステップアップに最適な一冊かと思います。
Contents
The CDK Book
目次
1. What is the Cloud Development Kit?
2. What Are Constructs
3. Publishing Constructs
4. Leveraging your Integrated Development Environment
5. Project Layout
6. Custome Resources and CFN Providers
7. Configuration Management
8. Assets
9. Testing
10. Enterprise Construct Libraries
11. Deployment Strategies
12. Importintg CloudFormation Templates
13. Combining AWS CDK With Other Dev Tools
14. Next Steps
15. Appendix 1: Migrating from CDK 1 to 2
全体的に
ブログ「AWS CDKでクラウドアプリケーションを開発するためのベストプラクティス」を更に詳細にして、サンプルコードもつけたような内容です。
CDKのコマンドやConstructsについて基礎的なところから、テストやデプロイ戦略、CloudFormationのImportなど幅広い内容が盛りこまれています。
目次だけ見ても、運用時の課題を解消してくれそうな本だと思いました。
私は、特に以下の項目が気になりました。
5. Project Layout
10. Enterprise Construct Libraries
11. Deployment Strategies
本書のいいなと思ったところは、サンプルコードの言語が一つだけではないということです。
それぞれの言語版のコンテンツが用意されています。(goも対応する予定らしいです)
5. Project Layout
各ファイルや各フォルダの説明です。(projenの方もあります)
CDKをアプリケーションリポジトリに置くか、リポジトリ分けるかという話がありました。
アプリケーションリポジトリに入れておけば、Assetsを使ってECRへのpushやS3へのファイルアップロードが楽です。
ただ、CDKへのデプロイとアプリケーションへのデプロイが別のパイプラインの場合は、デプロイのトリガーを分ける必要があります。
(アプリケーションへの変更があったときだけ、デプロイするトリガー/CDKへの変更があったときだけ、デプロイするトリガー)
同一のパイプラインでよければアプリケーションリポジトリに入れるのがいいのですが、できない場合はリポジトリを分けたほうが良いです。
7. Configureation Management
CDKでのConfig管理についてです。
vpcIdとかInstanceTypeとか環境によって変えたい値があると思います。
そういった値をどう管理すればよいのかが書いています。
以下の方法が紹介されていました。
- contextで渡す
- cdk.json/コマンド実行時にオプションで渡す
- configの値をファイルに分ける(json)
- configの値をファイルに分ける(ts)
- サードパーティのサービスに置いて、実行時に動的に取得する
個人的には、「configの値をファイルに分ける(ts)」がちょうど良いかと思いました。
# /env/dev.ts
import { InstanceClass, InstanceSize, InstanceType } from 'aws-cdk-lib/awsec2';
export const config = {
vpcId: 'vpc-abcd0123',
instanceType: InstanceType.of(InstanceClass.R5, InstanceSize.XLARGE),
};
# main.ts
import { config as devProperties } from './env/dev';
import { config as prodProperties } from './env/prod';
// Create our DEV RDS instance
new DbStack(app, 'DevDb', {
env: devEnv,
...devProperties,
});
// Create our prod RDS instance
new DbStack(app, 'ProdDb', {
env: prodEnv,
...prodProperties,
});
cdk.jsonに書いていく方法は、本書にも書いてある通り肥大化しがちです。
jsonファイルに分ける方法もありですが、せっかくならtypescriptの型の恩恵を得たいです。
実行時に動的に取得する方法は準備が少し大変そうです。
configで制御するものが少ない場合、用意する手間と見合わないかもしれません。
最初はｔｓのファイルに分ける方法で値が増えてきたら、実行時に動的に取得する方法に切り替えるのがいいかなと思いました。
本書とは関係ないですが、config管理は以下の記事も勉強になりました。
4 Methods to configure multiple environments in the AWS CDK
10. Enterprise Construct Libraly
組織内でのCDKのライブラリ化についてです。
CDKレベル、AWSアカウントレベルどちらでもコンプライアンスのための設定をしたほうが良さそうです。
AWSアカウントレベルだけでは、デプロイするまでわからずCDKを作成するスピードが落ちるためです。
CDKベストプラクティスにもある「コンプライアンスのためにConstructを使わない」と近しい内容がありました。
S3バケットを暗号化するような、単純なものをライブラリにするのは良くないようです。(Aspectを使えばできるので)
ApiGatewayをRestApiにして、WAFをつけるような関連リソースが多い構成を、ライブラリ化するのことを勧めていました。
(各要素の組み合わせの設定とかを、使う側が知らなくてすむ)
ライブラリ化しても、各リソースを使う人が設定変更できる形にしたほうがいいです。
構成変更のために、ライブラリを読んで設定変更のPRを投げる運用になってしまい使う側の負荷があがるからです。
設定の強制をライブラリ化の目的にせず、あくまで開発スピードをあげることを目的にしましょう。
まとめ
CDKはプログラミング言語でインフラを定義できる、とても便利なツールです。
書き方の自由度が高いため、迷うようなところがあると思います。
実運用で悩むポイントがいい感じに書いており、CDKの実装の指針になると思います。
英語なのは少しネックですが、文字数はそこまで多くなく、サンプルコードが多いのため、英語が苦手な方もGoogle翻訳でなんとかなると思います。
CDKを業務で使用している方に、おすすめの一冊です。
