View a markdown version of this page

Démarrage avec AWS App Mesh et Amazon ECS - AWS App Mesh
ScénarioConditions préalablesÉtape 1 : Créer un maillage et un service virtuelÉtape 2 : Créer un nœud virtuelÉtape 3 : Créer un routeur virtuel et un routageÉtape 4 : vérifier et créerÉtape 5 : Créer des ressources supplémentairesÉtape 6 : Mettre à jour les servicesRubriques avancées

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Démarrage avec AWS App Mesh et Amazon ECS

Important

Avis de fin de support : le 30 septembre 2026, AWS le support pour AWS App Mesh. Après le 30 septembre 2026, vous ne pourrez plus accéder à la AWS App Mesh console ni aux AWS App Mesh ressources. Pour plus d'informations, consultez ce billet de blog Migration depuis Amazon ECS Service Connect AWS App Mesh vers Amazon ECS.

Cette rubrique vous aide à utiliser AWS App Mesh un service réel qui s'exécute sur Amazon ECS. Ce didacticiel couvre les fonctionnalités de base de plusieurs types de ressources App Mesh.

Scénario

Pour illustrer l'utilisation d'App Mesh, supposons que vous disposez d'une application présentant les caractéristiques suivantes :

  • Comprend deux services nommés serviceA etserviceB.

  • Les deux services sont enregistrés dans un espace de noms nommé apps.local.

  • ServiceAcommunique avec serviceB plus de HTTP/2, port 80.

  • Vous avez déjà déployé la version 2 de serviceB et l'avez enregistrée avec le nom serviceBv2 dans l'espace de noms apps.local.

Les exigences requises sont les suivantes :

  • Vous souhaitez envoyer 75 % du trafic de destination serviceA à serviceB et 25 % du trafic de destination en serviceBv2 premier. En n'envoyant que 25 % àserviceBv2, vous pouvez vérifier que le site est exempt de bogues avant d'envoyer 100 % du trafic depuisserviceA.

  • Vous voulez pouvoir ajuster facilement la pondération du trafic afin que 100 % du trafic soit acheminé vers serviceBv2 une fois que sa fiabilité a été prouvée. Une fois que tout le trafic est envoyéserviceBv2, vous souhaitez arrêterserviceB.

  • Vous ne souhaitez pas avoir à modifier un code d'application ou un enregistrement de découverte de services existant pour que vos services actuels répondent aux exigences précédentes.

Pour répondre à vos besoins, vous décidez de créer un maillage de services App Mesh avec des services virtuels, des nœuds virtuels, un routeur virtuel et un itinéraire. Après avoir implémenté votre maillage, vous mettez à jour vos services pour utiliser le proxy Envoy. Une fois mis à jour, vos services communiquent entre eux via le proxy Envoy plutôt que directement entre eux.

Conditions préalables

Important

Avis de fin de support : le 30 septembre 2026, AWS le support pour AWS App Mesh. Après le 30 septembre 2026, vous ne pourrez plus accéder à la AWS App Mesh console ni aux AWS App Mesh ressources. Pour plus d'informations, consultez ce billet de blog Migration depuis Amazon ECS Service Connect AWS App Mesh vers Amazon ECS.

  • Une compréhension existante des concepts d'App Mesh. Pour de plus amples informations, veuillez consulter Qu'est-ce que AWS App Mesh?.

  • Une compréhension existante des concepts d'Amazon ECS. Pour plus d'informations, consultez Qu'est-ce qu'Amazon ECS dans le guide du développeur Amazon Elastic Container Service.

  • App Mesh prend en charge les services Linux enregistrés avec DNS AWS Cloud Map, ou les deux. Pour utiliser ce guide de démarrage, nous vous recommandons d'avoir trois services existants enregistrés avec DNS. Les procédures décrites dans cette rubrique supposent que les services existants sont nommés serviceA serviceBv2 et que tous les services sont détectables via un espace de noms nommé. serviceB apps.local

    Vous pouvez créer un maillage de service et ses ressources même si les services n'existent pas, mais vous ne pouvez pas utiliser le maillage tant que vous n'avez pas déployé des services réels. Pour plus d'informations sur la découverte de services sur Amazon ECS, consultez Service Discovery. Pour créer un service Amazon ECS avec service discovery, consultez Tutoriel : Création d'un service à l'aide de Service Discovery. Si aucun service n'est déjà en cours d'exécution, vous pouvez créer un service Amazon ECS avec service discovery.

Étape 1 : Créer un maillage et un service virtuel

Un maillage de service est une limite logique pour le trafic réseau entre les services qui résident dans celui-ci. Pour de plus amples informations, veuillez consulter Maillages de service. Un service virtuel est une abstraction d'un service réel. Pour de plus amples informations, veuillez consulter Services virtuels.

Créez les ressources suivantes :

  • Un maillage nommé apps, puisque tous les services du scénario sont enregistrés dans l'espace de noms apps.local.

  • Un service virtuel nommé serviceb.apps.local, car le service virtuel représente un service détectable avec ce nom et vous ne souhaitez pas modifier votre code pour référencer un autre nom. Un service virtuel nommé servicea.apps.local est ajouté dans une étape ultérieure.

Vous pouvez utiliser la AWS CLI version 1.18.116 Console de gestion AWS ou supérieure ou la version 2.0.38 ou supérieure pour effectuer les étapes suivantes. Si vous utilisez le AWS CLI, utilisez la aws --version commande pour vérifier la AWS CLI version que vous avez installée. Si vous n'avez pas installé la version 1.18.116 ou supérieure ou la version 2.0.38 ou supérieure, vous devez installer ou mettre à jour le. AWS CLI Sélectionnez l'onglet correspondant à l'outil que vous souhaitez utiliser.

Console de gestion AWS

  1. Ouvrez l'assistant de première exécution de la console App Mesh à https://console.aws.amazon.com/appmesh/get-started l'adresse.

  2. Pour Mesh name (Nom de maillage), entrez apps.

  3. Pour Virtual service name (Nom du service virtuel), entrez serviceb.apps.local.

  4. Pour continuer, choisissez Suivant.

AWS CLI

  1. Créez un maillage avec la commande create-mesh.

    aws appmesh create-mesh --mesh-name apps

  2. Créez un service virtuel avec la commande create-virtual-service.

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

Étape 2 : Créer un nœud virtuel

Un nœud virtuel tient lieu de pointeur logique vers un service réel. Pour de plus amples informations, veuillez consulter Nœuds virtuels.

Créez un nœud virtuel nommé serviceB, car l'un des nœuds virtuels représente le service réel nommé serviceB. Le service réel représenté par le nœud virtuel est détectable via DNS avec le nom d'hôte serviceb.apps.local. Alternativement, vous pouvez découvrir des services réels en utilisant AWS Cloud Map. Le nœud virtuel écoutera le trafic à l'aide du HTTP/2 protocole sur le port 80. D'autres protocoles sont également pris en charge, tout comme les vérifications de l'état. Vous allez créer des nœuds virtuels pour serviceA et serviceBv2 dans une étape ultérieure.

Console de gestion AWS

  1. Pour Virtual node name (Nom du nœud virtuel), entrez serviceB.

  2. Pour Service discovery method (Méthode de découverte de service), choisissez DNS et entrez serviceb.apps.local comme DNS hostname (Nom d'hôte DNS).

  3. Sous Configuration de l'écouteur, sélectionnez http2 comme Protocole et entrez 80 comme Port.

  4. Pour continuer, choisissez Suivant.

AWS CLI

  1. Créez un fichier nommé create-virtual-node-serviceb.json avec le contenu suivant :

    {
    "meshName": "apps",
    "spec": {
        "listeners": [
            {
                "portMapping": {
                    "port": 80,
                    "protocol": "http2"
                }
            }
        ],
        "serviceDiscovery": {
            "dns": {
                "hostname": "serviceB.apps.local"
            }
        }
    },
    "virtualNodeName": "serviceB"
}

  2. Créez le nœud virtuel avec la commande create-virtual-node en utilisant le fichier JSON en entrée.

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

Étape 3 : Créer un routeur virtuel et un routage

Les routeurs virtuels gèrent le trafic d'un ou de plusieurs services virtuels au sein de votre maillage. Pour plus d’informations, consultez Routeurs virtuels et Routes.

Créez les ressources suivantes :

  • Routeur virtuel nommé serviceB, car le service virtuel serviceB.apps.local n'initie pas de communication sortante avec un autre service. N'oubliez pas que le service virtuel que vous avez créé précédemment est une abstraction de votre service serviceb.apps.local réel. Le service virtuel envoie du trafic au routeur virtuel. Le routeur virtuel écoute le trafic à l'aide du HTTP/2 protocole du port 80. D'autres protocoles sont également pris en charge.

  • Un itinéraire nommé serviceB. Il achemine 100 % de son trafic vers le nœud serviceB virtuel. Le poids sera calculé ultérieurement une fois que vous aurez ajouté le nœud serviceBv2 virtuel. Bien que cet aspect ne soit pas couvert dans ce guide, vous pouvez ajouter des critères de filtre supplémentaires pour l'itinéraire et ajouter une stratégie de nouvelle tentative pour que le proxy Envoy fasse plusieurs tentatives pour envoyer du trafic vers un nœud virtuel lorsqu'il rencontre un problème de communication.

Console de gestion AWS

  1. Pour Virtual router name (Nom du routeur virtuel), entrez serviceB.

  2. Sous Configuration de l'écouteur, sélectionnez http2 comme Protocole et entrez 80 comme Port.

  3. Pour Route name (Nom de l'itinéraire), entrez serviceB.

  4. Pour Route type (Type d'itinéraire), choisissez http2.

  5. Dans la zone Nom du nœud virtuel, sous Configuration cible, sélectionnez serviceB et saisissez 100 le champ Poids.

  6. Dans Configuration de correspondance, choisissez une méthode.

  7. Pour continuer, choisissez Suivant.

AWS CLI

  1. Créez un routeur virtuel.

    1. Créez un fichier nommé create-virtual-router.json avec le contenu suivant :

      {
    "meshName": "apps",
    "spec": {
        "listeners": [
            {
                "portMapping": {
                    "port": 80,
                    "protocol": "http2"
                }
            }
        ]
    },
    "virtualRouterName": "serviceB"
}

    2. Créez le routeur virtuel avec la commande create-virtual-router en utilisant le fichier JSON en entrée.

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

  2. Créez un itinéraire.

    1. Créez un fichier nommé create-route.json avec le contenu suivant :

      {
    "meshName" : "apps",
    "routeName" : "serviceB",
    "spec" : {
        "httpRoute" : {
            "action" : {
                "weightedTargets" : [
                    {
                        "virtualNode" : "serviceB",
                        "weight" : 100
                    }
                ]
            },
            "match" : {
                "prefix" : "/"
            }
        }
    },
    "virtualRouterName" : "serviceB"
}

    2. Créez l'itinéraire avec la commande create-route en utilisant le fichier JSON en entrée.

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

Étape 4 : vérifier et créer

Vérifiez les paramètres par rapport aux instructions précédentes.

Console de gestion AWS

Choisissez Edit (Modifier) si vous devez apporter des modifications dans une section. Une fois que vous êtes satisfait des paramètres, choisissez Créer un maillage.

L'écran État affiche toutes les ressources de maillage créées. Vous pouvez voir les ressources créées dans la console en sélectionnant Afficher le maillage.

AWS CLI

Passez en revue les paramètres du maillage que vous avez créé à l'aide de la commande describe-mesh.

aws appmesh describe-mesh --mesh-name apps

Passez en revue les paramètres du service virtuel que vous avez créé avec la commande describe-virtual-service.

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

Passez en revue les paramètres du nœud virtuel que vous avez créé avec la commande describe-virtual-node.

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

Passez en revue les paramètres du routeur virtuel que vous avez créé avec la commande describe-virtual-router.

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

Passez en revue les paramètres de l'itinéraire que vous avez créé avec la commande describe-route.

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

Étape 5 : Créer des ressources supplémentaires

Pour terminer le scénario, vous devez :

  • Créer un nœud virtuel nommé serviceBv2 et un autre nommé serviceA. Les deux nœuds virtuels écoutent les requêtes sur HTTP/2 le port 80. Pour le nœud serviceA virtuel, configurez un backend de. serviceb.apps.local Tout le trafic sortant du nœud serviceA virtuel est envoyé au service virtuel nomméserviceb.apps.local. Bien que cela ne soit pas couvert dans ce guide, vous pouvez également spécifier un chemin d'accès de fichier vers lequel écrire les journaux d'accès pour un nœud virtuel.

  • Créez un service virtuel supplémentaire nomméservicea.apps.local, qui envoie tout le trafic directement au nœud serviceA virtuel.

  • Mettez à jour l'itinéraire serviceB que vous avez créé à l'étape précédente pour envoyer 75 % de son trafic vers le nœud virtuel serviceB et 25 % de son trafic vers le nœud virtuel serviceBv2. Au fil du temps, vous pouvez continuer à modifier les poids jusqu'à ce que serviceBv2 reçoive 100 % du trafic. Une fois que tout le trafic est envoyéserviceBv2, vous pouvez arrêter et interrompre le nœud serviceB virtuel et le service réel. Lorsque vous modifiez les pondérations, votre code ne nécessite aucune modification, car les noms de service serviceb.apps.local virtuels et réels ne changent pas. Rappelez-vous que le service virtuel serviceb.apps.local envoie du trafic au routeur virtuel, qui achemine le trafic vers les nœuds virtuels. Les noms de découverte de service pour les nœuds virtuels peuvent être modifiés à tout moment.

Console de gestion AWS

  1. Dans le panneau de navigation, sélectionnez Meshes (Maillages).

  2. Sélectionnez le maillage apps que vous avez créé à l'étape précédente.

  3. Dans le panneau de navigation de gauche, sélectionnez Virtual nodes (Nœuds virtuels).

  4. Choisissez Create virtual node (Créer un nœud virtuel).

  5. Pour Virtual node name (Nom de nœud virtuel), entrez serviceBv2, pour Service discovery method (Méthode de découverte de service), choisissez DNS, et pour DNS hostname (Nom d'hôte DNS), entrez servicebv2.apps.local.

  6. Pour la Configuration de l'écouteur, sélectionnez http2 comme Protocole et entrez 80 comme Port.

  7. Choisissez Create virtual node (Créer un nœud virtuel).

  8. Choisissez Create virtual node (Créer un nœud virtuel). Entrez serviceA comme Nom de nœud virtuel. Pour Méthode de découverte de service, choisissez DNS, et comme Nom d'hôte DNS, entrez servicea.apps.local.

  9. Dans la zone Entrez un nom de service virtuel sous Nouveau backend, entrez serviceb.apps.local.

  10. Sous Configuration de l'écouteur, choisissez http2 comme Protocole, entrez 80 comme Port, puis choisissez Créer un nœud virtuel.

  11. Dans le panneau de navigation de gauche, sélectionnez Virtual routers (Routeurs virtuels), puis choisissez le routeur virtuel serviceB dans la liste.

  12. Sous Routes (Itinéraires), sélectionnez l'itinéraire ServiceB que vous avez créé à l'étape précédente, puis choisissez Modifier.

  13. Sous Cibles, Virtual node name (Nom du nœud virtuel), modifiez la valeur de Weight (Pondération) de serviceB en 75.

  14. Choisissez Ajouter une cible, faites votre choix serviceBv2 dans la liste déroulante et définissez la valeur de Weight sur25.

  15. Choisissez Enregistrer.

  16. Dans le panneau de navigation de gauche, sélectionnez Services virtuels puis choisissez Créer un service virtuel.

  17. Entrez servicea.apps.local pour Nom du service virtuel, sélectionnez Nœud virtuel comme Fournisseur, sélectionnez serviceA comme Nœud virtuel, puis choisissez Créer un service virtuel.

AWS CLI

  1. Créez le nœud virtuel serviceBv2.

    1. Créez un fichier nommé create-virtual-node-servicebv2.json avec le contenu suivant :

      {
    "meshName": "apps",
    "spec": {
        "listeners": [
            {
                "portMapping": {
                    "port": 80,
                    "protocol": "http2"
                }
            }
        ],
        "serviceDiscovery": {
            "dns": {
                "hostname": "serviceBv2.apps.local"
            }
        }
    },
    "virtualNodeName": "serviceBv2"
}

    2. Créez le nœud virtuel.

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

  2. Créez le nœud virtuel serviceA.

    1. Créez un fichier nommé create-virtual-node-servicea.json avec le contenu suivant :

      {
   "meshName" : "apps",
   "spec" : {
      "backends" : [
         {
            "virtualService" : {
               "virtualServiceName" : "serviceb.apps.local"
            }
         }
      ],
      "listeners" : [
         {
            "portMapping" : {
               "port" : 80,
               "protocol" : "http2"
            }
         }
      ],
      "serviceDiscovery" : {
         "dns" : {
            "hostname" : "servicea.apps.local"
         }
      }
   },
   "virtualNodeName" : "serviceA"
}

    2. Créez le nœud virtuel.

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

  3. Mettez à jour le service virtuel serviceb.apps.local que vous avez créé lors d'une étape précédente pour envoyer son trafic vers le routeur virtuel serviceB. Lorsque le service virtuel a été créé à l'origine, il n'envoyait de trafic nulle part, car le routeur virtuel serviceB n'avait pas encore été créé.

    1. Créez un fichier nommé update-virtual-service.json avec le contenu suivant :

      {
   "meshName" : "apps",
   "spec" : {
      "provider" : {
         "virtualRouter" : {
            "virtualRouterName" : "serviceB"
         }
      }
   },
   "virtualServiceName" : "serviceb.apps.local"
}

    2. Mettez à jour le service virtuel avec la commande update-virtual-service.

      aws appmesh update-virtual-service --cli-input-json file://update-virtual-service.json

  4. Mettez à jour l'itinéraire serviceB que vous avez créé lors d'une étape précédente.

    1. Créez un fichier nommé update-route.json avec le contenu suivant :

      {
   "meshName" : "apps",
   "routeName" : "serviceB",
   "spec" : {
      "http2Route" : {
         "action" : {
            "weightedTargets" : [
               {
                  "virtualNode" : "serviceB",
                  "weight" : 75
               },
               {
                  "virtualNode" : "serviceBv2",
                  "weight" : 25
               }
            ]
         },
         "match" : {
            "prefix" : "/"
         }
      }
   },
   "virtualRouterName" : "serviceB"
}

    2. Mettez à jour l'itinéraire avec la commande update-route.

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

  5. Créez le service virtuel serviceA.

    1. Créez un fichier nommé create-virtual-servicea.json avec le contenu suivant :

      {
   "meshName" : "apps",
   "spec" : {
      "provider" : {
         "virtualNode" : {
            "virtualNodeName" : "serviceA"
         }
      }
   },
   "virtualServiceName" : "servicea.apps.local"
}

    2. Créez le service virtuel.

      aws appmesh create-virtual-service --cli-input-json file://create-virtual-servicea.json
Résumé du maillage

Avant de créer le maillage de service, vous aviez trois services réels nommés servicea.apps.local, serviceb.apps.local et servicebv2.apps.local. En plus des services réels, vous disposez désormais d'un maillage de service qui contient les ressources suivantes représentant les services réels :

  • Deux services virtuels. Le proxy envoie tout le trafic du service virtuel servicea.apps.local vers le service virtuel serviceb.apps.local via un routeur virtuel.

  • Trois nœuds virtuels nommés serviceA, serviceB et serviceBv2. Le proxy Envoy utilise les informations de découverte de service configurées pour les nœuds virtuels pour rechercher les adresses IP des services réels.

  • Un routeur virtuel avec un itinéraire qui indique au proxy Envoy d'acheminer 75 % du trafic entrant vers le nœud virtuel serviceB et 25 % du trafic vers le nœud virtuel serviceBv2.

Étape 6 : Mettre à jour les services

Après avoir créé votre maillage, vous devez effectuer les tâches suivantes :

  • Autorisez le proxy Envoy que vous déployez avec chaque tâche Amazon ECS à lire la configuration d'un ou de plusieurs nœuds virtuels. Pour plus d'informations sur l'autorisation du proxy, consultez Autorisation du proxy.

  • Mettez à jour chacune de vos définitions de tâches Amazon ECS existantes pour utiliser le proxy Envoy.

Informations d’identification

Le conteneur Envoy nécessite des Gestion des identités et des accès AWS informations d'identification pour signer les demandes envoyées au service App Mesh. Pour les tâches Amazon ECS déployées avec le type de lancement Amazon EC2, les informations d'identification peuvent provenir du rôle d'instance ou d'un rôle IAM de tâche. Les tâches Amazon ECS déployées avec Fargate sur des conteneurs Linux n'ont pas accès au serveur de métadonnées Amazon EC2 qui fournit les informations d'identification du profil IAM de l'instance. Pour fournir les informations d'identification, vous devez associer un rôle de tâche IAM à toutes les tâches déployées avec le type de conteneurs Fargate on Linux.

Si une tâche est déployée avec le type de lancement Amazon EC2 et que l'accès au serveur de métadonnées Amazon EC2 est bloqué, comme décrit dans l'annotation importante dans Rôle IAM pour les tâches, un rôle IAM de tâche doit également être associé à la tâche. Le rôle que vous attribuez à l'instance ou à la tâche doit être associé à une politique IAM, comme décrit dans la section Autorisation du proxy.

Pour mettre à jour votre définition de tâche à l'aide du AWS CLI

Vous utilisez la AWS CLI commande Amazon ECS register-task-definition. L'exemple de définition de tâche ci-dessous montre comment configurer App Mesh pour votre service.

Note

La configuration d'App Mesh pour Amazon ECS via la console n'est pas disponible.

Configuration du proxy

Pour configurer votre service Amazon ECS afin qu'il utilise App Mesh, la définition des tâches de votre service doit comporter la section de configuration du proxy suivante. Définissez la configuration de proxy type à APPMESH et le containerName à envoy. Définissez les valeurs de propriété suivantes en conséquence.

IgnoredUID

Le proxy Envoy n'achemine pas le trafic provenant de processus qui utilisent cet ID utilisateur. Vous pouvez choisir n'importe quel ID utilisateur souhaité pour cette valeur de propriété, mais cet ID doit être identique à celui du conteneur Envoy user dans la définition de tâche. Cette mise en correspondance permet à Envoy d'ignorer son propre trafic sans utiliser le proxy. Nos exemples utilisent 1337 à des fins historiques.

ProxyIngressPort

Il s'agit du port entrant pour le conteneur proxy Envoy. Définissez cette valeur à 15000.

ProxyEgressPort

Il s'agit du port sortant du conteneur proxy Envoy. Définissez cette valeur à 15001.

AppPorts

Spécifiez tous les ports entrants sur lesquels vos conteneurs d'applications écoutent. Dans cet exemple, le conteneur d'application écoute le port 9080. Le port que vous spécifiez doit correspondre au port configuré sur l'écouteur du nœud virtuel.

EgressIgnoredIPs

Envoy ne proxy pas de trafic vers ces adresses IP. Définissez cette valeur sur169.254.170.2,169.254.169.254, ce qui ignore le serveur de métadonnées Amazon EC2 et le point de terminaison des métadonnées des tâches Amazon ECS. Le point de terminaison des métadonnées fournit des rôles IAM pour les informations d'identification des tâches. Vous pouvez ajouter des adresses supplémentaires.

EgressIgnoredPorts

Vous pouvez ajouter une liste de ports séparés par des virgules. Envoy n'attribue pas de proxy pour le trafic vers ces ports. Même si vous ne mentionnez aucun port sur la liste, le port 22 est ignoré.

Note

Le nombre maximum de ports sortants pouvant être ignorés est de 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"
		}
	]
}
Dépendances Envoy de conteneur d'application

Les conteneurs d'application dans vos définitions de tâches doivent attendre que le proxy Envoy amorce et démarre avant de pouvoir démarrer. Pour vous en assurer, vous devez définir une dependsOn section dans chaque définition de conteneur d'application pour attendre que le conteneur Envoy produise le rapportHEALTHY. Le bloc de code suivant illustre un exemple de définition de conteneur d'application avec cette dépendance. Toutes les propriétés de l'exemple suivant sont obligatoires. Certaines valeurs de propriété sont également obligatoires, mais d'autres le sontreplaceable.

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

Définition de conteneur Envoy

Vos définitions de tâches Amazon ECS doivent contenir une image de conteneur App Mesh Envoy.

Toutes les régions prises en charge peuvent être Region-code remplacées par n'importe quelle région autre que me-south-1 ap-east-1 ap-southeast-3eu-south-1,il-central-1,, etaf-south-1.

Standard

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

FIPS-compliant

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

Standard

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

Standard

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

Standard

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

Standard

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

Standard

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

Standard

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

Standard

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

FIPS-compliant

public.ecr.aws/appmesh/aws-appmesh-envoy:v1.39.1.0-prod-fips
Important

Seule la version v1.9.0.0-prod ou ultérieure est prise en charge pour une utilisation avec App Mesh.

Vous devez utiliser l'image du conteneur App Mesh Envoy jusqu'à ce que l'équipe du projet Envoy fusionne les modifications qui prennent en charge App Mesh. Pour plus de détails, consultez le numéro de la GitHub feuille de route.

Toutes les propriétés de l'exemple suivant sont obligatoires. Certaines valeurs de propriété sont également obligatoires, mais d'autres le sontreplaceable.

Note

  • La définition de conteneur Envoy doit être marquée comme essential.

  • Nous vous recommandons d'allouer 512 des unités centrales et au moins 64 Mio de mémoire au conteneur Envoy. Sur Fargate, le niveau le plus bas que vous pourrez régler est de 1024 MiB de mémoire.

  • Le nom du nœud virtuel pour le service Amazon ECS doit être défini sur la valeur de la APPMESH_RESOURCE_ARN propriété. Cette propriété nécessite une version 1.15.0 ou une version ultérieure de l'image Envoy. Pour de plus amples informations, veuillez consulter Image de l'envoyé.

  • La valeur du paramètre user doit correspondre à la valeur IgnoredUID de la configuration du proxy de définition de tâche. Dans cet exemple, nous utilisons 1337.

  • Le contrôle de santé présenté ici attend que le conteneur Envoy démarre correctement avant de signaler à Amazon ECS que le conteneur Envoy est en bon état et prêt à démarrer les conteneurs d'applications.

  • Par défaut, App Mesh utilise le nom de la ressource que vous avez spécifiée dans APPMESH_RESOURCE_ARN lorsque Envoy fait référence à lui-même dans les métriques et les traces. Vous pouvez remplacer ce comportement en définissant la variable d'environnement APPMESH_RESOURCE_CLUSTER avec votre propre nom. Cette propriété nécessite une version 1.15.0 ou une version ultérieure de l'image Envoy. Pour de plus amples informations, veuillez consulter Image de l'envoyé.

Le bloc de code suivant présente un exemple de définition de conteneur Envoy.

{
	"name": "envoy",
	"image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.39.1.0-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"
}
Exemples de définitions de tâches

Les exemples suivants de définitions de tâches Amazon ECS montrent comment fusionner les exemples ci-dessus dans une définition de tâche pourtaskB. Des exemples sont fournis pour créer des tâches pour les deux types de lancement d'Amazon ECS avec ou sans utilisation AWS X-Ray. Modifiez les replaceable valeurs, le cas échéant, afin de créer des définitions de tâches pour les tâches nommées taskBv2 et taskA à partir du scénario. Substituez votre nom de maillage et le nom de nœud virtuel à la valeur APPMESH_RESOURCE_ARN et une liste des ports que votre application écoute pour la valeur de configuration de proxy AppPorts. Par défaut, App Mesh utilise le nom de la ressource que vous avez spécifiée dans APPMESH_RESOURCE_ARN lorsque Envoy fait référence à lui-même dans les métriques et les traces. Vous pouvez remplacer ce comportement en définissant la variable d'environnement APPMESH_RESOURCE_CLUSTER avec votre propre nom. Toutes les propriétés des exemples suivants sont obligatoires. Certaines valeurs de propriété sont également obligatoires, mais d'autres le sontreplaceable.

Si vous exécutez une tâche Amazon ECS comme décrit dans la section Informations d'identification, vous devez ajouter un rôle IAM de tâche existant aux exemples.

Important

Fargate doit utiliser une valeur de port supérieure à 1024.

Exemple Définition de tâches JSON pour Amazon ECS - Fargate sur les conteneurs Linux
{
   
   "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.39.1.0-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"
}
Exemple Définition de tâches JSON pour Amazon ECS avec AWS X-Ray - Fargate sur les conteneurs Linux

X-Ray vous permet de collecter des données sur les demandes traitées par une application et fournit des outils que vous pouvez utiliser pour visualiser le flux de trafic. L'utilisation du X-Ray pilote pour Envoy permet à Envoy de communiquer les informations de suivi à X-Ray. Vous pouvez activer le X-Ray suivi à l'aide de la configuration Envoy. En fonction de la configuration, Envoy envoie des données de suivi au X-Ray démon qui fonctionne comme un conteneur sidecar et le démon transmet les traces au service. X-Ray Une fois les traces publiées X-Ray, vous pouvez utiliser la X-Ray console pour visualiser le graphique des appels de service et demander les détails du suivi. Le code JSON suivant représente une définition de tâche permettant d'activer l'intégration X-Ray.

{
   
   
   "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.39.1.0-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"
}
Exemple Définition de tâche JSON pour Amazon ECS - Type de lancement 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.39.1.0-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"
}
Exemple Définition de tâches JSON pour Amazon ECS avec AWS X-Ray - Type de lancement 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.39.1.0-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"
}

Rubriques avancées

Déploiements Canary à l'aide d'App Mesh

Les déploiements et les versions de Canary vous permettent de basculer le trafic entre une ancienne version d'une application et une version récemment déployée. Il surveille également l'état de santé de la nouvelle version déployée. En cas de problème avec la nouvelle version, le déploiement de Canary peut automatiquement renvoyer le trafic vers l'ancienne version. Les déploiements de Canary vous permettent de transférer le trafic entre les versions des applications avec plus de contrôle.

Pour plus d'informations sur la mise en œuvre de déploiements Canary pour Amazon ECS à l'aide d'App Mesh, voir Création d'un pipeline avec des déploiements Canary pour Amazon ECS à l'aide d'App Mesh

Note

Pour plus d'exemples et de procédures pas à pas pour App Mesh, consultez le référentiel d'exemples App Mesh.