Amazon ECSのデプロイツール「ecspresso」について調べてみた

こんにちはクラスメソッドのイ・スジェです。

Amazon ECSを運用していると、新しいコンテナイメージをデプロイするために、タスク定義を登録してサービスを更新する場面がよくあります。

AWSマネジメントコンソールから操作することも、AWS CLIでデプロイスクリプトを作成することもできます。しかし、サービスが増えてくると、現在の設定を管理したり、デプロイ状況を確認したりする作業も徐々に複雑になります。

このような場合に検討できるツールがecspressoです。本記事では、ecspressoがどのようなツールなのか、主な機能やほかの管理方法との違いについて紹介します。

ecspressoとは？

ecspressoは、KAYACが公開しているAmazon ECS向けのデプロイツールです。

名前はespressoと同じように発音します。AWSが提供するマネージドサービスではなく、ローカル環境やCI/CDパイプラインで実行するオープンソースのCLIです。

簡単に説明すると、ECSサービスとタスク定義をファイルで管理し、デプロイに必要な一連の操作を一つのコマンドで実行できるツールです。

ecspressoでは、一般的に次の三つのファイルを使用します。

サービス定義とタスク定義はJSON、YAML、またはJsonnetで管理できます。また、環境変数やTerraform State、CloudFormationのOutputなどをテンプレートから参照することも可能です。

主な機能

既存のECSサービスを取り込める

ecspressoは、新しいECS環境を構築するツールというよりも、すでに稼働しているサービスを管理する用途に向いています。

ecspresso initを実行すると、現在のECSサービスとタスク定義を読み取り、ローカルに設定ファイルを生成します。

ecspresso init \
  --region ap-northeast-1 \
  --cluster <cluster-name> \
  --service <service-name> \
  --config ecspresso.yml

AWSマネジメントコンソールやほかのツールで作成したECSサービスをコード管理へ移行したい場合も、比較的簡単に始められます。

自動生成されたファイルはそのまま使用するのではなく、不要な属性が含まれていないか、アカウントIDや機密情報などリポジトリに保存すべきでない値が含まれていないかを確認することをおすすめします。

デプロイ前に差分を確認できる

diffコマンドを使用すると、ローカルに記述したサービス定義およびタスク定義と、現在ECSで使用されている設定との差分を確認できます。

verifyコマンドでは、設定から参照しているAWSリソースや定義を検証できます。

# ECSサービスを変更せずに設定を確認します。
ecspresso diff --config ecspresso.yml
ecspresso verify --config ecspresso.yml

これらのコマンドをCI/CDのデプロイ前のステップで実行すると、実際のデプロイ前に変更内容を確認しやすくなります。

デプロイとロールバックを一つのツールで実行できる

ecspresso deployを実行すると、新しいタスク定義を登録してECSサービスを更新し、サービスが安定した状態になるまで待機します。

デフォルトではローリングアップデートを使用し、ECSネイティブまたはCodeDeployを利用したBlue/Greenデプロイにも対応しています。

# このコマンドは新しいタスク定義を登録し、ECSサービスを実際に変更します。
ecspresso deploy --config ecspresso.yml

デプロイに問題が発生した場合は、ecspresso rollbackで一つ前のタスク定義リビジョンを再適用できます。

このほかにも、サービスのステータス確認、タスク一覧の取得、単発タスクの実行、スケール変更、ECS Execなどの機能を提供しています。

イメージタグをテンプレートで管理する

ecspressoのテンプレート機能を使用すると、CI/CDから渡されたイメージタグをタスク定義へ反映できます。

例えば、タスク定義のイメージを次のように記述します。

{
  "containerDefinitions": [
    {
      "name": "app",
      "image": "<account-id>.dkr.ecr.ap-northeast-1.amazonaws.com/app:{{ must_env `IMAGE_TAG` }}"
    }
  ]
}

デプロイ時には、CI/CDからイメージタグを環境変数として渡します。

export IMAGE_TAG=<immutable-image-tag>
ecspresso deploy --config ecspresso.yml

must_envを使用すると、IMAGE_TAGが設定されていない場合に処理が中断されます。値が空のままデプロイされたり、意図しないデフォルトタグが使用されたりすることを防ぐ場合に便利です。

個人的には、latestのように繰り返し使われるタグよりも、コミットSHAのようにデプロイしたイメージを識別できるタグをおすすめします。どのイメージがデプロイされているのかを確認したり、以前のバージョンへ戻したりする場合にも分かりやすくなります。

ほかの方法とは何が違うのか？

ECSをデプロイする方法には、ecspresso以外にもAWS CLI、Terraform、CloudFormationなどがあります。

最も大きな違いは、管理する範囲です。

AWS CLIでは、register-task-definitionやupdate-serviceなどのコマンドを組み合わせて必要な処理を構成できます。自由度が高い一方で、デプロイ状況の確認や失敗時の処理なども自分で実装する必要があります。

TerraformとCloudFormationでは、ECSだけでなく周辺のAWSリソースも一つのIaC構成として管理できます。インフラ全体の作成、変更、削除を管理することが目的であれば、こちらのほうが適しています。

ecspressoは、VPCやIAMを含むインフラ全体ではなく、ECSサービスとタスク定義のデプロイに重点を置いています。インフラは別のツールで管理し、アプリケーションのデプロイだけをシンプルにしたい場合に検討しやすいツールだと思います。

同じような役割のツールとしてAWS Copilot CLIもありましたが、2026年6月12日にサポートが終了し、公式リポジトリも読み取り専用になりました。新規導入するツールを比較する場合、現時点では新規導入の選択肢として比較しにくく、既存のCopilot環境を運用している場合は移行の観点で確認するのがよいでしょう。

Terraformと組み合わせる場合

ecspressoは、Terraform Stateの値やCloudFormationのOutputをテンプレートから参照できます。そのため、次のように役割を分けることも可能です。

• TerraformまたはCloudFormation：VPC、サブネット、セキュリティグループ、ECSクラスター、IAMロール、ロードバランサー
• ecspresso：ECSサービス、タスク定義、アプリケーションのデプロイ

ただし、Terraformとecspressoが同じECSサービスの設定を同時に管理する場合は注意が必要です。

例えば、ecspressoが新しいタスク定義をデプロイした後もTerraformでtask_definitionの値を管理していると、次回のterraform planでこの変更がドリフトとして検出される可能性があります。

二つのツールを併用する場合は、どのリソースと属性をどちらで管理するのかを先に決め、実際のデプロイ後にterraform planの結果も確認することをおすすめします。

検討事項

ecspressoを導入する前に、次の点を確認しておく必要があります。

• VPC、ECSクラスター、IAMロールなど、インフラ全体を構築するツールではありません。
• CodeDeploy方式のBlue/Greenデプロイを使用する場合は、CodeDeployのアプリケーションとデプロイグループを別途用意する必要があります。
• rollbackは以前のタスク定義を再適用する機能です。データベーススキーマ、外部API、メッセージ形式の変更まで元に戻すものではありません。
• TerraformやCloudFormationと併用する場合は、同じECS設定を重複して管理していないか確認する必要があります。

特にデータベースマイグレーションを含むデプロイでは、アプリケーションのロールバックとデータのロールバックを分けて考える必要があります。ecspressoのロールバックだけで、サービス全体が以前の状態へ戻るわけではありません。

実際に使ってみる

最後に、すでに稼働しているECSサービスをecspressoへ取り込み、コンテナイメージのタグを変更してデプロイしてみます。

今回の検証ではecspresso v2.8.5を使用しました。ECSクラスターとサービスは事前に作成し、AWSの認証も完了している環境で実施しています。

既存のECSサービスを取り込む

変更前にECSコンソールを確認したところ、サービスはタスク定義の最初のリビジョンを使用していました。

次にinitを実行し、現在のECSサービス設定をローカルファイルへ取り込みます。--configには、生成するecspresso設定ファイルのパスを指定します。

ecspresso init \
  --region "$TASK_REGION" \
  --cluster "$CLUSTER_NAME" \
  --service "$SERVICE_NAME" \
  --config ecspresso.yml

実行すると、サービス定義、タスク定義、ecspresso設定ファイルが生成されました。

[INFO] saving service definition [path:ecs-service-def.json]
[INFO] saving task definition [path:ecs-task-def.json]
[INFO] saving config [path:ecspresso.yml]

ecs-service-def.json
ecs-task-def.json
ecspresso.yml

ecspresso.ymlには、対象のリージョン、クラスター、サービス名、二つの定義ファイルのパスが保存されます。実際のコンテナイメージやタスク設定はecs-task-def.json、ネットワークやデプロイ設定はecs-service-def.jsonで管理します。

イメージタグを変更する

今回はアプリケーションの動作を大きく変えずにデプロイの流れを確認するため、Apache HTTP Serverイメージのタグを2.4から具体的なパッチバージョンである2.4.68へ変更しました。

-      "image": "public.ecr.aws/docker/library/httpd:2.4"
+      "image": "public.ecr.aws/docker/library/httpd:2.4.68"

まず、diffを使用して現在ECSに登録されているタスク定義とローカルファイルとの差分を確認します。

ecspresso diff \
  --config ecspresso.yml

続いて、定義とそこから参照しているAWSリソースを検証し、実際には変更せずにデプロイ内容を確認しました。

ecspresso verify \
  --config ecspresso.yml

ecspresso deploy \
  --config ecspresso.yml \
  --dry-run

diff、verify、deploy --dry-runまではECSサービスを変更しません。結果に問題がないことを確認した後、実際のデプロイを実行します。

# このコマンドは新しいタスク定義を登録し、ECSサービスを実際に変更します。
ecspresso deploy \
  --config ecspresso.yml

デプロイが開始されると、ecspressoは新しいタスク定義リビジョンを登録してECSサービスを更新します。その後、新しいタスクが起動し、サービスが安定した状態になるまで待機します。

デプロイ完了後にECSコンソールを確認すると、サービスが新しいタスク定義リビジョンを使用し、実行中のタスクも置き換わっていることを確認できました。

以前のリビジョンへロールバックする

検証が完了した後は、rollbackを実行してECSサービスを以前のタスク定義リビジョンへ戻せます。

# このコマンドはECSサービスが使用するタスク定義を実際に変更します。
ecspresso rollback \
  --config ecspresso.yml

rollbackはECSサービスが使用するタスク定義を以前のリビジョンへ変更しますが、ローカルのecs-task-def.jsonまでは元に戻しません。そのままにすると次回のdiffで差分が表示され、再度deployした際に変更後のイメージが適用される可能性があります。

今回は変更前のイメージタグが分かっているため、ローカルファイルも元の値へ戻しました。

-      "image": "public.ecr.aws/docker/library/httpd:2.4.68"
+      "image": "public.ecr.aws/docker/library/httpd:2.4"

最後にdiffを実行し、ロールバック後のECSサービスとローカル定義が一致していることを確認します。

ecspresso diff \
  --config ecspresso.yml

変更前のファイルを保存しておらず、元の値が分からない場合は、ロールバック後に別のディレクトリでinitを再実行し、現在のECS設定を取り込んでから既存ファイルと比較する方法もあります。同じ場所でそのまま上書きすると、テンプレートやローカルの変更内容も失われる可能性があるため、先に比較することをおすすめします。

実際に使用してみると、既存のECSサービスをファイルへ取り込み、差分を確認してからデプロイするまでの流れを、いくつかのコマンドで進められました。特に、実際のデプロイ前にdiffとdry-runで変更内容を確認できる点は分かりやすいと感じました。

まとめ

ecspressoはECSのインフラ全体を構築するツールというよりも、既存のECSサービスとタスク定義をコードで管理し、デプロイ作業をシンプルにするツールです。

TerraformやCloudFormationでインフラを管理しながらアプリケーションのデプロイだけを分離したい場合や、AWSマネジメントコンソールで運用しているECSサービスをコード管理へ移行したい場合に検討できます。

ECSのデプロイツールを検討している方の参考になれば幸いです。

最後までお読みいただき、ありがとうございました。

参考資料

• KAYAC ecspresso公式リポジトリ
• AWS CLI ecs update-service
• AWS CloudFormation AWS::ECS::Service
• HashiCorp Terraform terraform plan
• AWS Copilot CLI公式リポジトリおよびサポート終了のお知らせ
• Docker Official Image httpd