AWS CopilotでFargate上に既存ツールを動作させようと四苦八苦していることについてまとめてみた

既存のBIツールデプロイを手軽くやってみたいという思いから色々試してみて、選択肢の一つとしてCopilotを試してみました。コマンドのオプションは手軽く、且つALBやECRへのリポジトリ作成も行ってくれるのはとても有り難い。

ただ、そう世の中甘くはないよと感じることもそこそこ。現在実行中で四苦八苦している状況について幾つか書いてみました。

Dockerfileはそこにあるのか

ビルドしたいリポジトリにDockerfileがあればcopilot initから試していきます。そうでなければ自身で作成する必要があります。

Deployに失敗したけれど原因がよくわからない

CloudWatchから辿るという手もありますが、出力が届いていないケースはよくあります。困った場合は以下のコマンドで確認してみましょう。

copilot svc logs

Dockerfile内での権限指定が漏れていたり、ファイルパスが誤っていたり等、修正してはDeployを繰り返すことになると思います。厄介なのは、docker-compose up等の他の手段で実施した際には全くエラーにならない場合があったりすることです。

Dockerfile修正がstack更新として扱われないためDeployしたくても反映されない場合

個人的に困りどころでした。今の所の対処方法としては、copilot svc delete後にcopilot svc initからcopilot svc deployと繰り返しています。要は、毎回更にしてやり直している感じです。

ServiceからRedisやPostgreSQLへつなぎこみたい

URLを環境変数で指定する場合は、copilot実行後に生成されるcopilot/xxxxx/manifest.ymlへ設定を足しましょう。必要な環境変数にもよりますが、以下のようになります。

variables: # Pass environment variables as key value pairs.
  REDIS_URL: redis://xxxxxxxxxxxx.apne1.cache.amazonaws.com
  DATABASE_URL: postgresql:///xxxxxx:xxxxxx@xxxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com

docker-compose.ymlの設定を反映させたい

仕様を確認したものの、service毎にDockerfileの作成が求められるのではないかと思われます。copilot svc init実行時に存在するDockerfileが一覧で表示されるため、たくさんのDockerfileを扱っている場合でも選択は苦になりません。

あとがき

既存ツールで、バックグラウンドサービスをいくつも起動させる必要があるものを物は試しとCopilotで動かそうとしているところですが、理解しているのであればcdkで一つ一つ組み立てたほうが確実だろうなとは感じています。

AWS上で小さなアプリケーションをとりあえず動かしてみたい、という場合にはオススメのツールです。docker compose等色々手段はありますが、設定完了時にはアクセス用URLを出力してくれる点において、迷った時に先ず触ってみるツールとして常備しておくとよいかもしれません。