背景
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) という構成にすれば、おそらくすんなりと動いてくれるはずである。