背景

Headless CMS を自前で運用してみたかったので、Docker Image が提供されている Strapi を動かしてみようと試みたが、うまくいかなかった記録。

ローカルで動かすのはストレージ故障などの不安があり、一方で AWS 上で動かすと常時稼働分リソースの料金が気になる。どうしたものかと考えたところ、以下の構成に落ち着いた。

構成

Fargate
- 使うときに ecs:RunTask して FARGATE_SPOT の Strapi を起動
- 使い終わったら ecs:StopTask
Aurora Serverless
- プライベートな利用なのでスリープからの復帰時間が生じても問題ない

ポイント

Strapi の Docker Image は、初期起動時に yarn build などのセットアップを行う。環境によっては十分以上かかることもある。
Fargate 起動のたびにこれが生じるとさすがに待ち時間が辛いため、ローカルでセットアップさせ、完了後のコンテナを docker commit で改めてイメージ化し、Fargate で稼働させる。

リポジトリ

Terraform で以下を構築している。

VPC
Subnet
IGW
Route Table
Security Group
Aurora Serverless Cluster
ECR
ECS Cluster
ECS Task Definition
CloudWatch Logs

構築・起動

# インフラ構築
cd terraform
terraform apply -var 'master_password=XXX'

# ローカルでセットアップ開始
cd ..
docker compose up -d

# イメージ作成
make commit
# -> (1)

# イメージをプッシュ
make login
make push

# Fargate を RunTask
cd ..
make run_task
# -> (2)

生じた問題

(1) docker commit しても一部ファイルがイメージに含まれない

Strapi がセットアップ時に生成したファイルが、commit したイメージに含まれていなかった。
原因は以下。

コンテナ内でマウントされているボリュームに含まれるデータは、コミット作業に含まれません。
http://docs.docker.jp/v19.03/engine/reference/commandline/commit.html

WORKDIR でもある /srv/app が、 Dockerfile で VOLUME 指定されている。

公式の Dockerfile をコピーして、VOLUME しないように書き換えることで回避は可能そうだが、少し気持ち悪い。
本問題を解消しなくても Fargate 上で再度セットアップされるだけなので、一旦はそのままにした。

(2) KnexTimeoutError

Fargate を RunTask すると KnexTimeoutError が発生し、Strapi の起動に失敗した。

調べてみると上記がヒットした。データベースのスペックが低いことに依るものとの記載があり、Aurora Serverless ゆえの問題かもしれない。
また、上記記事では yml を書き換えることでも解消したとの記載があった。やはり自前で Dockerfile を用意する必要があり、ここで力尽きた。

まとめ

せこいことをやろうとするとうまくいかない、という好例であった。
素直に API Gateway + Fargate + Aurora (not Serverless) という構成にすれば、おそらくすんなりと動いてくれるはずである。