AWS copilot でサーバー構築

AWS copilot

AWS copilot は、webサーバー、バックグラウンドで常時起動するサーバー、定期ジョブ（Cronのような）が、かなり簡単なymlとコマンドだけでセットアップでき、オートスケールにも対応できます。GCPのKubernetesに近いです。
コンテナ内でコマンドを実行し、DBへコマンド実行なども、task コマンドが用意されているため行えます。

$ copilot init
$ copilot env init
$ copilot svc init
$ copilot svc deploy

この程度のコマンドと、Dockerfile があれば、アクセスできるALBのURLが作成されます。

やっていることは、CloudFormation が実行され、リソースが自動で作成される、ビルド＆デプロイが実行されるコマンドが用意されている というだけです。
追加で、RDSやCloudFront、Redisなど使いたいリソースを Terraform や手動で作成することになります。

他サービスと比較すると、

  • GCP の Cloud Run では、常時起動が想定されていない
  • Serverless Framework (AWS)では、常時起動ができない、システムに制限がある
  • AWS の Kubernetes では、ログの出力など所々全自動ではなく面倒
  • GCP の Kubernetes では、セットアップはほぼ自動だが、ビルド・デプロイはコマンド1つになっていない
  • GCP では、CloudFront ほどのカスタマイズ性、動作のわかりやすいCDNがないため、AWSを利用したい
  • AWS Elastic Beanstalk は、Amazon Linux2などOSが変わったときに、設定ファイル書き換えが必要など、OSやElastic Beanstalkの設定変更に依存してしまう

Serverless Framework などで、大抵のものは対応できますが、さらに一歩進んだサーバー構成が必要なときに、どれも手軽さがないと思っていましたが、ちょうどいいツールとなっていました。
Fargate やALBが起動し、特有の制限もなく使えるため、どんなサーバー構成が必要な場合も使えると思います。

しかし、Terraform などで AWSリソースの定義がすんでいて、ビルド、デプロイまでの環境が作れている場合は、特に利用する必要はないツールです。

最初に困ったこと

  • インストール方法の記載に、古いバージョンが指定されているものがいくつかあります。copilot 1.0.0 以前のバージョンは`copilot init`もろくに動かないため、インストールは1.0.0 以降を利用します。
  • `~/.aws/credentials` に profile を記載しただけでは認識されず、`~/.aws/config` に書かなければcopilotコマンドに認識されません。

今後対応されそうだが困っていること

デプロイ後のヘルスチェックに失敗すると、その後デプロイができなくなる。

https://github.com/aws/copilot-cli/issues/1180
デプロイコマンドがなかなか終わらなかったら、手動でタスク定義を修正し、前のリビジョンを指定する、または必要なタスク数を0に（Webサーバーの場合は当然アクセスできなくなる）すればば再度デプロイできる。

docker build コマンドのARGが、環境ごとに切り替えられない

https://github.com/aws/copilot-cli/pull/1059

M1 Mac で deploy ができない

arm64 でimageをビルドすると、サービスが起動できないようです。

必要最小限なIAM Policy の定義をドキュメントに書いてほしい

調査が面倒で、ALLアクセスにする人が多くなってしまうので、教えてほしい。

デプロイ時に保持されるリビジョンが2つのため、ロールバックできなくなってしまう

そもそもロールバックのコマンドはまだないが、手動でリビジョンを戻せばロールバックできる。しかし、リビジョンが2つしか保持されないため、2回デプロイに失敗すると戻せなくなってしまう。

なんとかなるが困っていること

  • コンテナが書き出すログの、datetime_format を指定できないため、cloudwatch logsに、誤った時間で取り込まれてしまう
  • コンテナ起動時の command がyamlで指定できない

気になった点

CloudFormation を使いたくない

CloudFormationは、内部エラーが起きると、復旧には copilot だけではどうにもならなくなるため、使いたくない気持ちになりました。ただ、AWSのツールなので、AWSのサービスを使わなければいけないはずで、そこが問題の1つかもしれません。

pipineという、CodeBuildとCodePipeline を利用した CI/CD が存在するが、CircleCI や Github Actions を使いたい

こちらもAWSのツールのため自社サービスを使わなければいけないという問題だと思います。
Github Actions で独自にビルド、デプロイを用意するのはとても簡単なので、利用されないかもしれません。

追加リソースを定義するアドオン

S3 をアプリからストレージとして使うことが多いため、S3などを定義し、さらにRoleを設定するアドオンがコマンドで追加できます。
今後も定義できるリソースは増えそうで、便利ではありますが、設定ファイルにCloudFormationの定義ファイルが大量に取り込まれ、見苦しいです。Terraformを使って定義するので、特にいらないと思いました。

GCPのKubernetesぐらいの手軽さ＋デプロイも楽というツールだと思いました。
Kubernetesをまだ理解していない人には、より簡単に感じる可能性もあります。

同じコンセプトで、AWSに依存しすぎないないツールが生まれた場合には、使われなくなってしまう気がしますが、現状は存在しないので、このツールを積極的に使っていきたいと思っています。