よ〜んです。

前回の記事では、Spring BootでシンプルなTodoアプリを作りました。

今回は、そのアプリを動かすインフラをAWS CDKで書いて、cdkdからデプロイしてみます。

気になっていたのは、L3 Constructすらもそのまま使えるのか、というところです。

cdkd#

cdkdはCDK Directの略で、AWS CDKのアプリケーションを、CloudFormationのスタック経由ではなくAWS SDKやCloud Control APIを使ってデプロイするツールです。

CDKのコードからCloudFormationテンプレートを生成し、それをもとにcdkdがリソースを作成・更新します。インフラを書くのはCDK、デプロイを担当するのはcdkd、という分担ですね。

cdkd - README

前回のアプリをAWSへ#

ちょっと前の記事で作ったTodoアプリを、ALB付きのECS Fargateで動かし、Aurora PostgreSQL Serverless v2に接続する構成をCDKで書きました。

コードはexamplesリポジトリに置いてあります。

ApplicationLoadBalancedFargateService(L3 Construct)について#

L3 Constructは、複数のリソースをよく使う構成としてまとめたものです。今回なら、ECSサービスやALBなどを一つのConstructから定義できます。

実際のコードから、設定の一部を抜粋するとこんな感じです。

const service = new ecsPatterns.ApplicationLoadBalancedFargateService(this, 'ApiService', {
  cluster,
  publicLoadBalancer: true,
  listenerPort: 80,
  assignPublicIp: true,
  cpu: 256,
  memoryLimitMiB: 512,
  // その他の設定は省略
});

ここは普段のCDKの書き方です。今回使ったFargateのL3 Constructは、cdkd専用の定義へ書き直すことなく利用できました！！！

できるだろうな〜と思いつつ検証しましたが、すごいの一言です。。。

デプロイしてみる#

デプロイ時には--full-waitを付けました。cdkdはデフォルトではECSサービスの安定状態まで待ちませんが、このオプションを付けるとそこまで待つようになります。

参考：Wait Modes

デプロイ後にアクセスすると、前回作ったTodo画面が確認できました。

まとめ(？)#

今回試したかったのは、L3 Constructも普通に使えるのかというところです。

速度比較はしていませんが、L3を使いながら、デプロイの仕組みを変えて素早くデプロイできた体験は素晴らしかったです。

ではでは〜