Amazon Web Services ブログ

Docker Compose を使用した Docker Swarm から Amazon ECS への移行

この記事は Migrating from Docker Swarm to Amazon ECS with Docker Compose を翻訳したものです。

Introduction

Docker Compose for Amazon Elastic Container Services (Amazon ECS) を活用することで、Compose ファイルで定義されたアプリケーションを Amazon ECS にデプロイすることができます。Compose はインフラストラクチャやクラウドサービスに依存しないオープンな仕様であり、開発者は開発時に一度アプリケーションを定義するだけで、本番環境に至るまで同じ定義をワークロード上で使用することができます。Compose は何年も前から存在しており、すでに多くの組織がワークロードをローカルマシンや Docker Swarm にデプロイするために活用しています。

この記事では、Docker Swarm から Amazon ECS への移行ツールとして Compose を使用することで、Compose の柔軟性を示します。これを行うために、既存の Compose ファイルを使用して Docker Swarm にアプリケーションをデプロイしていく予定です。次に、Docker Compose for Amazon ECS を活用することで、同じ Compose ファイルを使用して、Docker CLI のデプロイメントコンテキストを変更し、同じワークロードを Amazon ECS にデプロイします。

Background

この部分はオプションです

組織の成長によってデプロイするコンテナの数が増えるにつれ、これらのワークロードを管理することも複雑さも増えます。多くの場合、コンテナ化されたワークロードを追跡したり、リモートマシンにコンテナをデプロイしたりするために、手動または自作のツールが構築されています。このような複雑さを管理するために、スケジューリング、サービスディスカバリ、高可用性を組み込んだコンテナオーケストレーションツールが次の論理的なステップとなりました。Kubernetes、Docker Swarm、Amazon ECS は、サーバー群全体のコンテナのスケジューリングを行う主要なオーケストレーターとして登場しました。

各コンテナオーケストレーターは、独自の設計を持っています。スケジュールする内容 (コンテナ、タスク、Pod) や、それらのワークロードの通信方法 (オーバーレイネットワーク、ネットワークアドレス変換、マイクロセグメンテーション)、ワークロードの定義方法 (Helm Charts、マニフェストファイル、タスク定義、スタックファイルなど) についてです。このような各コンテナオーケストレーターの違いにより、コンテナイメージの標準規格に加えて、ワークロードの定義を各コンテナオーケストレーターで行う必要があるため、意見が別れます。

2020 年 4 月、Docker は Compose Specification を発表しました。Compose Specification は人気のある Docker Compose のツールから独立した仕様です。「Compose Specification は、クラウドおよびプラットフォームに依存しないコンテナベースのアプリケーションを定義するための開発者に焦点を当てた標準です[1]」。コンテナプラットフォームからの抽象化を提供するという Compose Specification の目標の 1 つにより、Compose で定義されたアプリケーションは、コンテナイメージに関連付けられることが多いコンテナオーケストレーター間のポータビリティを実現できます。

また、2020 年半ばに Docker と AWS は、Compose Specification で定義されたアプリケーションを Docker Compose for Amazon ECS を通じて Amazon ECS にデプロイできることを共同発表しました。以前の AWS ブログでは、Amazon ECS for Docker Compose についての説明と、Docker Compose と Amazon ECS を利用したソフトウェアデリバリの自動化を紹介しました。本記事では、Amazon ECS for Docker Compose についてもう一度見ていきますが、今回は移行と移植性の観点から、特に Docker Swarm から Amazon ECS への移行について説明します。

コンテナオーケストレーターである Docker Swarm のワークロードは、通常、Compose ファイル、特に Docker Compose の v3 ファイル形式で定義されます。v3 の Docker Compose ファイルは、docker stack deploy コマンドを使用して Docker Swarm クラスターにデプロイされます。このコマンドは、Docker Swarm スタックを作成し、その Compose ファイル内で定義されたすべてのサービスを論理的にグループ化し、それらを Docker Swarm クラスターにデプロイします。

最近発表された Compose Specification は、Compose ファイルの v2 と v3 両方のスキーマを単一の Compose スキーマにマージします。Docker Swarm の Compose v3 で定義されたワークロードは、Compose Specification に準拠している必要があります。そのため、ワークロードの定義ファイルへ最小限の変更を加えるか、もしくはまったく変更を行わず、Docker Compose CLI を介して Amazon ECS にデプロイが可能です。

Docker Swarm に投票アプリをデプロイ

移行元は Docker Swarm となるので、最初の手順としてサンプルアプリケーションを Docker Swarm クラスターにデプロイします。このウォークスルーで Docker Swarm から Amazon ECS に移行されるワークロードは、Docker でのお馴染みの投票アプリ (voting app) です。

ワークロードを Docker Swarm から Amazon ECS に移行する場合、多数の EC2 インスタンス (またはその他のインフラストラクチャ) にデプロイされた本番環境の Docker Swarm で実行されている可能性があります。しかし、この記事では本番環境のエンドポイントを模倣するために、シングルノードの Docker Swarm クラスターをデプロイします。

シングルノードの Docker Swarm クラスターを作成するために必要な前提条件は、単一の Docker Engine にアクセスできることだけです。Docker Swarm は Docker Engine に組み込まれているため、Docker Desktop を搭載した Mac OS や Windows 10 のワークステーション、または Docker Engine を搭載した Linux マシンがあればシングルノードの Docker Swarm クラスターの機能をすべて動作させることができます。

1) Docker Swarm クラスターの作成

# Docker Swarm クラスターの初期化
$ docker swarm init
Swarm initialized: current node (p6jrlxky3iksu81njsjj69xed) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-5qjrn0chobljke6ml1o9qri8cj1q5qcq3bydtlwndm2hdqxff5-61z08dqaye1axgwbvu40hngxv 192.168.65.3:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

# Docker Swarm が正しく作成されたことを確認
$ docker node list
ID                            HOSTNAME         STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
p6jrlxky3iksu81njsjj69xed *   docker-desktop   Ready     Active         Leader           20.10.6

2) サンプルアプリケーションをクローン

サンプルアプリケーションを Docker Swarm クラスターにデプロイするには、Compose v3 ファイルを使用します。1 つはアップストリームのリポジトリに作成済みで、サンプルアプリケーションのソースコードと一緒に保存されています。アップストリームのリポジトリは、Docker エコシステム内の様々なデモに使用されています。混乱を避けるために、リポジトリ内にある Compose ファイルの 1 つを除いてすべて削除することにします。

# リポジトリのクローン
$ git clone https://github.com/dockersamples/example-voting-app
Cloning into 'example-voting-app'..

# クローンしたリポジトリへの移動
$ cd example-voting-app

# 既存のワークロードの定義をすべて削除
$ rm ./docker-compose*
$ rm ./*/docker-compose*
$ rm ./docker-stack-windows*
$ rm ./docker-stack.yml

# ディレクトリのルートに Compose ファイルが 1 つのみであることを確認
$ find . -name 'docker-compose*' -o -name 'docker-stack*'
./docker-stack-simple.yml

# 残りの Compose ファイルをリネーム
$ mv docker-stack-simple.yml docker-compose.yml

3) コンテナイメージのビルド

ワークロードをデプロイする前に、投票アプリの各マイクロサービスのコンテナイメージをビルドし、Amazon Elastic Container Registry (Amazon ECR) にプッシュする必要があります。

以下のコマンドは AWS CLI v2 がローカルシステムにインストール、設定されていることを前提としています。また、ECR リポジトリを作成する権限を持つ IAM ユーザーも設定されていることを前提としています。これらの前提条件が満たされていない場合は、このドキュメントに従って AWS CLI v2 をインストールし、こちらのガイドを参照して設定してください。

# ECR リポジトリの新規作成
$ export AWS_REGION="eu-west-1"
$ export ECR_URI=$(aws ecr create-repository \
  --repository-name voting-app \
  --region $AWS_REGION \
  --query 'repository.repositoryUri' \
  --output text)

# ECR へログイン
$ aws ecr get-login-password --region $AWS_REGION| docker login --username AWS --password-stdin $ECR_URI

# コンテナイメージのビルドとプッシュ
for SERVICE in vote result worker;
do
  docker image build -t $ECR_URI:$SERVICE $SERVICE/
  docker image push $ECR_URI:$SERVICE
done

# すべてのコンテナイメージが ECR リポジトリに正常にプッシュされていることを確認
$ aws ecr list-images --repository-name voting-app | jq '.imageIds | .[].imageTag'
"vote"
"worker"
"result"

既存の Compose ファイルを更新して、Amazon ECR にプッシュされたコンテナイメージを参照するようにする必要があります。Docker Compose は環境変数をサポートしているため、旧バージョンのコンテナイメージを参照しているアップストリームのリポジトリの環境変数を置き換えます。

# Linux ユーザー向け
$ sed -i 's#dockersamples/examplevotingapp_worker#${ECR_URI}:worker#g' docker-compose.yml
$ sed -i 's#dockersamples/examplevotingapp_result:before#${ECR_URI}:result#g' docker-compose.yml
$ sed -i 's#dockersamples/examplevotingapp_vote:before#${ECR_URI}:vote#g' docker-compose.yml

# MacOS ユーザー向け
$ sed -i "" 's#dockersamples/examplevotingapp_worker#${ECR_URI}:worker#g' docker-compose.yml
$ sed -i "" 's#dockersamples/examplevotingapp_result:before#${ECR_URI}:result#g' docker-compose.yml
$ sed -i "" 's#dockersamples/examplevotingapp_vote:before#${ECR_URI}:vote#g' docker-compose.yml

これで、投票アプリをローカルの Docker Swarm クラスターにデプロイすることができます。

$ docker stack deploy \
  --with-registry-auth \
  --compose-file docker-compose.yml \
  voting-app
  
Creating network voting-app_backend
Creating network voting-app_frontend
Creating service voting-app_db
Creating service voting-app_vote
Creating service voting-app_result
Creating service voting-app_worker
Creating service voting-app_redis

数分後、ローカルマシン上で Docker Swarm サービスが正常に開始されているはずです。

$ docker service list
ID             NAME                MODE         REPLICAS   IMAGE                                                            PORTS
fiexmedo7vms   voting-app_db       replicated   1/1        postgres:9.4
kamhy0edlulo   voting-app_redis    replicated   1/1        redis:alpine                                                     *:30000->6379/tcp
rf2fskw2apvs   voting-app_result   replicated   1/1        111122223333.dkr.ecr.eu-west-1.amazonaws.com/voting-app:result   *:5001->80/tcp
uopmoan7vvd8   voting-app_vote     replicated   1/1        111122223333.dkr.ecr.eu-west-1.amazonaws.com/voting-app:vote     *:5000->80/tcp
klis3kck8pi0   voting-app_worker   replicated   1/1        111122223333.dkr.ecr.eu-west-1.amazonaws.com/voting-app:worker

Web ブラウザで http://localhost:5000 と http://localhost:5001 を開くと、Web アプリケーションに関連付けられた投票ページと結果ページが表示されます。

これでサンプルアプリケーションが Docker Swarm 上で正常に動作することが証明され、Amazon ECS への移行のソースとして使用できるワークロードの定義ファイルができました。

Docker Swarm のコンセプトを Amazon ECS にマッピング

ワークロードのセグメンテーションにセキュリティグループを活用

Docker Swarm はオーバーレイネットワークによるネットワークのセグメント化を実装しており、オーバーレイネットワーク上のすべての通信が許可されます。特定のワークロード (例えばデータベース) をセグメント化するには、ワークロードを独自のオーバーレイネットワークに配置し、ワークロードへの接続を必要とするマイクロサービスのみをオーバーレイネットワークに接続する必要があります。投票アプリの Compose ファイルでは、これらのオーバーレイネットワークが定義され、“Frontend” と “Backend”というラベルが付けられています。

$ cat docker-compose.yml
<snippet>
 networks:
  frontend:
  backend:

AWS では、ワークロードを分離する代わりにセキュリティグループが使用されます。Docker Compose for Amazon ECS は、ユーザーに代わってセキュリティグループをプロビジョニングし、それらのセキュリティグループを ECS タスクにアタッチします。Compose の仕様では、セキュリティグループは Network の概念にマッピングされています。Compose の構文は、Docker Swarm サービスの場合と同じです。デプロイのターゲットが Docker Swarm から Amazon ECS に変更されると、Compose CLI はセキュリティグループを作成し、“Vote” および “Redis” サービスに関連するタスクに、そのセキュリティグループをアタッチします。以下がその例になります。

services:
  vote:
    image: ${ECR_URI}:vote
    networks:
      - frontend
    
  redis:
    image: redis:alpine
    networks:
      - frontend

networks:
  frontend:

Amazon ECS で投票アプリを公開

Compose の仕組みを通じて公開される2 つ目のネットワークコンポーネントは、エンドユーザーがワークロードを利用できる方法を提供します。Compose ファイルではサービス定義の一部として、パブリッシュポートとターゲットポートが定義されます。パブリッシュポートは外部からアクセス可能なポートを指し、ターゲットポートはアプリケーションが実行されているコンテナ内のポートを指します。

# ポート番号　5000　は公開ポート、80 はターゲットポート
services:
    vote:
      image: ${ECR_URI}:worker
      ports:
       - 5000:80

Docker Swarm では、ワークロードが公開されると、公開されたポートがクラスター内のすべてのノードで公開されます。ingress ネットワークと呼ばれる内部のオーバーレイネットワークが、リクエストを受け取ったノードからコンテナが実行されているノードへのトラフィックをルーティングします。これは、Docker Swarm の ingress ネットワーク、またはルーティング・メッシュと呼ばれることがあります。

一方 Amazon ECS は、サービスを公開するためにより伝統的なアプローチをとります。ECS のタスクは Amazon VPC にアタッチされたネットワークインターフェースを持っているので、Elastic Load Balancing をタスク郡のフロントにするのが一般的です。Docker Compose for Amazon ECS は、ロードバランサー、リスナー、ターゲットグループの作成を抽象化します。サービス定義の中にポートが定義されている場合、Compose CLI は Elastic Load Balancing を作成し、公開されたポートのリスナーを作成し、ターゲットポートのターゲットグループにマッピングします。

本記事の執筆時点 (2021/08/02) では、Docker Compose for Amazon ECS は、Compose サービスの公開ポートがターゲットポートと一致する必要があります。そのため、投票アプリを Amazon ECS にデプロイする前に、Compose ファイルのターゲットポートを更新する必要があります。さらに、Redis サービスは外部に公開する必要がなく、また今後も公開すべきではないため、現在 docker-compose.ymlファイルに定義されている公開ポートを削除します。

<snippet>
  vote:
    image: ${ECR_URI}:vote
    ports:
      - 80:80

  redis:
    image: redis:alpine
    networks:
      - frontend

<snippet>
  result:
    image: ${ECR_URI}:result
    ports:
      - 80:80

Compose ファイルでアプリケーションを公開する際に、考慮すべきポイントがもうひとつあります。Docker Compose for Amazon ECS は、Compose ファイル内で定義されたすべてのサービスに対して同じ Elastic Load Balancer を利用するため、2 つのサービスが同じポートで公開されている場合にコンフリクトが発生します。投票アプリを Docker Swarm から移行する際にこの問題を回避するには、Compose ファイルにカスタム CloudFormation リソースを定義し、Compose オーバーレイを使用して ELB リスナーポートをオーバーライドします。このケースでは、投票結果サービスの ELB リスナーの値をオーバーレイして、ELB リスナーをポート8080で公開しています。次の x-aws-cloudformation を Compose ファイルの下部に配置します。

<snippet>
x-aws-cloudformation:
  Resources:
    ResultTCP80Listener:
      Properties:
        Port: 8080
    Backend8080Ingress:
      Type: AWS::EC2::SecurityGroupIngress
      Properties:
        CidrIp: 0.0.0.0/0
        Description: result:8080/tcp on backend network
        GroupId:
          Ref: BackendNetwork
        IpProtocol: TCP
        ToPort: 8080
        FromPort: 8080
 
       サービスの配置とロールアウトの動作 投票アプリの Compose ファイルに必要な最後の調整は、Docker Swarm のサービススケジューリングフラグのいくつかを削除することです。各コンテナオーケストレーターには、サービスのロールアウト方法を制御する変数があります。例えば、投票アプリの Compose ファイルに設定されている変数には、ローリングアップデート時に並列で更新するレプリカの数や、データボリュームを利用できるようにデータベースサービスをクラスター内の特定のノードに固定することなどが含まれています。 Docker Compose for Amazon ECS は、Compose のキー項目を Docker Swarm とすべて共有しているわけではないので、投票アプリの各マイクロサービスの 
       deploy セクションを以下の例のように更新する必要があります。 
       
# Docker Swarm でのデプロイに関する変数
services:
  redis:
    deploy:
      replicas: 1
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure

# Amazon ECS でのデプロイに関する変数
services:
  redis:
    deploy:
      replicas: 1
      update_config:
        parallelism: 1
 
       
上記の Redis サービスへの変更は、docker-compose.yml で定義されている 5 つのサービス (Redis、database、vote、result、worker) すべてにも行う必要があります。
 
       
ステートフルなワークロード
 
       
コンテナのオーバーレイファイルシステムは一時的なものです。コンテナが停止するとそのファイルシステムに保存されたデータはすべて失われます。そのため、アプリケーションコンテナに状態を提供するために、データボリュームを使用してコンテナのファイルシステムに外部ディレクトリをマウントすることができます。
 
       
volumes は、基盤となるストレージ技術を抽象化する Compose ファイルの概念です。Docker Swarm を利用する場合、基盤となるストレージ技術は Docker Swarm のデータボリュームです。デフォルトの Docker Swarm データボリュームドライバーは、基盤となるコンテナホスト上にディレクトリを作成し、このディレクトリが Swarm サービスにマウントされます。ホスト上のこのディレクトリは、コンテナが停止しても削除されません。これは、ディレクトリのライフサイクルが Docker Swarm サ ービスではなく、Docker Swarm ボリュームによって管理されているためです。
 
       
投票アプリでは、Postgres データベースがステートフルなサービスとなっています。Compose ファイルでボリュームを定義し、db サービスにアタッチしました。これを Docker Swarm クラスターにデプロイすると、db-data ボリュームはコンテナホスト上のデータボリュームとなり、その基盤となるデータボリュームは Postgres コンテナの /var/lib/postgresql/data にマウントされます。これは、db-data ボリュームが既存の Compose ファイル内の最下部で、トップレベルのオブジェクトとして定義されていることからわかります。volumes のサブキーは、コンテナ内のターゲットディレクトリを指定するために db サービスで使用されます。
 
       
services:
<snippet>
  db:
    image: postgres:9.4
    environment:
      POSTGRES_USER: "postgres"
      POSTGRES_PASSWORD: "postgres"
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - backend
    deploy:
      replicas: 1
      update_config:
        parallelism: 1

<snippet>
volumes:
  db-data:
 
       
同じ Compose ファイルを Amazon ECS にデプロイする場合、voluems キーは基盤となるコンテナホスト上のディレクトリにマッピングされず、代わりに Amazon Elastic File System (Amazon EFS) にマッピングされます。EFS の共有は、NFS を介してコンテナにマウントされ、POSIX パーミッションでロックダウンされます。Docker Compose for Amazon ECS では、EFS の概念はすべてユーザーから抽象化されているため、Compose ファイルに変更を加える必要はありません。投票アプリの Compose ファイルが Amazon ECS にデプロイされると、Compose CLI は投票アプリ用の EFS の共有を作成し、各アベイラビリティーゾーンにマウント・ターゲットを作成し、EFS アクセスポイントを作成します。
 
       
EFS ストレージを利用した Postgres データベースをコンテナ上で展開していますが、これはデモ目的のためであり、必ずしもベストプラクティスではありません。ユーザーは、特定のニーズ、ユースケース、およびパフォーマンス要件に基づいて、ステートフルなワークロードに最適なデプロイモデルを検討する必要があります。
 
       
Compose ファイル の最終形
 
       
前のセクションで行ったさまざまな変更を適用した後、Compose ファイルの先頭にあるバージョン行を削除します (Composeの仕様には version キーがないため)。投票アプリの Compose ファイルは以下のようになります。
 
       
$ cat docker-compose.yml
services:

  redis:
    image: redis:alpine
    networks:
      - frontend
    deploy:
      replicas: 1
      update_config:
        parallelism: 1
  db:
    image: postgres:9.4
    environment:
      POSTGRES_USER: "postgres"
      POSTGRES_PASSWORD: "postgres"
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - backend
    deploy:
      replicas: 1
      update_config:
        parallelism: 1
  vote:
    image: ${ECR_URI}:vote
    ports:
      - 80:80
    networks:
      - frontend
    depends_on:
      - redis
    deploy:
      replicas: 1
      update_config:
        parallelism: 1
  result:
    image: ${ECR_URI}:result
    ports:
      - 80:80
    networks:
      - backend
    depends_on:
      - db
    deploy:
      replicas: 1
      update_config:
        parallelism: 1

  worker:
    image: ${ECR_URI}:worker
    networks:
      - frontend
      - backend
    depends_on:
      - db
      - redis
    deploy:
      replicas: 1
      update_config:
        parallelism: 1

networks:
  frontend:
  backend:

volumes:
  db-data:

x-aws-cloudformation:
  Resources:
    ResultTCP80Listener:
      Properties:
        Port: 8080
    Backend8080Ingress:
      Type: AWS::EC2::SecurityGroupIngress
      Properties:
        CidrIp: 0.0.0.0/0
        Description: result:8080/tcp on backend network
        GroupId:
          Ref: BackendNetwork
        IpProtocol: TCP
        ToPort: 8080
        FromPort: 8080
 
       
Compose ファイルを Amazon ECS へデプロイ
 
       
1) Docker Context の編集
 
       
Docker Compose for ECS は Docker Context を介して設定されます。Docker Context により、Docker コマンドラインクライアントは異なるエンドポイントを指すことができます。デフォルトの Context は、ローカルワークステーション / サーバーで実行されている Docker Engine です。
 
       
# Amazon ECS 用の Docker Context 作成
$ docker context create ecs demo_ecs_context
 
       
Docker Context ウィザードを通じて、AWS クラウド上でリソースをプロビジョニングする際に使用する AWS クレデンシャルを選択するよう指示されます。Docker Context を作成する際の詳細およびトラブルシューティングについては、Docker Documentation を参照してください。
 
       
2) Docker Compose up
 
       
Docker Compose CLI で Compose ファイルを Amazon ECS にデプロイします。
 
       
# Amazon ECS 用の Context　を選択
$ docker context use demo_ecs_context

# Docker Compose ファイルをデプロイ
$ docker compose \
  --project-name voting-app \
  --file docker-compose.yml \
  up
 
       
すべてのリソースの作成と設定には時間が掛かりますが、デプロイが完了すると、投票アプリの前にあるロードバランサーの DNS 名を次のコマンドで取得できます。ECS タスクが ELB リスナーのヘルスチェックを通過して利用できるようになるまでには数分かかることがあります。
 
       
$ aws elbv2 describe-load-balancers | jq -r '.LoadBalancers | .[] | select(.DNSName|test("vot.")).DNSName'
votin-LoadB-DYQ1QS2R3PU0-290533005.eu-west-1.elb.amazonaws.com
 
       
ポート 80 では、”vote” マイクロサービスにアクセスできるようになっています。
 
       
 
       
ポート8080 では、“Result” マイクロサービスにアクセスできるはずです。
 
       
 
       
アプリケーションが Docker Swarm から Amazon ECS に移行されると、本番ワークロードへの移行を完了するために追加の変更が必要になります。CI/CD パイプラインで、新しいデプロイメントターゲットやテスト用のエンドポイントを更新する必要があるかもしれません。DNS エントリや CDN は、Docker Swarm エンドポイントから ELB のエンドポイントに切り替える必要があるかもしれません。このようなロールアウトは通常、段階的なアプローチで実施され、トラフィックは徐々に新しい環境に移行されます。
 
       
すべての本番トラフィックが ECS 環境から提供されるようになったら、Docker Swarm クラスターを削除することができます。この記事では、シングルノードの Docker Swarm クラスターのみを運用していたので、環境をクリーンアップするために以下のコマンドを実行します。
 
       
# デフォルトの Context に切り替えて、ローカルの Docker Daemon をクリーンアップ
$ docker context use default

# Docker Stack の削除
$ docker stack remove voting-app

# サービスが動いていないことを確認
$ docker service list
ID        NAME      MODE      REPLICAS   IMAGE     PORTS

# Docker Swarm クラスターの削除
$ docker swarm leave --force
Node left the swarm.
 
       
クリーンアップ
 
       
この記事を通じて AWS 上にデプロイされたすべてのリソースをクリーンアップするために、以下のコマンドを実行します。
 
       
# Amazon ECS 用の Context に切り替え
$ docker context use demo_ecs_context

# 投票アプリのクリーンアップ
$ docker compose \
  --project-name voting-app \
  down

# EFS の共有ファイルを削除
$ FS_ID=$(aws efs describe-file-systems | jq -r '.FileSystems | .[] | select(.Name=="voting-app_db-data").FileSystemId')
$ aws efs delete-file-system \
   --file-system-id $FS_ID

# ECR リポジトリのクリーンアップ
$ aws ecr delete-repository \
  --repository-name voting-app \
 
       
まとめ
 
       
この記事では Docker Compose for Amazon ECS を活用することで、アプリケーションの定義を記述することなく、コンテナオーケストレーター間でアプリケーションを移行できることを示しました。Docker のサンプル投票アプリを使用し、コンテナイメージのローカルコピーを Amazon ECR にプッシュしました。その後、私たちは、
 
       
     
        
  • Compose v3 ファイルを使用して、アプリケーションを Docker Swarmに デプロイしました。
    •  
        
  • Compose ファイルのいくつかのキーを調整して、アプリケーションが AWS クラウドでどのように実行されるべきかを定義しました。
    •  
        
  • Docker Compose for Amazon ECSを 使用して、投票アプリを Amazon ECS にデプロイしました。
    •  
       
 
       
Docker Compose for Amazon ECS に関する追加情報は Docker ドキュメントを参照してください。問題の報告や機能要求の作成には、Compose-Cli GitHub Repository の ‘Issues’ タブをご利用ください。Docker Compose for Amazon ECS のロードマップについては、Docker Roadmap on GitHub をご覧ください。
 
       
翻訳はソリューションアーキテクト加治が担当しました。原文はこちらです。