AWS CDKの昨今
最近は仕事でもプライベートでもAWSのリソース配備にはAWS CDKを使っている。
ちなみに最近はCDK for Terraformが出るなど、AWSに限らないツールキットを指向している雰囲気があるので「仕事は {ここにAWS以外のクラウドプロバイダが入る} だからな〜」「AWS以外も含めたハイブリッドクラウド環境だからな〜」という人も一度触ってみるとおもしろいのではないでしょうか。
ちなみにCDK for Terraformのようなものを作る布石はaws/constructsという前は@aws-cdk/core以下にあった階層や依存関係を表現する基礎的なクラス群が独立したライブラリとして提供されはじめたころからあったと思われる。
CDKはCloud Development Kitという名の通り従来のIaCというところから一歩進んだ「クラウド開発キット」であり、マネージドサービスを使っていくとインフラかアプリケーションかという区別が曖昧になっていくなら、構築支援するライブラリ・ツールキットもそれらを無理に分け隔てる必要はないのでは? という着想が垣間見える。実際使っていると隔たりが限りなく取り払われていく感触がある。
たとえばAWS CDKには手元のファイルをS3にアップロードしたり、手元のディレクトリでdocker buildしてECRにイメージをpushするライブラリなどがあったりする。Lambdaのコードを手元からアップロードするのはとても便利。
アプリケーションを上から下までプログラムで構築していくという考え方が徹底している。そういった話は1年前くらいの発表で触れていて、変わりない。
CDKのベターデフォルト
cdk initで雛形はできるけれど、いくつかの点で不満がある。
- ESLintが同梱されていない
- ここに空白あったほうがいいですね、とか議論していい時代はもう終わった
- renovateが設定されていない
- CDKは頻繁に更新されるのでこれ無しではすぐに滅ぶ
- アップデートはさほど苦しくないので自動化を徹底することが大事
- GitHub Actionsの設定がない
- TypeScriptのコンパイルが必須
などなど。
ESLintとかはともかく、TypeScriptのコンパイルを必須とするのは個人的にはCDKのような、Vanilla JSへ変換することが必須だったりアセットの整合性を追跡したいような要件がない場合には冗長だと感じる。
なので--noEmitとts-nodeで良いじゃん派。cdk deployとかして古いな〜 → コンパイルしていなかった、というようなできごとで失う時間のほうが多いと考える。
ので、良いかんじのtsconfigなどを込みにしたリポジトリを作った:
含めてあるものは上記の通りで、
- ESLintと良いかんじの設定
- renvoateの設定
- 良いかんじのtsconfig
など。
テストなどはcdk initで出力されるものを基本的に踏襲している。
