AWS App Mesh と Amazon の開始方法 ECS - AWS App Mesh

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS App Mesh と Amazon の開始方法 ECS

このトピックは、Amazon AWS App Mesh で実行されている実際のサービスで を使用するのに役立ちますECS。このチュートリアルでは、複数の App Mesh リソースタイプのベーシックな機能について説明します。

シナリオ

App Mesh の使用方法を説明するために、次の特性を持つアプリケーションがあると仮定します。

  • serviceA および serviceB という名前の 2 つのサービスで構成されています。

  • どちらのサービスも、apps.local という名前の名前空間にメンバー登録されます。

  • ServiceA は HTTP/2、ポート 80 serviceB経由で と通信します。

  • すでに serviceB のバージョン 2 をデプロイし、serviceBv2 名前空間に apps.local という名前でメンバー登録しました。

次の要件があります。

  • から にトラフィックの 75% serviceA を送信serviceBし、serviceBv2最初に にトラフィックの 25% を送信するとします。に 25% のみを送信することでserviceBv2、 からトラフィックの 100% を送信する前に、バグがないことを検証できますserviceA

  • トラフィックの重み付けを簡単に調整して、信頼性が証明されたら、トラフィックの 100% が serviceBv2 へ転送されるようにします。すべてのトラフィックが serviceBv2 に送信されたら、serviceB を切断します。

  • 上記の要件を満たすために、実際のサービスの既存のアプリケーションコードまたはサービスディスカバリ登録を変更する必要はありません。

要件を満たすために、仮想サービス、仮想ノード、仮想ルーター、およびルートで、App Mesh サービスメッシュを作成することにします。メッシュを実装した後、サービスを更新して、Envoy プロキシを使用します。更新されると、サービスは相互に直接ではなく、Envoy プロキシを介して相互に通信します。

前提条件

  • App Mesh の概念を既に理解している。詳細については、「AWS App Mesh とは?」を参照してください。

  • Amazon のECSs概念に関する既存の理解。詳細については、「Amazon Elastic Container Service デベロッパーガイドECS」の「Amazon とは」を参照してください。

  • App Mesh はDNS、、 AWS Cloud Map、またはその両方に登録されている Linux サービスをサポートします。この入門ガイドを使用するには、 に登録されている 3 つの既存のサービスがあることをお勧めしますDNS。このトピックの手順は、既存のサービスが、serviceAserviceBserviceBv2 という名前で、すべてのサービスが apps.local という名前の名前空間を介して検出可能であることを前提としています。

    サービスが存在しない場合でもサービスメッシュとそのリソースを作成できますが、実際のサービスをデプロイするまでメッシュを使用することはできません。Amazon でのサービス検出の詳細についてはECS、「サービス検出」を参照してください。ECS サービス検出を使用して Amazon サービスを作成するには、「チュートリアル: サービス検出を使用したサービスの作成」を参照してください。サービスがまだ実行されていない場合は、ECSサービス検出 を使用して Amazon サービスを作成できます

ステップ 1: メッシュと仮想サービスを作成する

サービスメッシュは、サービス間のネットワークトラフィックの論理的な境界であり、サービスはその中に存在します。詳細については、「サービスメッシュ」を参照してください。仮想サービスは、実際のサービスを抽象化したものです。詳細については、「仮想サービス」を参照してください。

次の リソースを作成します。

  • シナリオ内のすべてのサービスが apps 名前空間にメンバー登録されているため、apps.local という名前のメッシュ。

  • serviceb.apps.local という名前の仮想サービス。仮想サービスは、その名前で検出可能なサービスを表しているため、別の名前をリファレンスするようにコードを変更したくないためです。servicea.apps.local という名前の仮想サービスが、次のステップで追加されます。

AWS Management Console または AWS CLI バージョン 1.18.116 以降または 2.0.38 以降を使用して、次のステップを完了できます。を使用している場合は AWS CLI、 aws --version コマンドを使用してインストールされている AWS CLI バージョンを確認します。バージョン 1.18.116 以降、または 2.0.38 以降をインストールしていない場合は、AWS CLIをインストールまたは更新する必要があります。使用するツールのタブを選択します。

AWS Management Console
  1. https://console.aws.amazon.com/appmesh/開始時に App Mesh コンソールの初回実行ウィザードを開きます。

  2. [メッシュ名]apps と入力します。

  3. [仮想サービス名]serviceb.apps.local と入力します。

  4. 続行するには、[次へ] を選択します。

AWS CLI
  1. create-mesh コマンドを使用してメッシュを作成します。

    aws appmesh create-mesh --mesh-name apps
  2. create-virtual-service コマンドを使用して仮想サービスを作成します。

    aws appmesh create-virtual-service --mesh-name apps --virtual-service-name serviceb.apps.local --spec {}

ステップ 2: 仮想ノードを作成する

仮想ノードは、実際のサービスの論理ポインタとして機能します。詳細については、「仮想ノード」を参照してください。

仮想ノードの 1 つが serviceB という名前の実際のサービスを表すため、serviceB という名前の仮想ノードを作成します。仮想ノードが表す実際のサービスは、serviceb.apps.local というホスト名を持つ DNS を介して検出可能です。または、 を使用して実際のサービスを検出することもできます AWS Cloud Map。仮想ノードは、ポート 80 の HTTP/2 プロトコルを使用してトラフィックをリッスンします。ヘルスチェックと同様に、その他のプロトコルもサポートされています。次のステップで、serviceA および serviceBv2 の仮想ノードを作成します。

AWS Management Console
  1. [仮想ノード名]serviceB と入力します。

  2. サービス検出方法 でDNSホスト名 serviceb.apps.localDNSを選択して入力します。

  3. [リスナーの設定] で、[プロトコル][http2] を選択し、[ポート]80 と入力します。

  4. 続行するには、[次へ] を選択します。

AWS CLI
  1. 次の内容で、create-virtual-node-serviceb.json という名前のファイルを作成します。

    { "meshName": "apps", "spec": { "listeners": [ { "portMapping": { "port": 80, "protocol": "http2" } } ], "serviceDiscovery": { "dns": { "hostname": "serviceB.apps.local" } } }, "virtualNodeName": "serviceB" }
  2. JSON ファイルを入力として使用して、 create-virtual-node コマンドを使用して仮想ノードを作成します。

    aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-serviceb.json

ステップ 3: 仮想ルーターとルートを作成する

仮想ルーターは、メッシュ内の 1 つ以上の仮想サービスのトラフィックを送信します。詳細については、「仮想ルーター」および「ルート」を参照してください。

次の リソースを作成します。

  • serviceB という名前の仮想ルーター。serviceB.apps.local 仮想サービスは、他のサービスとのアウトバウンド通信を開始しないためです。前に作成した仮想サービスは、実際の serviceb.apps.local サービスの抽象化であることに注意してください。仮想サービスは、仮想ルーターにトラフィックを送信します。仮想ルーターは、ポート 80 の HTTP/2 プロトコルを使用してトラフィックをリッスンします。その他のプロトコルもサポートされています。

  • serviceB という名前のルート。このルートはトラフィックの 100% を serviceB 仮想ノードにルーティングします。重み付けは、serviceBv2 仮想ノードを追加した後のステップで行います。このガイドでは説明しませんが、ルートにフィルタ条件を追加したり、通信の問題が発生したときに Envoy プロキシが仮想ノードへのトラフィックの送信を複数回試行する再試行ポリシーを追加したりできます。

AWS Management Console
  1. [仮想ルーター名]serviceB と入力します。

  2. [リスナーの設定] で、[プロトコル][http2] を選択して、[ポート]80 を指定します。

  3. [ルート名]serviceB と入力します。

  4. [ルートタイプ] で、[http2] を選択します。

  5. [ターゲット設定][仮想ノード名]で、[serviceB] を選択し、[重み]に 100 と入力します。

  6. [一致設定] で、[方法] を選択します。

  7. 続行するには、[次へ] を選択します。

AWS CLI
  1. 仮想ルーターを作成します。

    1. 次の内容で、create-virtual-router.json という名前のファイルを作成します。

      { "meshName": "apps", "spec": { "listeners": [ { "portMapping": { "port": 80, "protocol": "http2" } } ] }, "virtualRouterName": "serviceB" }
    2. JSON ファイルを入力として使用して、 create-virtual-router コマンドを使用して仮想ルーターを作成します。

      aws appmesh create-virtual-router --cli-input-json file://create-virtual-router.json
  2. ルートを作成します。

    1. 次の内容で、create-route.json という名前のファイルを作成します。

      { "meshName" : "apps", "routeName" : "serviceB", "spec" : { "httpRoute" : { "action" : { "weightedTargets" : [ { "virtualNode" : "serviceB", "weight" : 100 } ] }, "match" : { "prefix" : "/" } } }, "virtualRouterName" : "serviceB" }
    2. ファイルJSONを入力として使用して create-route コマンドでルートを作成します。

      aws appmesh create-route --cli-input-json file://create-route.json

ステップ 4: 確認して作成する

前のステップと照らし合わせて設定を確認します。

AWS Management Console

いずれかのセクションに変更を加える必要がある場合は、[編集] を選択します。設定が完了したら、[メッシュの作成] を選択します。

[ステータス] 画面には、作成されたすべてのメッシュリソースが表示されます。作成したリソースをコンソールに表示するには、[メッシュの表示] を選択します。

AWS CLI

describe-mesh コマンドで作成したメッシュの設定を確認します。

aws appmesh describe-mesh --mesh-name apps

describe-virtual-service コマンドで作成した仮想サービスの設定を確認します。

aws appmesh describe-virtual-service --mesh-name apps --virtual-service-name serviceb.apps.local

describe-virtual-node コマンドで作成した仮想ノードの設定を確認します。

aws appmesh describe-virtual-node --mesh-name apps --virtual-node-name serviceB

describe-virtual-router コマンドで作成した仮想ルーターの設定を確認します。

aws appmesh describe-virtual-router --mesh-name apps --virtual-router-name serviceB

describe-route コマンドで作成したルートの設定を確認します。

aws appmesh describe-route --mesh-name apps \ --virtual-router-name serviceB --route-name serviceB

ステップ 5: 追加のリソースを作成する

このシナリオを完了するには、次のことを行う必要があります。

  • serviceBv2 という名前の仮想ノードと、serviceA という名前の別の仮想ノードを作成します。両方の仮想ノードは、HTTP/2 ポート 80 経由でリクエストをリッスンします。serviceA 仮想ノードには、serviceb.apps.local のバックエンドを設定します。serviceA 仮想ノードからのすべてのアウトバウンドトラフィックは、serviceb.apps.local という名前の仮想サービスに送信されます。このガイドでは説明しませんが、仮想ノードのアクセスログを書き込むファイルパスを指定することもできます。

  • servicea.apps.local という名前の追加の仮想サービスを 1 つ作成します。これにより、すべてのトラフィックが serviceA 仮想ノードに直接送信されます。

  • 前のステップで作成した serviceB ルートを更新して、トラフィックの 75% を serviceB 仮想ノードに送信し、25% を serviceBv2 仮想ノードに送信します。時間の経過とともに、serviceBv2 が 100% のトラフィックを受信するまで、継続して重みを変更することができます。すべてのトラフィックが serviceBv2 に送信されたら、serviceB 仮想ノードと実際のサービスをシャットダウンして中止することができます。重みを変更しても、serviceb.apps.local 仮想サービス名および実際のサービス名は変更されないため、コードを変更する必要はありません。serviceb.apps.local 仮想サービスは仮想ルーターにトラフィックを送信し、仮想ルーターはトラフィックを仮想ノードにルーティングすることに注意してください。仮想ノードのサービスディスカバリ名は、いつでも変更できます。

AWS Management Console
  1. 左のナビゲーションペインで [メッシュ] を選択します。

  2. 前のステップで作成した apps メッシュを選択します。

  3. 左側のナビゲーションペインで、[仮想ノード] を選択します。

  4. [仮想ノードの作成] を選択します。

  5. 仮想ノード名 には を入力しserviceBv2サービス検出方法 には を選択しDNSDNSホスト名 には を入力しますservicebv2.apps.local

  6. [リスナーの設定] で、[プロトコル][http2] を選択し、[ポート]80 を入力します。

  7. [仮想ノードの作成] を選択します。

  8. [仮想ノードの作成] をもう一度選択します。[仮想ノード名]serviceA と入力してください。サービス検出メソッド で を選択しDNSDNSホスト名 で を入力しますservicea.apps.local

  9. [新しいバックエンド] の下の [仮想サービス名の入力]serviceb.apps.local と入力します。

  10. [リスナーの設定] で、[プロトコル][http2] を選択し、[ポート]80 を入力して、[仮想ノードの作成] を選択します。

  11. 左側のナビゲーションペインで [仮想ルーター] を選択し、リストから [serviceB] 仮想ルーターを選択します。

  12. [ルート] で、前のステップで作成した ServiceB という名前のルートを選択し、[編集] を選択します。

  13. [ターゲット]仮想ノード名で、serviceB[重み] の値を 75 に変更します。

  14. [ターゲットの追加] を選択し、ドロップダウンリストから serviceBv2を選択して、[重み] の値を 25 に設定します。

  15. [保存] を選択します。

  16. 左側のナビゲーションペインで、[仮想サービス] を選択し、[仮想サービスの作成] を選択します。

  17. [仮想サービス名]servicea.apps.local と入力し、[プロバイダー][仮想ノード] を選択し、[仮想ノード]serviceA を選択し、[仮想サービスの作成]を選択します。

AWS CLI
  1. serviceBv2 仮想ノードを作成します。

    1. 次の内容で、create-virtual-node-servicebv2.json という名前のファイルを作成します。

      { "meshName": "apps", "spec": { "listeners": [ { "portMapping": { "port": 80, "protocol": "http2" } } ], "serviceDiscovery": { "dns": { "hostname": "serviceBv2.apps.local" } } }, "virtualNodeName": "serviceBv2" }
    2. 仮想ノードを作成します。

      aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicebv2.json
  2. serviceA 仮想ノードを作成します。

    1. 次の内容で、create-virtual-node-servicea.json という名前のファイルを作成します。

      { "meshName" : "apps", "spec" : { "backends" : [ { "virtualService" : { "virtualServiceName" : "serviceb.apps.local" } } ], "listeners" : [ { "portMapping" : { "port" : 80, "protocol" : "http2" } } ], "serviceDiscovery" : { "dns" : { "hostname" : "servicea.apps.local" } } }, "virtualNodeName" : "serviceA" }
    2. 仮想ノードを作成します。

      aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicea.json
  3. 前のステップで作成した serviceb.apps.local 仮想サービスを更新して、そのトラフィックを serviceB 仮想ルーターに送信します。仮想サービスが最初に作成された時点では、serviceB 仮想ルーターがまだ作成されていないため、トラフィックはどこにも送信されませんでした。

    1. 次の内容で、update-virtual-service.json という名前のファイルを作成します。

      { "meshName" : "apps", "spec" : { "provider" : { "virtualRouter" : { "virtualRouterName" : "serviceB" } } }, "virtualServiceName" : "serviceb.apps.local" }
    2. update-virtual-service コマンドを使用して仮想サービスを更新します。

      aws appmesh update-virtual-service --cli-input-json file://update-virtual-service.json
  4. 前のステップで作成した serviceB ルートを更新します。

    1. 次の内容で、update-route.json という名前のファイルを作成します。

      { "meshName" : "apps", "routeName" : "serviceB", "spec" : { "http2Route" : { "action" : { "weightedTargets" : [ { "virtualNode" : "serviceB", "weight" : 75 }, { "virtualNode" : "serviceBv2", "weight" : 25 } ] }, "match" : { "prefix" : "/" } } }, "virtualRouterName" : "serviceB" }
    2. update-route コマンドを使用してルートを更新します。

      aws appmesh update-route --cli-input-json file://update-route.json
  5. serviceA 仮想サービスを作成します。

    1. 次の内容で、create-virtual-servicea.json という名前のファイルを作成します。

      { "meshName" : "apps", "spec" : { "provider" : { "virtualNode" : { "virtualNodeName" : "serviceA" } } }, "virtualServiceName" : "servicea.apps.local" }
    2. 仮想サービスを作成します。

      aws appmesh create-virtual-service --cli-input-json file://create-virtual-servicea.json
メッシュの概要

サービスメッシュを作成する前に、servicea.apps.localserviceb.apps.local、および servicebv2.apps.local という 3 つの実際のサービスがありました。実際のサービスに加えて、実際のサービスを表す次のリソースを含むサービスメッシュが作成されました。

  • 2 つの仮想サービス。プロキシは、仮想ルーターを経由して、servicea.apps.local 仮想サービスからのすべてのトラフィックを serviceb.apps.local 仮想サービスに送信します。

  • serviceAserviceB、および serviceBv2 という名前の 3 つの仮想ノード。Envoy プロキシは、仮想ノードに対して設定されたサービスディスカバリ情報を使用して、実際のサービスの IP アドレスを検索します。

  • Envoy プロキシがインバウンドトラフィックの 75% を serviceB 仮想ノードに、25% を serviceBv2 仮想ノードにルーティングするように指定する 1 つのルートを持つ仮想ルーター。

ステップ 6: サービスを更新する

メッシュを作成したら、次のタスクを完了する必要があります。

  • 各 Amazon ECSタスクでデプロイする Envoy プロキシに、1 つ以上の仮想ノードの設定を読み取る権限を付与します。プロキシの認証方法の詳細については、「プロキシの認証」を参照してください。

  • Envoy プロキシを使用するように既存の各 Amazon ECSタスク定義を更新します。

認証情報

Envoy コンテナには、App Mesh サービスに送信されるリクエストに署名するための AWS Identity and Access Management 認証情報が必要です。Amazon EC2起動タイプ でデプロイされた Amazon ECSタスクの場合、認証情報はインスタンスロール またはタスクIAMロール から取得できます。Linux コンテナに Fargate でデプロイされた Amazon ECSタスクは、インスタンスIAMプロファイルの認証情報を提供する Amazon EC2メタデータサーバーにアクセスできません。認証情報を指定するには、Linux コンテナタイプで Fargate でデプロイされたタスクに タスクIAMロールをアタッチする必要があります。

タスクが Amazon EC2起動タイプでデプロイされ、Amazon EC2メタデータサーバーへのアクセスがブロックされている場合は、「タスクのロール」の「重要な注釈」で説明されているように、タスクIAMロールもタスクにアタッチする必要があります。 IAM インスタンスまたはタスクに割り当てるロールには、「プロキシ認証」の説明に従ってIAM、ポリシーがアタッチされている必要があります。

を使用してタスク定義を更新するには AWS CLI

Amazon ECS AWS CLI コマンド を使用しますregister-task-definition。以下のタスク定義の例は、サービスの App Mesh を設定する方法を示しています。

注記

コンソールECSを使用した Amazon の App Mesh の設定は利用できません。

プロキシ設定

App Mesh を使用するように Amazon ECSサービスを設定するには、サービスのタスク定義に次のプロキシ設定セクションが必要です。プロキシ設定 typeAPPMESH に、containerNameenvoy に設定します。これに応じて、次のプロパティ値を設定します。

IgnoredUID

Envoy プロキシは、このユーザー ID を使用するプロセスからのトラフィックをルーティングしません。このプロパティ値には任意のユーザー ID を選択できますが、この ID はタスク定義の Envoy コンテナの user ID と同じである必要があります。この一致により、Envoy はプロキシを使用せずに、それ自体のトラフィックを無視することができます。例では、履歴上の目的で 1337 を使用します。

ProxyIngressPort

これは、Envoy プロキシのコンテナのインバウンドポートです。この値は 15000 に設定します。

ProxyEgressPort

これは、Envoy プロキシのコンテナのアウトバウンドポートです。この値は 15001 に設定します。

AppPorts

アプリケーションコンテナがリッスンするインバウンドポートを指定します。この例では、アプリケーションコンテナはポート 9080 でリッスンします。指定するポートは、仮想ノードリスナーで設定されたポートと一致する必要があります。

EgressIgnoredIPs

Envoy は、これらの IP アドレスにトラフィックをプロキシしません。この値を に設定します。これにより169.254.170.2,169.254.169.254、Amazon EC2メタデータサーバーと Amazon ECSタスクメタデータエンドポイントは無視されます。メタデータエンドポイントは、タスク認証情報のIAMロールを提供します。さらにアドレスを追加できます。

EgressIgnoredPorts

コンマで区切られたポートのリストを追加できます。Envoy は、これらのポートにトラフィックをプロキシしません。ポートがない場合でも、ポート 22 は無視されます。

注記

無視できるアウトバウンドポートの最大数は 15 です。

"proxyConfiguration": { "type": "APPMESH", "containerName": "envoy", "properties": [{ "name": "IgnoredUID", "value": "1337" }, { "name": "ProxyIngressPort", "value": "15000" }, { "name": "ProxyEgressPort", "value": "15001" }, { "name": "AppPorts", "value": "9080" }, { "name": "EgressIgnoredIPs", "value": "169.254.170.2,169.254.169.254" }, { "name": "EgressIgnoredPorts", "value": "22" } ] }
アプリケーションコンテナ Envoy の依存関係

タスク定義のアプリケーションコンテナは開始する前に Envoy プロキシがブートストラップして起動するのを待機する必要があります。これを確実に行うには、各アプリケーションコンテナの定義に dependsOn セクションを設定して、Envoy コンテナが HEALTHY としてレポートするのを待ちます。次のコードは、この依存関係があるアプリケーションコンテナの定義の例を示しています。次の例のすべてのプロパティが必須です。プロパティ値の一部も必要ですが、replaceable.

{ "name": "appName", "image": "appImage", "portMappings": [{ "containerPort": 9080, "hostPort": 9080, "protocol": "tcp" }], "essential": true, "dependsOn": [{ "containerName": "envoy", "condition": "HEALTHY" }] }

Envoy コンテナの定義

Amazon ECSタスク定義には、App Mesh Envoy コンテナイメージが含まれている必要があります。

me-south-1ap-east-1ap-southeast-3eu-south-1il-central-1af-south-1 以外のサポートされているリージョンすべて。を置き換えることができます。Region-codeme-south-1ap-east-1、、、ap-southeast-3eu-south-1il-central-1および 以外の任意の リージョンを持つ af-south-1

標準

840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod

FIPS準拠

840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod-fips
me-south-1

標準

772975370895.dkr.ecr.me-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod

FIPS準拠

772975370895.dkr.ecr.me-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod-fips
ap-east-1

標準

856666278305.dkr.ecr.ap-east-1.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod

FIPS準拠

856666278305.dkr.ecr.ap-east-1.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod-fips
ap-southeast-3

標準

909464085924.dkr.ecr.ap-southeast-3.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod

FIPS準拠

909464085924.dkr.ecr.ap-southeast-3.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod-fips
eu-south-1

標準

422531588944.dkr.ecr.eu-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod

FIPS準拠

422531588944.dkr.ecr.eu-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod-fips
il-central-1

標準

564877687649.dkr.ecr.il-central-1.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod

FIPS準拠

564877687649.dkr.ecr.il-central-1.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod-fips
af-south-1

標準

924023996002.dkr.ecr.af-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod

FIPS準拠

924023996002.dkr.ecr.af-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod-fips
Public repository

標準

public.ecr.aws/appmesh/aws-appmesh-envoy:v1.29.6.1-prod

FIPS準拠

public.ecr.aws/appmesh/aws-appmesh-envoy:v1.29.6.1-prod-fips
重要

App Mesh での使用は、バージョン v1.9.0.0-prod 以降のみサポートされています。

Envoy プロジェクトチームが App Mesh をサポートする変更をマージをするまでは、App Mesh Envoy コンテナイメージを使用する必要があります。詳細については、GitHub 「ロードマップの問題」を参照してください。

次の例のすべてのプロパティが必須です。プロパティ値の一部も必要ですが、replaceable.

注記
  • Envoy のコンテナの定義は essential とマークされる必要があります。

  • Envoy コンテナに512CPUユニットと少なくとも 64 MiB のメモリを割り当てることをお勧めします。Fargate では、設定できる最低メモリは 1024 MiB です。

  • Amazon ECSサービスの仮想ノード名は、 APPMESH_RESOURCE_ARNプロパティの値に設定する必要があります。このプロパティには、Envoy イメージのバージョン 1.15.0 以降が必要です。詳細については、「Envoy イメージ」を参照してください。

  • user 設定の値は、タスク定義のプロキシ設定の IgnoredUID 値と一致する必要があります。この例では、1337 を使用します。

  • ここに示すヘルスチェックは、Envoy コンテナが正常にブートストラップするのを待ってから、Envoy コンテナが正常ECSであり、アプリケーションコンテナを起動する準備ができていることを Amazon に報告します。

  • デフォルトでは、App Mesh は、Envoy によってメトリクスとトレースでそれ自体が参照されるとき、APPMESH_RESOURCE_ARN で指定したリソースの名前を使用します。APPMESH_RESOURCE_CLUSTER 環境変数に独自の名前を設定することで、この動作を上書きできます。このプロパティには、Envoy イメージのバージョン 1.15.0 以降が必要です。詳細については、「Envoy イメージ」を参照してください。

次のコードは Envoy コンテナの定義の例を示しています。

{ "name": "envoy", "image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod", "essential": true, "environment": [{ "name": "APPMESH_RESOURCE_ARN", "value": "arn:aws:appmesh:us-west-2:111122223333:mesh/apps/virtualNode/serviceB" }], "healthCheck": { "command": [ "CMD-SHELL", "curl -s http://localhost:9901/server_info | grep state | grep -q LIVE" ], "startPeriod": 10, "interval": 5, "timeout": 2, "retries": 3 }, "user": "1337" }
タスク定義の例

次の Amazon ECSタスク定義の例は、上記の例を のタスク定義にマージする方法を示していますtaskB。を使用して Amazon ECS起動タイプの両方のタスクを作成する例を示します AWS X-Ray。の変更 replaceable は、必要に応じて、シナリオtaskAから taskBv2および という名前のタスクのタスク定義を作成します。メッシュ名と仮想ノード名を APPMESH_RESOURCE_ARN 値に置き換え、アプリケーションがリッスンするポートのリストをプロキシ設定の AppPorts 値に置き換えます。デフォルトでは、App Mesh は、Envoy によってメトリクスとトレースでそれ自体が参照されるとき、APPMESH_RESOURCE_ARN で指定したリソースの名前を使用します。APPMESH_RESOURCE_CLUSTER 環境変数に独自の名前を設定することで、この動作を上書きできます。次の例のすべてのプロパティは必須です。プロパティ値の一部も必要ですが、replaceable.

認証情報セクションで説明されているように Amazon ECSタスクを実行している場合は、既存のタスクIAMロール を例に追加する必要があります。

重要

Fargate は 1024 より大きいポート値を使用する必要があります。

例 JSON for Amazon ECSタスク定義 - Linux コンテナ上の Fargate
{ "family" : "taskB", "memory" : "1024", "cpu" : "0.5 vCPU", "proxyConfiguration" : { "containerName" : "envoy", "properties" : [ { "name" : "ProxyIngressPort", "value" : "15000" }, { "name" : "AppPorts", "value" : "9080" }, { "name" : "EgressIgnoredIPs", "value" : "169.254.170.2,169.254.169.254" }, { "name": "EgressIgnoredPorts", "value": "22" }, { "name" : "IgnoredUID", "value" : "1337" }, { "name" : "ProxyEgressPort", "value" : "15001" } ], "type" : "APPMESH" }, "containerDefinitions" : [ { "name" : "appName", "image" : "appImage", "portMappings" : [ { "containerPort" : 9080, "protocol" : "tcp" } ], "essential" : true, "dependsOn" : [ { "containerName" : "envoy", "condition" : "HEALTHY" } ] }, { "name" : "envoy", "image" : "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod", "essential" : true, "environment" : [ { "name" : "APPMESH_VIRTUAL_NODE_NAME", "value" : "mesh/apps/virtualNode/serviceB" } ], "healthCheck" : { "command" : [ "CMD-SHELL", "curl -s http://localhost:9901/server_info | grep state | grep -q LIVE" ], "interval" : 5, "retries" : 3, "startPeriod" : 10, "timeout" : 2 }, "memory" : 500, "user" : "1337" } ], "requiresCompatibilities" : [ "FARGATE" ], "taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole", "executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole", "networkMode" : "awsvpc" }
例 JSON for Amazon ECS task definition with AWS X-Ray - Linux コンテナの Fargate

X-Ray を使用すると、アプリケーションが処理するリクエストに関するデータ収集が可能になります。また、トラフィックフローを視覚化するために使用できるツールが提供されます。Envoy 用の X-Ray ドライバーを使用すると、Envoy はトレース情報を X-Ray に報告することができます。Envoy の設定で、X-Rayトレースを有効にすることができます。設定に基づいて、Envoy は、サイドカーコンテナとして実行されている X-Ray デーモンにトレースデータを送信し、デーモンは、トレースを X-Ray サービスに転送します。トレースが X-Ray に発行されたら、X-Ray コンソールを使用してサービス呼び出しグラフを視覚化し、トレースの詳細をリクエストできます。以下に、X-Ray 統合を有効にするタスク定義JSONを示します。

{ "family" : "taskB", "memory" : "1024", "cpu" : "512", "proxyConfiguration" : { "containerName" : "envoy", "properties" : [ { "name" : "ProxyIngressPort", "value" : "15000" }, { "name" : "AppPorts", "value" : "9080" }, { "name" : "EgressIgnoredIPs", "value" : "169.254.170.2,169.254.169.254" }, { "name": "EgressIgnoredPorts", "value": "22" }, { "name" : "IgnoredUID", "value" : "1337" }, { "name" : "ProxyEgressPort", "value" : "15001" } ], "type" : "APPMESH" }, "containerDefinitions" : [ { "name" : "appName", "image" : "appImage", "portMappings" : [ { "containerPort" : 9080, "protocol" : "tcp" } ], "essential" : true, "dependsOn" : [ { "containerName" : "envoy", "condition" : "HEALTHY" } ] }, { "name" : "envoy", "image" : "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod", "essential" : true, "environment" : [ { "name" : "APPMESH_VIRTUAL_NODE_NAME", "value" : "mesh/apps/virtualNode/serviceB" }, { "name": "ENABLE_ENVOY_XRAY_TRACING", "value": "1" } ], "healthCheck" : { "command" : [ "CMD-SHELL", "curl -s http://localhost:9901/server_info | grep state | grep -q LIVE" ], "interval" : 5, "retries" : 3, "startPeriod" : 10, "timeout" : 2 }, "memory" : 500, "user" : "1337" }, { "name" : "xray-daemon", "image" : "amazon/aws-xray-daemon", "user" : "1337", "essential" : true, "cpu" : "32", "memoryReservation" : "256", "portMappings" : [ { "containerPort" : 2000, "protocol" : "udp" } ] } ], "requiresCompatibilities" : [ "FARGATE" ], "taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole", "executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole", "networkMode" : "awsvpc" }
例 JSON for Amazon ECSタスク定義 - EC2起動タイプ
{ "family": "taskB", "memory": "256", "proxyConfiguration": { "type": "APPMESH", "containerName": "envoy", "properties": [ { "name": "IgnoredUID", "value": "1337" }, { "name": "ProxyIngressPort", "value": "15000" }, { "name": "ProxyEgressPort", "value": "15001" }, { "name": "AppPorts", "value": "9080" }, { "name": "EgressIgnoredIPs", "value": "169.254.170.2,169.254.169.254" }, { "name": "EgressIgnoredPorts", "value": "22" } ] }, "containerDefinitions": [ { "name": "appName", "image": "appImage", "portMappings": [ { "containerPort": 9080, "hostPort": 9080, "protocol": "tcp" } ], "essential": true, "dependsOn": [ { "containerName": "envoy", "condition": "HEALTHY" } ] }, { "name": "envoy", "image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod", "essential": true, "environment": [ { "name": "APPMESH_VIRTUAL_NODE_NAME", "value": "mesh/apps/virtualNode/serviceB" } ], "healthCheck": { "command": [ "CMD-SHELL", "curl -s http://localhost:9901/server_info | grep state | grep -q LIVE" ], "startPeriod": 10, "interval": 5, "timeout": 2, "retries": 3 }, "user": "1337" } ], "requiresCompatibilities" : [ "EC2" ], "taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole", "executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole", "networkMode": "awsvpc" }
例 JSON for Amazon ECSタスク定義 AWS X-Ray - EC2起動タイプ
{ "family": "taskB", "memory": "256", "cpu" : "1024", "proxyConfiguration": { "type": "APPMESH", "containerName": "envoy", "properties": [ { "name": "IgnoredUID", "value": "1337" }, { "name": "ProxyIngressPort", "value": "15000" }, { "name": "ProxyEgressPort", "value": "15001" }, { "name": "AppPorts", "value": "9080" }, { "name": "EgressIgnoredIPs", "value": "169.254.170.2,169.254.169.254" }, { "name": "EgressIgnoredPorts", "value": "22" } ] }, "containerDefinitions": [ { "name": "appName", "image": "appImage", "portMappings": [ { "containerPort": 9080, "hostPort": 9080, "protocol": "tcp" } ], "essential": true, "dependsOn": [ { "containerName": "envoy", "condition": "HEALTHY" } ] }, { "name": "envoy", "image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.29.6.1-prod", "essential": true, "environment": [ { "name": "APPMESH_VIRTUAL_NODE_NAME", "value": "mesh/apps/virtualNode/serviceB" }, { "name": "ENABLE_ENVOY_XRAY_TRACING", "value": "1" } ], "healthCheck": { "command": [ "CMD-SHELL", "curl -s http://localhost:9901/server_info | grep state | grep -q LIVE" ], "startPeriod": 10, "interval": 5, "timeout": 2, "retries": 3 }, "user": "1337" }, { "name": "xray-daemon", "image": "amazon/aws-xray-daemon", "user": "1337", "essential": true, "cpu": 32, "memoryReservation": 256, "portMappings": [ { "containerPort": 2000, "protocol": "udp" } ] } ], "requiresCompatibilities" : [ "EC2" ], "taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole", "executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole", "networkMode": "awsvpc" }

高度なトピック

App Mesh を使用した canary デプロイ

canary デプロイ/リリースは、アプリケーションの古いバージョンと新しくデプロイされたバージョンの間でトラフィックを切り替えるのに役立ちます。また、新しくデプロイされたバージョンのヘルスも監視します。新しいバージョンに問題がある場合、canary デプロイはトラフィックを古いバージョンに自動的に切り替えることができます。canary デプロイでは、アプリケーションのバージョン間でトラフィックを詳細に制御して切り替えることができます。

App Mesh ECSを使用して Amazon の Canary デプロイを実装する方法の詳細については、「App Mesh ECSを使用して Amazon の Canary デプロイでパイプラインを作成する」を参照してください。

注記

App Mesh のその他の例とチュートリアルについては、App Mesh サンプルリポジトリを参照してください。