AWS Copilot CLIのススメ

はじめに

今回はAWS Copilot CLI（以下Copilotと呼ぶ）をおすすめしていきたいと思います。
Copilotは、その名の通りCLIでAWSにコンテナアプリケーションを構築するためのツールです。

Copilotを使って作成されたリソースは、ほとんどがymlファイルで管理されているため、簡易的なIaCとしても役立ちます。

既にAWSに深い知識がある方は、Copilotを使わなくてもTerraformやCloudFormationを使って、簡単に同じことができるかもしれません。

しかし、Copilotは最低限のAWSの知識で簡単にインフラ環境を構築することができるため、初心者の方やスタートアップで素早く環境を作りたい、という方にはとてもおすすめです！

対象の読者

• Copilotを使うか迷っている人
• Copilotでどんなことができるのかを知りたい方
• Copilotをうまく使うためのTipsなどを知りたい方

対象外の読者

• Copilotそのものの解説を求めている方
• ハンズオン形式でCopilotの作り方を学びたい方

他のツールとの比較

AWSには、Copilot以外にもささっとインフラを構築できる以下のようなツールがあります。

• Elastic Beanstalk
• App Runner

Beanstalkは、EB CLIを使って、CLIからリソースを作ることはできますが、IaCのような形でリソースを管理することはできません。

AppRunnerは、この中で最も簡単にインフラを構築できるツールですが、カスタマイズ性がかなり低く、まだ本番には早いか？と思い、自分のプロダクトでは導入を見送りました。

Copilotは、ある程度のカスタマイズ性と、IaCのような形でリソースを管理できるという点で、自分にとってはベストなツールでした。

ここはこの記事の本題ではないので、この程度にしておきますが、自分たちのプロダクトに合ったツールを選ぶことはとても大切なので、他のツールもぜひ検討してみてください。

おおまかな流れ

Copilotには独自にAWSのリソースを抽象化した名前を付けており、主に以下の4つを作っていく必要があります。

• Application ... アプリケーション全体を表すリソース。
• Environment ... 開発、ステージング、本番などの環境を表すリソース。
• Service ... BE、FE、Batchなどの実行環境を表すリソース。
• Pipeline ...Environmentごとにデプロイを自動化するためのリソース。

準備

以下の準備が必要になります。

• AWS CLIのインストール
• アクセスキー、シークレットキーの設定
  • ローカルからAWSに接続できる状態にしておいてください

Application

まずは、以下のコマンドを実行してApplicationを作成します。

copilot app init --domain xxx.jp --resource-tags app=xxx

--domainとresource-tagsオプションは任意ですが、おすすめです。
--domainに、事前にRoute53で取得済みのドメインを指定することが可能で、作成する環境が自動的に指定されたドメインに紐づけられます。

resource-tagsを使って、タグを自由につけることができます。
Copilotで作成されるリソースは多岐にわたるため、ここでユニークなタグをつけておくことで、後から検索しやすくなります。

また、--domainや--resource-tagsなどのオプションは、initのタイミングでしか指定できません（こちらのリリースで改善されている可能性あり）

Environment

以下のコマンドを実行して、Environmentを作成します。
そうすると、いくつか質問されるので、回答を進めながら環境を作成していきます。（VPCやサブネットのCIDRを手動で指定したい、既存のVPCやサブネットをインポートするなど様々な手法に対応しています）

copilot env init

# 作成が終わったら
copilot env deploy --name {環境名}

※ 環境は作成しただけではAWS上に反映されないため、必ずデプロイが必要です。

Service

続いて以下のコマンドを実行して、Serviceを作成します。

copilot svc init

Serviceにはいくつかの種類が存在するので、最も要件に適している種類を選ぶ必要があります。

恐らく多くのパターンで以下のどちらかを選ぶことになると思います。

Load Balanced Web Service

• インターネットからアクセス可能な常時起動しているサーバーを作りたい時に選択します。
• （例）Webサーバー、APIサーバー

Backend Service

• インターネットからアクセス不可能な常時起動しているサーバーを作りたい時に選択します。
• （例）バッチサーバー

Serviceを作成した後は、Manifestファイルを使ってカスタマイズすることができます。

私が良く設定する項目へのリンクを貼っておくので、もしよければ参考にしてみてください。

• http-healthcheck

  • ヘルスチェックのパスや条件を変えたい時に使います

• http-alias

  • 公開されるドメインを変えたい時に使います

• image

  • モノレポなどで、Dockerfileの場所やDockerコンテキストが異なる場合に独自の設定をする際に使います。

• cpu, memory

  • CPUやメモリの割り当てを変えたい時に使います。指定できる値は決められているので注意が必要です。

• count

  • 冗長化やスケールアップを設定する際に使います。

• exec

  • copilot svc execでコンテナに入るために、trueにしておきます

• network-connect

  • Service Connectのために、trueにしておきます

• network-vpc-security-groups

  • 独自のセキュリティグループをサービスにアタッチします。例えば、他のRDSなどのリソースにアクセスするためにセキュリティグループをアタッチしないといけないようなケースで役に立ちます。

• variables

  • サービスに環境変数を設定する際に使います。ただし、秘匿情報はこちらを使わないようにしてください。

• secrets

  • サービスに環境変数を設定する際に使います。秘匿情報は必ずこちらを使ってください。

• taskdef-overrides

  • ECSのタスクの定義を上書きするために使います。例えばフォアグラウンドで動くプロセスがないコンテナを動かし続けるために、以下のような設定をします。

- path: ContainerDefinitions[0].PseudoTerminal
  value: true

• environments
  • 環境ごとにmanifestの設定値を変えたい場合に使います。冗長化や環境変数などは、こちらを使って環境ごとにも設定できます。

Addons

ここでAddonsについて紹介少し紹介をしておきます。
こちらは、CopilotのManifestファイルで設定ができない追加のAWSリソースを作成するための仕組みです。

Serviceごとのaddonsだけなく、Environmentごとのaddonsも作成することができます。
また、これらの追加リソースは、ServiceやEnvironmentが削除された時に自動で削除されるようになっているため、手動で作るより圧倒的に管理が楽になります。

RDS、S3、DynamoDBなどのよくある追加リソースは以下のコマンドで作成することができます。

copilot storage init

私は過去にSESをEnvironmentsの追加リソースとして作成したことがありますが、そちらはこのようなコマンドは用意されておらず、自分でCloudFormationを書く必要があるため注意です。

また、Addonsで作成した追加リソースにアクセスするためのIAMロールが自動的にService（正確にはタスク）に設定されることになるため、自らIAMロールを設定する必要はありません。

上記以外にも、例えばセキュリティグループや独自のIAMロールをServiceに与えたい場合は、Addonsの中でそれらのリソースを作成するだけで、自動的にServiceに紐づけられます。

最後に以下のコマンドを実行して、Serviceをデプロイします。

copilot svc deploy

Pipeline

最後に、自動デプロイのためのPipelineを作成します。

もちろん、copilot svc deployコマンドを使って、Github ActionsなどでCDを実現することもできますが、Pipelineを使うことで、より簡単にCDを実現することができます。

Pipelineの作成は以下のコマンドで行います。

copilot pipeline init
git add copilot/ && git commit -m "Adding pipeline artifacts" && git push
copilot pipeline deploy

copilot pipeline initの後に、Serviceと同様に色々と質問されるため、対応していく必要があります。（AWSとGithubリポジトリの接続等もあります）
また、pipelineをデプロイする前に、Serviceのデプロイをしておく必要があるため注意してください。

pipelineを設定した後は、ServiceやEnvironmentのManifestファイルを変更したPRが対象のブランチにマージされたタイミングで、自動的にデプロイされ、反映されるようになります。

しかし、pipelineのManifestファイルやBuildSpecを変更した場合は、copilot pipeline deployを行って明示的に更新する必要があるため注意が必要です。

まとめ

いかがだったでしょうか。
自分がCopilotで環境を作っていて、便利だなと思ったことや困ったことなどをつらつらと書いてみました。

まだまだ柔軟性がないなと感じる部分もありますが、小中規模なプロダクトで独自のカスタマイズがそこまで必要ないのであれば、Copilotはとても有力な選択肢になると思います。

カスタマイズしていくためには、どうしてもCloudFormationを書く必要があるのですが、いきなり全部CloudFormationは難しいかも...と思っている方にとっては、IaCの入門にもなると思います。

ぜひ、Copilotを使って爆速でインフラ環境を構築してみてください！