ECS での Docker コンテナーのデプロイ

読む時間の目安: 12 分

概要

Docker Compose CLI は、Amazon ECS（Amazon Elastic Container Service; ECS）の中で、ネイティブな Docker コマンドの利用を可能にします。 これを使って、クラウドに適したアプリケーションを構築し実行します。

Docker と Amazon ECS の統合により、開発者が Docker Compose CLI を用いる際には、以下のことが可能になります。

  • 1 つの Docker コマンドに対して AWS コンテキストを設定することができます。 これによってローカルコンテキストとクラウドコンテキストを切り替えられるようになり、アプリケーションの実行をすばやく簡単に行うことができます。
  • Compose ファイルを使って、Amazon ECS 上の複数コンテナーアプリケーションの開発を単純化できます。

ECS 統合アーキテクチャー、Compose 機能一覧、ECS 統合の Compose 利用例 も参照してください。

前提条件

Docker コンテナーを ECS にデプロイするには、以下の条件を満たしていることが必要です。

  1. Docker Desktop 最新版をダウンロードしインストールしていることが必要です。

    あるいは Docker Compose CLI for Linux をインストールしていることが必要です。

  2. AWS アカウントを持っていることが必要です。

Docker は、単にローカルのマルチコンテナーを実行するだけのものではなくなります。 docker compose up により Compose ファイルを使って Amazon ECS 上の Docker コンテナーをシームレスにデプロイできます。 以下の節では Amazon ECS 上において Docker コンテナーをデプロイする手順を説明します。

ECS 上でのアプリケーション実行

前提条件

AWS uses a fine-grained permission model, with specific role for each resource type and operation.

To ensure that Docker ECS integration is allowed to manage resources for your Compose application, you have to ensure your AWS credentials grant access to following AWS IAM permissions:

  • application-autoscaling:*
  • cloudformation:*
  • ec2:AuthorizeSecurityGroupIngress
  • ec2:CreateSecurityGroup
  • ec2:CreateTags
  • ec2:DeleteSecurityGroup
  • ec2:DescribeRouteTables
  • ec2:DescribeSecurityGroups
  • ec2:DescribeSubnets
  • ec2:DescribeVpcs
  • ec2:RevokeSecurityGroupIngress
  • ecs:CreateCluster
  • ecs:CreateService
  • ecs:DeleteCluster
  • ecs:DeleteService
  • ecs:DeregisterTaskDefinition
  • ecs:DescribeClusters
  • ecs:DescribeServices
  • ecs:DescribeTasks
  • ecs:ListAccountSettings
  • ecs:ListTasks
  • ecs:RegisterTaskDefinition
  • ecs:UpdateService
  • elasticloadbalancing:*
  • iam:AttachRolePolicy
  • iam:CreateRole
  • iam:DeleteRole
  • iam:DetachRolePolicy
  • iam:PassRole
  • logs:CreateLogGroup
  • logs:DeleteLogGroup
  • logs:DescribeLogGroups
  • logs:FilterLogEvents
  • route53:CreateHostedZone
  • route53:DeleteHostedZone
  • route53:GetHealthCheck
  • route53:GetHostedZone
  • route53:ListHostedZonesByName
  • servicediscovery:*

GPU support, which relies on EC2 instances to run containers with attached GPU devices, require a few additional permissions:

  • ec2:DescribeVpcs
  • autoscaling:*
  • iam:CreateInstanceProfile
  • iam:AddRoleToInstanceProfile
  • iam:RemoveRoleFromInstanceProfile
  • iam:DeleteInstanceProfile

AWS コンテキストの生成

docker context create ecs myecscontext コマンドを実行して AWS コンテキストを生成します。 すでに AWS CLI をインストールし設定を行っているのであれば、このセットアップコマンドにより、既存の AWS プロファイルを選んで Amazon への接続を行います。 これがまだできていない場合は、AWS access key ID and a secret access key を通じて、新たなプロファイルを生成します。 Finally, you can configure your ECS context to retrieve AWS credentials by AWS_* environment variables, which is a common way to integrate with third-party tools and single-sign-on providers.

? Create a Docker context using:  [Use arrows to move, type to filter]
  An existing AWS profile
  AWS secret and token credentials
> AWS environment variables

AWS コンテキストを生成したら、docker context ls コマンドを実行して Docker コンテキストの一覧を表示します。

NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT               KUBERNETES ENDPOINT   ORCHESTRATOR
myecscontext        ecs                 credentials read from environment
default *           moby                Current DOCKER_HOST based configuration   unix:///var/run/docker.sock                         swarm

Compose アプリケーションの実行

Compose ファイルに定義したマルチコンテナーによるアプリケーションを、Amazon ECS に対してデプロイし管理するためには、docker compose コマンドを実行します。 これを行うためには以下のことが必要です。

  • AWS コンテキストを利用していることが必要です。 これはコマンド実行時に--context myecscontextフラグを指定するか、あるいはカレントなコンテキストを設定するコマンドdocker context use myecscontextを実行します。

  • docker compose upとdocker compose downを実行して、Compose アプリケーションの開始、停止ができることが必要です。

    デフォルトにおいてdocker compose upは、カレントフォルダーのcompose.yamlファイルまたはdocker-compose.yamlファイルを利用します。 --workdir フラグを使ってワーキングディレクトリを指定するか、あるいは Compose ファイルを直接するdocker compose --file mycomposefile.yaml upのような実行方法も可能です。

    Compose アプリケーションのデプロイの際に--project-nameフラグを使って、アプリケーション名を指定することもできます。 アプリケーション名の指定がなかった場合は、ワーキングディレクトリから名前が定められます。

Docker ECS integration converts the Compose application model into a set of AWS resources, described as a CloudFormation template. The actual mapping is described in technical documentation. You can review the generated template using docker compose convert command, and follow CloudFormation applying this model within AWS web console when you run docker compose up, in addition to CloudFormation events being displayed in your terminal.

  • Amazon ECS 上の Compose アプリケーションに対して生成されたサービスの情報およびその状態を確認するにはdocker compose psコマンドを実行します。

  • Compose アプリケーションを構成するコンテナーに対しては、コマンドdocker compose logsを実行してそれぞれのログを確認できます。

Compose 機能一覧 も参照してください。

ローリングアップデート

本番環境の実行を妨げることなくアプリケーションのアップデートを行うには、更新された Compose プロジェクト上においてdocker compose upを実行するだけです。 ECS サービスはローリングアップデート設定を含めて生成されます。 Compose ファイルを修正した上でdocker compose upを実行すると、その修正に応じてアップデートが行われ、必要なサービスは置き換えられます。 この置き換え処理は、サービスの deploy.update_config 設定によって定められるローリングアップデート設定に従います。

AWS ECS ではパーセントベースモデル（percent-based model）を採用して、ローリングアップデート時に起動または停止するコンテナー数を定義しています。 Docker Compose CLI では項目prallelismまたはreplicasに従って、ローリングアップデート設定を算出しています。 ローリングアップデートの設定を、項目x-aws-min_percentやx-aws-max_percentを使って設定したい場合があります。 x-aws-min_percentはサービスに対して、起動させるコンテナーの最小パーセントを設定します。 x-aws-max_percentは、それまでのバージョンのコンテナーを削除する前に、追加で起動するコンテナーの最大パーセントを設定します。

デフォルトにおいて ECS のローリングアップデートは、コンテナー数の 2 倍（200%）の数だけ起動されるように設定されます。 またアップデート時にコンテナー停止を行う程度は 100 % として設定されます。

アプリケーションログの確認

Docker Compose CLI では、コンテナーに対して AWS CloudWatch ログサービスを設定します。 Compose アプリケーションログの確認は、デフォルトではローカルデプロイを確認することと同様に行うことができます。

# アプリケーションログをカレントなワーキングディレクトリに取り出します。
$ docker compose logs

# Compose プロジェクト名を指定します。
$ docker compose --project-name PROJECT logs

# Compose ファイルを指定します。
$ docker compose --file /path/to/docker-compose.yaml logs

アプリケーションにおいて、ロググループdocker-compose/<アプリケーション名>が生成され、またアプリケーション内の各サービスとコンテナーにおいては、ログストリーム<アプリケーション名>/<サービス名>/<コンテナーID>が生成されます。

AWS CloudWatch ログに対しては Compose ファイル内の拡張項目x-aws-logs_retentionを使って、イベントの保存日数を調整することができます。 デフォルトは無期限に保存します。

標準的な Compose ファイルの項目logging.driver_optsを使い、コンテナーに対してawslogsパラメーターを指定することもできます。 利用可能なログドライバーオプションの詳細は AWS ドキュメント を参照してください。

プライベートな Docker イメージ

Docker Compose CLI では自動的に認証が設定されます。 したがって Amazon ECR レジストリにあるプライベートイメージは、同じ AWS アカウントを使ってプルすることができます。 一方 Docker Hub も含め、別のレジストリからプライベートイメージをプルするには、AWS Secrets Manager service 上にユーザー名とパスワード（あるいはユーザー名とトークン）を生成する必要があります。

Docker Compose CLI では、便利なコマンドとしてdocker secretが提供されています。 したがって AWS CLI をインストールしていなくても、AWS SMS において生成した機密情報を管理することができます。

First, create a token.json file to define your DockerHub username and access token.

For instructions on how to generate access tokens, see Managing access tokens.

{
  "username":"DockerHubUserName",
  "password":"DockerHubAccessToken"
}

You can then create a secret from this file using docker secret:

$ docker secret create dockerhubAccessToken token.json
arn:aws:secretsmanager:eu-west-3:12345:secret:DockerHubAccessToken

この ARN を生成したら Compose ファイル内において、カスタム拡張 x-aws-pull_credentials を利用して、そのサービスに対する Docker イメージ URI を指定することができます。

services:
  worker:
    image: mycompany/privateimage
    x-aws-pull_credentials: "arn:aws:secretsmanager:eu-west-3:12345:secret:DockerHubAccessToken"

メモ

Compose ファイルのバージョンを 3.8 またはそれ以降に指定すると、この Compose ファイルをそのまま、docker-compose を使ってローカル開発環境向けに利用することができます。 その場合、カスタム ECS 拡張は無視されます。

サービスの検出

日本語訳情報

当節の内容はよく理解できなかったため、訳出に自信がありません。 内容がおわかりの方はご教示よろしくお願いします。

サービス間の通信は、デフォルトで透過的に実装されています。 したがって Compose アプリケーションのデプロイは、複数接続されたサービスに対しても、Compose ファイルをローカル向け、ECS デプロイ向けに切り替えずに行うことができます。 個々のサービスは、それぞれの（メモリや CPU に対する）制約やレプリカに関するルールに従って動作します。

サービス名

アプリケーションデプロイを行うサービスは、Docker Compose CLI により AWS Cloud Map 上に自動登録されます。 これは <サービス>.<composeプロジェクト名>.local という形の完全修飾ドメイン名として表わされています。

サービスが、依存するサービスを引き出す際には、Compose サービス名（docker-compose を使ってローカルにデプロイする際にも用いられる）、またはこの完全修飾ドメイン名が利用されます。

メモ

VPC 内においてパブリック DNS 名を有効にしていない限り、完全修飾サービス名ではなく、短いサービス名が名前解決されます。

依存サービスの起動時間と DNS 名前解決

Compose ファイルがデプロイされると ECS 上においてサービスが同タイミングでスケジューリングされます。 AWS Cloud Map では、サービスドメイン名を解決できるようにするため、DNS サービスの初期遅延処理を行っています。 したがってアプリケーションコードには、その遅延への対応が必要になります。 つまり依存サービスが準備状態となるのを待つか、Docker イメージへエントリーポイントとして、ウェイトを行うスクリプトを追加するなどの対応を行います。 このことは 起動順の制御 において説明しています。 なお Compose アプリケーション内の依存サービスに対しても、docker-compose によりローカルにデプロイする際にもこれが必要です。 ただし遅延は普通は短いものです。 明らかな問題が発生するとすれば ECS へのデプロイ時であり、サービスがその依存サービスの起動を待たずに実行されてしまった場合です。

それとは別に Compose ファイルにおける depends_on 機能を利用することができます。 これを利用すると依存するサービスがまず生成されることになり、アプリケーションのデプロイは生成開始前から稼動するまで待機します。

サービスの分離

サービス間の通信は Security Groups ルールによって実現されています。 サービス間では共通の Compose ファイル「network」が共有され、Compose サービス名を使って互いに通信を行います。

ボリューム

ECS 統合では Amazon Elastic File System (Amazon EFS) をベースとしたボリューム管理をサポートしています。 ECS 統合において Compose ファイルにvolumeを宣言する際には、CloudFormation テンプレート内に EFS ファイルシステムの生成を定義します。 Retain（維持）ポリシーを利用すれば、アプリケーションのシャットダウン時にデータが削除されることはありません。 同一のアプリケーション（同一のプロジェクト名）が再度デプロイされると、ファイルシステムが再度アタッチされて、それまで開発者が行っていた docker-compose による作業を再開できます。

ボリュームを利用した基本的な Compose サービスは、以下のように宣言します。

services:
  nginx:
    image: nginx
    volumes:
      - mydata:/some/container/path
volumes:
  mydata:

With no specific volume options, the volume still must be declared in the volumessection for the compose file to be valid (in the above example the empty mydata: entry) 必要であれば、ファイルシステムの初期状態はdriver-optsを用いて変更することができます。

volumes:
  my-data:
    driver_opts:
      # Filesystem configuration
      backup_policy: ENABLED
      lifecycle_policy: AFTER_14_DAYS
      performance_mode: maxIO
      throughput_mode: provisioned
      provisioned_throughput: 1

AWS 上においてdocker compose upを実行して生成されるファイルシステムは、docker volume lsによって一覧確認ができます。 またdocker volume rm <ファイルシステムID>によって削除することができます。

EFS 上にすでにデータを保存している場合や、別の Compose スタックによって生成されたファイルシステムを利用したい場合には、既存のファイルシステムを利用することもできます。

volumes:
  my-data:
    external: true
    name: fs-123abcd

コンテナーからボリュームにアクセスする際には、POSIX ユーザー ID のパーミッションに関する問題が発生する可能性があります。 Docker イメージにおいては、コンテナー内で稼動するプロセスに対して、任意のユーザー ID およびグループ ID を定義しているからです。 ただしuid:gidが同一であれば、ファイルシステム上での POSIX パーミッションに合致していなければなりません。 このような衝突を回避するためには、ボリュームにアクセスする際に利用するuidとgidを設定します。

volumes:
  my-data:
    driver_opts:
      # Access point configuration
      uid: 0
      gid: 0

Secrets

Docker モデルを使って ECS サービスに Secret 情報を受け渡すことにより、/run/secrets配下にあるファイルを機密データとして結びつけることができます。 Compose ファイルに Secret 情報を宣言している場合、ECS 上へのアプリケーションのデプロイにあたって、デプロイの一部としてその情報が生成されます。 Compose ファイル内にて既存の Secret 情報をexternal: trueとして参照している場合、Secret 名として ECS Secrets Manager の 完全リソース名を使うことができます。

services:
  webapp:
    image: ...
    secrets:
      - foo

secrets:
  foo:
    name: "arn:aws:secretsmanager:eu-west-3:1234:secret:foo-ABC123"
    external: true

Secret はサービス実行時には、/run/secrets/foo というプレーンなテキストファイルとしてアクセスできます。

AWS Secrets マネージャーにおいて機密情報を保存する際には、（Docker の Secret と同じように）プレーンテキストとして保存する方法と、階層化した JSON ドキュメントとして保存する方法があります。 Docker Compose CLI にて後者の方法を利用する場合には、カスタム項目x-aws-keysを利用して、サービスコンテナー内の Secret として、JSON ドキュメント内のどの項目を結びつけるかを定義します。

services:
  webapp:
    image: ...
    secrets:
      - foo

secrets:
  foo:
    name: "arn:aws:secretsmanager:eu-west-3:1234:secret:foo-ABC123"
    x-aws-keys:
      - "bar"

このようにするとキー bar に対する機密データは、サービスの実行時に /run/secrets/foo/bar というプレーンなテキストファイルとしてアクセスできます。 特別な値として * を用いると、コンテナー内のキーすべてを得ることができます。

自動スケーリング

サービスをスケーリングするための固定的な（自動スケーリングではない）情報は、普通に Compose ファイルの文法として指定することができます。

services:
  foo:
    deploy:
      replicas: 3

Compose ファイルモデルでは、自動スケーリングの条件を定める属性定義はありません。 したがってカスタム拡張機能x-aws-autoscalingを利用して自動スケーリングの範囲を定義することになります。 ターゲットメトリックの定義において、リソース使用率として表現される CPU やメモリを定めることと同様です。

services:
  foo:
    deploy:
      x-aws-autoscaling:
        min: 1
        max: 10 #required
        cpu: 75
        # mem: - mutualy exlusive with cpu

IAM ロール

ECS タスクは、AWS 管理ポリシーAmazonECSTaskExecutionRolePolicy と AmazonEC2ContainerRegistryReadOnly へのアクセスが可能な、専用の IAM ロールによって実行されます。 さらにサービスが Secret を利用している場合、IAM ロールは追加の権限によって AWS Secret マネージャーから Secret の読み込みと復号化を行います。

サービスの実行にあたって管理ポリシーを追加で利用するには、サービス定義の内部においてx-aws-policiesを用います。

services:
  foo:
    x-aws-policies:
      - "arn:aws:iam::aws:policy/AmazonS3FullAccess"

また独自に IAM ポリシードキュメント を記述して、ECS サービスに適用する IAM ロールを調整することができます。 そしてサービス定義内にx-aws-roleを用いることで、YAML 書式のポリシードキュメントを受け渡すことができます。

services:
  foo:
    x-aws-role:
      Version: "2012-10-17"
      Statement:
        - Effect: "Allow"
          Action:
            - "some_aws_service"
          Resource:
            - "*"

CloudFormation テンプレートの調整

Docker Compose CLI では Amazon CloudFormation を活用して、アプリケーションのデプロイ管理を行っています。 生成済みのリソースをより的確に制御するには、docker compose convert を使い、Compose ファイルから CloudFormation スタックファイルを生成します。 スタックファイルを生成すると、そこに定義されたリソースの確認や、必要に応じたテンプレートのカスタマイズ、AWS CLI や AWS ウェブコンソールからのテンプレートの適用を行うことができます。

Once you have identified the changes required to your CloudFormation template, you can include overlays in your Compose file that will be automatically applied on compose up. An overlay is a yaml object that uses the same CloudFormation template data structure as the one generated by ECS integration, but only contains attributes to be updated or added. It will be merged with the generated template before being applied on the AWS infrastructure.

Adjusting Load Balancer http HealthCheck configuration

While ECS cluster uses the HealthCheck command on container to get service health, Application Load Balancers define their own URL-based HealthCheck mechanism so traffic gets routed. As the Compose model does not offer such an abstraction (yet), the default one is applied, which queries your service under / expecting HTTP status code 200.

You can tweak this behavior using a cloudformation overlay by following the AWS CloudFormation User Guide for configuration reference:

services:
  webapp:
    image: acme/webapp
    ports:
      - "80:80"

x-aws-cloudformation:
  Resources:
    WebappTCP80TargetGroup:
      Properties:
        HealthCheckPath: /health
        Matcher:
          HttpCode: 200-499

Setting SSL termination by Load Balancer

You can use Application Load Balancer to handle the SSL termination for HTTPS services, so that your code, which ran inside a container, doesn’t have to. This is currently not supported by the ECS integration due to the lack of an equivalent abstraction in the Compose specification. However, you can rely on overlays to enable this feature on generated Listeners configuration:

services:
  webapp:
    image: acme/webapp
    ports:
      - "80:80"

x-aws-cloudformation:
  Resources:
    WebappTCP80Listener:
      Properties:
        Certificates:
          - CertificateArn: "arn:aws:acm:certificate/123abc"
        Protocol: HTTPS
        Port: 443

既存の AWS ネットワークリソースの利用

Docker Compose CLI では、Compose アプリケーションに対して、デフォルトで以下のものを生成します。 1 つは Compose アプリケーション用の ECS クラスターです。 もう 1 つはネットワークごとの SecurityGroup です。 これは AWS でのデフォルト VPC 上において、Compose ファイルによって定義されるネットワークごとのものです。 そしてサービスのトラフィックをルーティングする LoadBlancer です。

以下のような基本的な Compose ファイルを使えば Docker Compose CLI が、ロードバランサーがトラフィックを公開ポート 80 に振り分けるような ECS 構成を自動的に生成してくれます。

services:
  nginx:
    image: nginx
    ports:
      - "80:80"

AWS アカウントに、そのようなリソースを生成する パーミッション が与えられていない場合、あるいは独自にこれらを管理したい場合は、以下のカスタム Compose 拡張機能を利用することができます。

  • Compose ファイルの最上位項目としてx-aws-clusterを利用します。 これは Compose アプリケーションのデプロイ時に利用する ECS クラスターの ID を設定するものです。 これがない場合、クラスターは Compose プロジェクトに対して生成されます。

  • Compose ファイルの最上位項目としてx-aws-vpcを利用します。 これは Compose アプリケーションのデプロイ時に利用する VPC の ARN を設定します。

  • Compose ファイルの最上位項目として x-aws-loadbalancer を利用します。 これは既存の LoadBalancer の ARN を設定します。

The latter can be used for those who want to customize application exposure, typically to use an existing domain name for your application:

  1. Use the AWS web console or CLI to get your VPC and Subnets IDs. You can retrieve the default VPC ID and attached subnets using this AWS CLI commands:

     ```console
 $ aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId'
    
 "vpc-123456"
 $ aws ec2 describe-subnets --filters Name=vpc-id,Values=vpc-123456 --query 'Subnets[*].SubnetId'
    
 [
     "subnet-1234abcd",
     "subnet-6789ef00",
 ]
 ```

  2. Use the AWS CLI to create your load balancer. The AWS Web Console can also be used but will require adding at least one listener, which we don’t need here.

     ```console
 $ aws elbv2 create-load-balancer --name myloadbalancer --type application --subnets "subnet-1234abcd" "subnet-6789ef00"
    
 {
     "LoadBalancers": [
         {
             "IpAddressType": "ipv4",
             "VpcId": "vpc-123456",
             "LoadBalancerArn": "arn:aws:elasticloadbalancing:us-east-1:1234567890:loadbalancer/app/myloadbalancer/123abcd456",
             "DNSName": "myloadbalancer-123456.us-east-1.elb.amazonaws.com",
 <...>
 ```

  3. To assign your application an existing domain name, you can configure your DNS with a CNAME entry pointing to just-created loadbalancer’s DNSName reported as you created the loadbalancer.

  4. Use Loadbalancer ARN to set x-aws-loadbalancer in your compose file, and deploy your application using docker compose up command.

Please note Docker ECS integration won’t be aware of this domain name, so docker compose ps command will report URLs with loadbalancer DNSName, not your own domain.

Docker Compose CLI 向けの Compose ファイルにおいて、ネットワーク定義内にexternal: trueを記述することもできます。 これによってセキュリティグループを生成 しない ようにします。 そしてサービス間のネットワーク接続を実現するために、利用したい既存の SecurityGroup における名前と ID を設定します。

networks:
  back_tier:
    external: true
    name: "sg-1234acbd"

ローカルシミュレーション

ECS 上にアプリケーションをデプロイする際に、追加の AWS サービスを用いたい場合があります。 そのような場合には、コード内に AWS SDK を埋め込んで、実行時に API 資格情報を取り出すことが必要になります。 AWS では資格情報を取得するメカニズムが用意されていて、SDK を使って完全実装されています。 そして固定 IP アドレス上のメタデータサービスにアクセスすることで、これを実現しています。

ただこの手法を採用してしまうと、ローカル環境においてテストやデバッグ目的でアプリケーションを実行することが困難になります。 そこでコンテキストを生成する際のオプションを導入しています。 そのオプションではecs-localコンテキストを設定して、ローカルマシンと AWS クラウドプロバイダー間でのアプリケーションの可搬性を確保しています。

$ docker context create ecs --local-simulation ecsLocal
Successfully created ecs-local context "ecsLocal"

ローカルシミュレーションコンテキストを選んだ場合、docker compose upコマンドを実行しても、アプリケーションは ECS 上にデプロイされません。 したがってアプリケーションはローカルでの実行となり、Compose アプリケーションは ECS local endpoints を用いるように、自動的に調整されます。 このことから、アプリケーションコード内にて利用する AWS SDK は、「AWS メタデータ API」としてローカルの一時的なコンテナーにアクセスし、ローカルの設定ファイル.aws/credentialsから資格情報を取得することになります。

Linux における Docker Compose CLI のインストール

Docker Compose CLI は、ECS 上のコンテナー実行と管理をサポートします。

インストールの前提条件

インストールスクリプト

インストールスクリプトを使えば、新たな CLI をインストールできます。

$ curl -L https://raw.githubusercontent.com/docker/compose-cli/main/scripts/install/install_linux.sh | sh

FAQ

this tool requires the "new ARN resource ID format" というエラーはどんな意味？

このエラーメッセージは、利用アカウントに対しては ECS 向けの新たな ARN リソース ID フォーマットが必要であることを示しています。 詳しくは Migrating your Amazon ECS deployment to the new ARN and resource ID format を参照してください。

フィードバック

Docker Compose CLI を利用していただき、ありがとうございます。 みなさんからのフィードバックが大変重要です。 フィードバックをいただくには、Github レポジトリ Compose CLI に issue をあげてください。

Docker, AWS, ECS, Integration, context, Compose, cli, deploy, containers, cloud