AWS copilot を用いたECSのデプロイでハマったこと4選

目次

1. 前提条件
2. [ハマりポイント1] デプロイ後にドメインの紐付けができない
3. [ハマりポイント2] 環境ごとにインフラの構成を変えることが難しい
4. [ハマりポイント3] アプリケーションからRDSにコネクションが確立できない
5. [ハマりポイント4] デプロイに失敗するとロールバックの時間が長い
6. まとめ

前提

• バックエンドとフロントエンドは別のALB配下に配置する(別のドメインでデプロイ)
  • そのため、環境ごとにRDSの作成の有無を分岐する必要があった

[ハマりポイント1] デプロイ後にドメインの紐付けができない

とりあえず、httpでデプロイして後でドメインの取得や証明書の配置をしよう、と思うのがエンジニアの性だと思いますが、残念ながらそれはできません(仕様的に)。
既存の証明書の紐付けなどは、環境の初期化時に以下のように行わなければなりません。

copilot env init --import-cert-arns <証明書のarn>

すでに環境を作っている方は、諦めて環境を削除して環境の再構築が必要です。
直感的には、これくらいは環境構築後でもできても良いかなとは思っています

[ハマりポイント2] 環境ごとにインフラの構成を変えることが難しい

はじめに述べておきますと、あくまでインフラの構成を変えるのが難しいだけで、インスタンスのスペックなどは環境ごとに簡単に変えることができます。

インスタンスのスペックを変える場合(copilot/addons/db.yml)

Mappings:
  dbEnvScalingConfigurationMap:
    # 環境別のAurora Serverless v2 clusterのスケーリング設定
    All:
      "DBMinCapacity": 0.5
      "DBMaxCapacity": 8
...[省略]

ServerlessV2ScalingConfiguration:
        MinCapacity:
          !FindInMap [dbEnvScalingConfigurationMap, !Ref Env, DBMinCapacity]
        MaxCapacity:
          !FindInMap [dbEnvScalingConfigurationMap, !Ref Env, DBMaxCapacity]

今回は、バックエンド用の環境にはRDSのインスタンスを作るが、フロントエンド用の環境には作らないという使い分けをしたいので、環境ごとにインフラの構成を変える必要がありました。
直感的には、copilot/environments/<環境名>/addons/hogehoge.yml というファイルを作って、環境ごとにaddonを定義するというのができてほしいところ。しかし、この機能は実装されてなさそう。
各LLMに聞いてみると、「実装済みです！」と元気な回答が返ってきますが、こちら、試してもうまく行きません。
実は、同じようなことを議論しているissueが上がっています
https://github.com/aws/copilot-cli/issues/3112

「環境レベル」のaddonsなら実装されていますが、特定の環境固有のaddonsを定義するのはできなさそうです。

実現するにはどうしたらいいだろうか...

結論、issueの中でも議論されていますが、CloudFormationテンプレートのConditionsを用いて、分岐させるのが良さそうです。
私は、「環境名が"-be"で終わっている場合」のみRDSクラスターを作るという条件をConditionsに記述することで実現しました。

[ハマりポイント3] アプリケーションからRDSにコネクションが確立できない

copilot svc deploy が成功して、アプリケーションからマイグレーションをしようとコマンドを実行したところ、コネクションが確立できずタイムアウト。
よくよくコンソールを探検してみると、RDSのセキュリティグループのインバウンドルールがECSタスクによるアクセスを許可するようになっていませんでした。
便利ツールというからには、これくらい自動でやってほしいところ。
結論としてはデプロイ後に手動でインバウンドルールを作成するのが良いと思います。

参考程度のメモ
addonsのdbのテンプレートにcopilotのサービスのセキュリティグループからのアクセスを許可するように、記載すればいい！と考えますが、この方法では、2回目以降なら問題ないのですが、初回のデプロイがうまく行きません。
なぜなら、copilotのデプロイは、env deploy(環境のデプロイ) → svc deploy(サービスのデプロイ)の手順で行いますが、RDS等のaddonsはenv deploy 時に作成されるものであり、その時にはまだサービスのセキュリティグループは作られておらず参照することができないからです。

[ハマりポイント4] デプロイに失敗するとロールバックの時間が長い

これは、ハマりポイントというより愚痴です（笑）。
リリースが迫る中、試行錯誤をしているという時に、エラーメッセージと共に15分待たされた苦い思い出があります。デフォルトでロールバックしてくれるのは非常に便利ですが、時間が長すぎるので余裕を持ってデプロイのスケジュールは取っておきましょう。

まとめ

結論、AWS copilot はとりあえず動かしたい時には便利ですが、カスタマイズをしようとするとなかなか難しいです。
正確には、「カスタマイズができないことはないが、実現しようとしても正解に辿り着くのには時間がかかる」という感じです。
実際には「プロトタイプをcopilotで作成→安定運用の必要性が出てきたらCDKなどに移行」という形がいいのではないでしょうか。

補足

色々、AWS copilot について書きましたが、AWS についてあまり詳しくないという方にはAWSでのインフラ構築の勉強法としてcopilot を使ってみるというのはおすすめです。
copilotの出力はCloudFormationのテンプレートだったりするので、CloudFormationについての理解が深まりますし、copilotはAWSでのベストプラクティスで構築してくれるので、それらについても学習することができます。