AWS workshop studioのECS Web Applicationハンズオンを題材に、AWS CDKに入門してみています。

背景

普段の業務では、アプリケーションの運用にEKSを使っています。

最近新規事業の立ち上げを行なっており、プロトタイプをデモするための環境としてECSを使い始めてみました。

今は手運用に頼ってしまっており、完全にリソース管理が属人化してしまっているのが課題です。
そこでAWS CDKを使ってリソース管理を行えるようにしていくため、CDKに入門してみました。

AWS CDK Patternsは使わずに実施しています。

今回は、3.5 EC2へのデプロイまでを実施しました。

環境

Macbook Air (CPUはM3)
これがなぜ書く必要があるのかは後述
Typescript

EC2のデプロイまで

まずは「3.5. EC2 へのデプロイ」までが動くようになったのがこちら。（ちょっとまだ直すべき点はあり）

以下のリソースが作成されます。

VPC
パブリックサブネット x2
EC2　オートスケーリンググループ
ECSクラスタ
ECSタスク定義
ALBでロードバランシングされるECSサービス

学び

サブネットはVPCと一緒に作る

VPCの作成時にオプション指定でサブネットを作っています。
PublicSubnetというのもありますが、これを使ってもいわゆる「パブリックサブネット」にはなりません。結局はigwの定義を自分で書き、ルートテーブルも自分で設定する必要があるようです。

Constructは暗黙的なリソースの作成がある

CDKは、全てのリソースを自分で明示的に書くのではなく一部のリソースを自動作成に任せるのが「CDKらしい」書き方らしいです。

例えば「サブネットはVPCと一緒に作る」のところにあるように、 new ec2.Vpc(...) のオプションを適宜与えると、VPCと同時にサブネットが作成されます。

VPCとサブネットはわかりやすいですが、セキュリティグループ周りはかなり暗黙的な部分が多そうです。

new ecs.EC2Service(...) はデフォルトでは自動でセキュリティグループを作成します。このセキュリティグループはALBにアタッチされるセキュリティグループからのインバウンドアクセスが許可された状態になります。

このインバウンドルールの自動設定に至ってはドキュメントを見ても、どこで実施されているのか明示的な答えが見つからず。
ALBとECSサービス両方に触れる記述はここくらいですが、ここで自動でセキュリティグループのインバウンドルールが追記されるのでしょうか。

const targetGroup = new elb.ApplicationTargetGroup(this, "MyTargetGroup", {
  vpc,
  port: 5000,
  protocol: elb.ApplicationProtocol.HTTP,
  targets: [ecsService],
});

インスタンスのCPUアーキテクチャに注意

最初はEC2のインスタンスタイプにt3.smallを選んでしまっていました。

途中コンテナが立ち上がらないしログも出ない〜と詰まってしまいふと気づいたのがCPUアーキテクチャの違い。

Apple Silicon のMacでビルドしたDockerイメージなので、ARM用のイメージになっていたんですね。ということでt4g.smallに変えてみたらコンテナが立ち上がりました。

今後の改善

現状では、一つのスタックの中にECRリポジトリの作成と、そのリポジトリのイメージを使ったECSタスクの開始が書かれてます。
なので、ECSタスクは空のECRリポジトリからイメージを取ってくるのに失敗してタスクを開始できず、cdk deployが完了しません。

ECRリポジトリの作成とECSタスク定義は少なくともスタックを分ける必要があります。

また記述量が増えていくにつれてファイルも肥大化してきてしまっているので、モジュール分割も必要になってきます。

ハンズオンに沿ってFargateでのデプロイ等も進めていく予定ですが、同時にリファクタリングも行なってみようと思います。