cdk を使ってみました。Infrastructure as a Code のフレームワークです。

AWS には CloudFormation というものがあります。これは、json や yaml でインフラ構築をテンプレートを使って定義して、 cli からその定義を流し込んで AWS Console を使わずに構築するものです。

画面操作で環境を作ってしまうと、環境構築の再現性が不確実なので、できるだけ早めに CloudFormation に移行した方がいいと、 ずっと思ってました。

そして、今回は、この CloudFormation のもう一歩先の cdk を使ってみたという話です。

CloudFormation は、json とか yaml の定義ファイルなので、定義の名称を間違えると、当然、正しく動かないわけで、動かないときに、 何が問題で動かないのかを探すのが、けっこう大変だったりします。

例えば、 S3 -> EventBridge -> StepFunctions -> Lambda -> Glue などと、細かくサービス間で連動して機能するような場合、なかなか面倒です。

そこで、Infrastructure as a Code ということなんだけど、たぶん、cdk を使わずに CloudFormation の定義を書いてる人たちも、 簡単なスクリプトを自作して、json や yaml を作成していると思います。 サービス間のつながりは、定義ファイル上の ID でリンクされるので、せめて、IDは、スクリプトの変数で共通化したいと思うわけです。

さて、cdk ですが、何をやってくれるかというと、実は上記の簡単なスクリプトがやってることと同じなんです。 CloudFormation の定義をプログラムで出力して、aws に投げて、インフラを作ってくれるんです。 自前のスクリプトよりもよいのは、型定義があるので IDE のコード補完の恩恵があるということと、デフォルト設定のようなものがカプセル化されてて、 書かなくてよいので、コード量が少なく可読性が高いというのがよいです。 DBのマイグレーションのコードを書いたことがある人は、インフラ構成のマイグレーションをやってくれるツールだと思ってもらえると近いです。

ちなみに、 cdk でデプロイしてみると、使われていないサービスの設定があったりすると、デプロイ時にエラーにしてくれたり、 デプロイ済のインフラ構成との差分を抽出して、その差分だけを反映してくれるんだけど、このあたりは、CloudFormationが持ってる機能です。

例えば、DBのマイグレーションツールは、DB内に、マイグレーション用のテーブルを作成して、そこで、差分管理をしてますが、 CloudFormation も似たようなもので、CloudFormation 上に Stack というものを作成して、そこで、管理されているようです。
※CloudFormation はS3バケットを作るだけの部分的な用途に利用するものではなくて、システム構成一式を管理するためのものです。

cdk に懸念点があるとすると、cdk は AWS が開発してるものだから、AWS専用で、ベンダーロックインなところだけど・・・、 少しほかを探してみると、CDK for Terraform というのが HashiCorp で開発されてました。 これは、CloudFormation じゃなくて、Terraform を使っているから、 GCP、 Azure にも対応してて、そして、 この CDKTF は、 AWS の cdk と同じコンセプトで、且つ、cdk の一部も使って作られているので、cdk に慣れておけば、GCP や Azure 用に IaS するときにも、 cdk の学習が生かされるということになります。

インフラの設定をすることになったら Infrastructure as a Code で構築することは MUST で、手っ取り早く cdk で構築する。 これが今のベストな選択かな。

実際取り組んでみると、Vagrant を使い始めたときより簡単にモノにできるし、Ansible よりも楽です。