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.
# Premiers pas avec AWS App Mesh Amazon EC2
**Important**
Avis de fin de support : le 30 septembre 2026, AWS le support de. 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 [intitulé Migration from AWS App Mesh to Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Cette rubrique vous aide à utiliser AWS App Mesh un service réel qui s'exécute sur Amazon EC2. 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 :
+ Se compose de deux services nommés `serviceA` et`serviceB`.
+ Les deux services sont enregistrés dans un espace de noms nommé `apps.local`.
+ `ServiceA` communique avec `serviceB` via 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 `serviceA` vers `serviceB` et 25 % du trafic vers le `serviceBv2` premier. En n'envoyant que 25 % du trafic vers`serviceBv2`, vous pouvez vérifier qu'il ne contient aucun bogue avant d'envoyer 100 % du trafic depuis`serviceA`.
+ 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 l'arrêter`serviceB`.
+ Vous ne souhaitez pas avoir à modifier le code d'application existant ni à vous inscrire à la découverte de services 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
App Mesh prend en charge les services Linux enregistrés auprès du DNS AWS Cloud Map, ou des deux. Pour utiliser ce guide de démarrage, nous vous recommandons d'avoir trois services existants enregistrés avec DNS. 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.
Si aucun service n'est déjà en cours d'exécution, vous pouvez lancer des instances Amazon EC2 et y déployer des applications. Pour plus d'informations, consultez [Tutoriel : Démarrage avec les instances Linux Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-lamp-amazon-linux-2.html) dans le guide de l'utilisateur Amazon EC2. Les étapes restantes supposent que les services réels sont nommés `serviceA`, `serviceB` et `serviceBv2`, et que tous les services peuvent être détectés via un espace de noms nommé `apps.local`.
## É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](meshes.md). Un service virtuel est une abstraction d'un service réel. Pour de plus amples informations, veuillez consulter [Services virtuels](virtual_services.md).
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 Management Console AWS CLI version 1.18.116 ou supérieure ou 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 installée. Si la version 1.18.116 ou supérieure ou 2.0.38 ou supérieure n'est pas installée, vous devez [installer](https://docs.aws.amazon.com/cli/latest/reference/appmesh/cli-chap-install.html) ou mettre à jour le. AWS CLI Sélectionnez l'onglet correspondant à l'outil que vous souhaitez utiliser.
------
#### [ AWS Management Console ]
1. Ouvrez l'assistant de première exécution de la console App Mesh au démarrage [https://console.aws.amazon.com/appmesh/.](https://console.aws.amazon.com/appmesh/get-started)
1. Pour **Mesh name (Nom de maillage)**, entrez **apps**.
1. Pour **Virtual service name (Nom du service virtuel)**, entrez **serviceb.apps.local**.
1. Pour continuer, choisissez **Suivant**.
------
#### [ AWS CLI ]
1. Créez un maillage avec la commande `[create-mesh](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-mesh.html)`.
```
aws appmesh create-mesh --mesh-name apps
```
1. Créez un service virtuel avec la commande `[create-virtual-service](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-service.html)`.
```
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](virtual_nodes.md).
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`. Vous pouvez également découvrir les services réels en utilisant AWS Cloud Map. Le nœud virtuel écoute le trafic à l'aide du protocole HTTP/2 sur le port 80. D'autres protocoles sont également pris en charge, tout comme les vérifications de l'état. Vous créez des nœuds virtuels pour `serviceA` et `serviceBv2` lors d'une étape ultérieure.
------
#### [ AWS Management Console ]
1. Pour **Virtual node name (Nom du nœud virtuel)**, entrez **serviceB**.
1. 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)**.
1. Sous **Configuration de l'écouteur**, sélectionnez **http2** comme **Protocole** et entrez **80** comme **Port**.
1. 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"
}
```
1. Créez le nœud virtuel avec la [create-virtual-node](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-node.html)commande en utilisant le fichier JSON comme 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](virtual_routers.md) et [Routes](routes.md).
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 protocole HTTP/2 sur le 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 déterminé 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.
------
#### [ AWS Management Console ]
1. Pour **Virtual router name (Nom du routeur virtuel)**, entrez **serviceB**.
1. Sous **Configuration de l'écouteur**, sélectionnez **http2** comme **Protocole** et entrez **80** comme **Port**.
1. Pour **Route name (Nom de l'itinéraire)**, entrez **serviceB**.
1. Pour **Route type (Type d'itinéraire)**, choisissez **http2**.
1. Pour le **nom du nœud virtuel** sous **Configuration cible**, sélectionnez `serviceB` et entrez **100** le **poids**.
1. Sous **Configuration de correspondance**, choisissez une **méthode**.
1. 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"
}
```
1. Créez le routeur virtuel avec la [create-virtual-router](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-router.html)commande en utilisant le fichier JSON comme entrée.
```
aws appmesh create-virtual-router --cli-input-json file://create-virtual-router.json
```
1. 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"
}
```
1. Créez l'itinéraire avec la commande [create-route](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-route.html) 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.
------
#### [ AWS Management Console ]
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](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-mesh.html).
```
aws appmesh describe-mesh --mesh-name apps
```
Vérifiez les paramètres du service virtuel que vous avez créé à l'aide de la [describe-virtual-service](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-service.html)commande.
```
aws appmesh describe-virtual-service --mesh-name apps --virtual-service-name serviceb.apps.local
```
Vérifiez les paramètres du nœud virtuel que vous avez créé à l'aide de la [describe-virtual-node](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-node.html)commande.
```
aws appmesh describe-virtual-node --mesh-name apps --virtual-node-name serviceB
```
Vérifiez les paramètres du routeur virtuel que vous avez créé à l'aide de la [describe-virtual-router](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-router.html)commande.
```
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](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-route.html).
```
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 demandes sur le port HTTP/2 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.
------
#### [ AWS Management Console ]
1. Dans le panneau de navigation, sélectionnez **Meshes (Maillages)**.
1. Sélectionnez le maillage `apps` que vous avez créé à l'étape précédente.
1. Dans le panneau de navigation de gauche, sélectionnez **Virtual nodes (Nœuds virtuels)**.
1. Choisissez **Create virtual node (Créer un nœud virtuel)**.
1. 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**.
1. Pour la **Configuration de l'écouteur**, sélectionnez **http2** comme **Protocole** et entrez **80** comme **Port**.
1. Choisissez **Create virtual node (Créer un nœud virtuel)**.
1. 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**.
1. Dans la zone **Entrez un nom de service virtuel** sous **Nouveau backend**, entrez **serviceb.apps.local**.
1. Sous **Configuration de l'écouteur**, choisissez **http2** comme **Protocole**, entrez **80** comme **Port**, puis choisissez **Créer un nœud virtuel**.
1. Dans le panneau de navigation de gauche, sélectionnez** Virtual routers (Routeurs virtuels)**, puis choisissez le routeur virtuel `serviceB` dans la liste.
1. Sous **Routes (Itinéraires)**, sélectionnez l'itinéraire `ServiceB` que vous avez créé à l'étape précédente, puis choisissez **Modifier**.
1. Sous **Cibles**, **Virtual node name (Nom du nœud virtuel)**, modifiez la valeur de **Weight (Pondération)** de `serviceB` en **75**.
1. Choisissez **Ajouter un objectif**, choisissez `serviceBv2` dans la liste déroulante et définissez la valeur du **poids** sur**25**.
1. Choisissez **Enregistrer**.
1. Dans le panneau de navigation de gauche, sélectionnez **Services virtuels** puis choisissez **Créer un service virtuel**.
1. 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"
}
```
1. Créez le nœud virtuel.
```
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicebv2.json
```
1. 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"
}
```
1. Créez le nœud virtuel.
```
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicea.json
```
1. 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"
}
```
1. Mettez à jour le service virtuel à l'aide de la [update-virtual-service](https://docs.aws.amazon.com/cli/latest/reference/appmesh/update-virtual-service.html)commande.
```
aws appmesh update-virtual-service --cli-input-json file://update-virtual-service.json
```
1. 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"
}
```
1. Mettez à jour l'itinéraire avec la commande [update-route](https://docs.aws.amazon.com/cli/latest/reference/appmesh/update-route.html).
```
aws appmesh update-route --cli-input-json file://update-route.json
```
1. 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"
}
```
1. 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 service à lire la configuration d'un ou de plusieurs nœuds virtuels. Pour plus d'informations sur la façon d'autoriser le proxy, consultez[Autorisation Envoy Proxy](proxy-authorization.md).
+ Pour mettre à jour votre service existant, suivez les étapes ci-dessous.
**Pour configurer une instance Amazon EC2 en tant que membre d'un nœud virtuel**
1. Créez un rôle IAM.
1. Créez un fichier nommé `ec2-trust-relationship.json` avec les contenus suivants.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. Créez un rôle IAM à l'aide de la commande suivante.
```
aws iam create-role --role-name mesh-virtual-node-service-b --assume-role-policy-document file://ec2-trust-relationship.json
```
1. Attachez au rôle des politiques IAM qui lui permettent de lire depuis Amazon ECR et uniquement la configuration d'un nœud virtuel App Mesh spécifique.
1. Créez un fichier nommé `virtual-node-policy.json` avec le contenu suivant. `apps` est le nom du maillage que vous avez créé dans [Étape 1 : Créer un maillage et un service virtuel](#create-mesh-and-virtual-service) et `serviceB` le nom du nœud virtuel que vous avez créé dans [Étape 2 : Créer un nœud virtuel](#create-virtual-node). *111122223333*Remplacez-le par votre identifiant de compte et *us-west-2* par la région dans laquelle vous avez créé votre maillage.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "appmesh:StreamAggregatedResources",
"Resource": [
"arn:aws:appmesh:us-west-2:111122223333:mesh/apps/virtualNode/serviceB"
]
}
]
}
```
------
1. Créez la politique à l'aide de la commande suivante.
```
aws iam create-policy --policy-name virtual-node-policy --policy-document file://virtual-node-policy.json
```
1. Attachez la politique que vous avez créée à l'étape précédente au rôle afin que le rôle puisse lire la configuration uniquement pour le nœud `serviceB` virtuel depuis App Mesh.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::111122223333:policy/virtual-node-policy --role-name mesh-virtual-node-service-b
```
1. Associez la politique `AmazonEC2ContainerRegistryReadOnly` gérée au rôle afin qu'il puisse extraire l'image du conteneur Envoy depuis Amazon ECR.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly --role-name mesh-virtual-node-service-b
```
1. [Lancez une instance Amazon EC2 avec le rôle IAM](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#launch-instance-with-role) que vous avez créé.
1. Connectez-vous à votre instance via SSH.
1. Installez Docker et le AWS CLI sur votre instance conformément à la documentation de votre système d'exploitation.
1. Authentifiez-vous auprès du référentiel Envoy Amazon ECR de la région à partir de laquelle vous souhaitez que votre client Docker extrait l'image.
+ Toutes les régions sauf `me-south-1``ap-east-1`,`ap-southeast-3`,`eu-south-1`,`il-central-1`, et`af-south-1`. Vous pouvez *us-west-2* remplacer par n'importe quelle [région prise en charge](https://docs.aws.amazon.com/general/latest/gr/appmesh.html) `me-south-1``ap-east-1`, à l'exception de `ap-southeast-3``eu-south-1`,`il-central-1`,, et`af-south-1`.
```
$aws ecr get-login-password \
--region us-west-2 \
| docker login \
--username AWS \
--password-stdin 840364872350.dkr.ecr.us-west-2.amazonaws.com
```
+ Région `me-south-1`
```
$aws ecr get-login-password \
--region me-south-1 \
| docker login \
--username AWS \
--password-stdin 772975370895.dkr.ecr.me-south-1.amazonaws.com
```
+ Région `ap-east-1`
```
$aws ecr get-login-password \
--region ap-east-1 \
| docker login \
--username AWS \
--password-stdin 856666278305.dkr.ecr.ap-east-1.amazonaws.com
```
1. Exécutez l'une des commandes suivantes pour démarrer le conteneur App Mesh Envoy sur votre instance, en fonction de la région d'où vous souhaitez extraire l'image. Les *serviceB* valeurs *apps* et sont les noms de maillage et de nœud virtuel définis dans le scénario. Ces informations indiquent au proxy la configuration du nœud virtuel à lire dans App Mesh. Pour terminer le scénario, vous devez également suivre ces étapes pour les instances Amazon EC2 qui hébergent les services représentés par les nœuds `serviceA` virtuels `serviceBv2` et. Pour votre propre application, remplacez ces valeurs par les vôtres.
+ Toutes les régions sauf `me-south-1``ap-east-1`,`ap-southeast-3`,`eu-south-1`,`il-central-1`, et`af-south-1`. Vous pouvez *Region-code* remplacer par n'importe quelle [région prise en charge](https://docs.aws.amazon.com/general/latest/gr/appmesh.html) `me-south-1``ap-east-1`, à l'exception des `af-south-1` régions `ap-southeast-3``eu-south-1`,`il-central-1`,,, et. Vous pouvez remplacer `1337` par n'importe quelle valeur comprise entre `0` et `2147483647`.
```
sudo docker run --detach --env APPMESH_RESOURCE_ARN=mesh/apps/virtualNode/serviceB \
-u 1337 --network host 840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
+ Région `me-south-1`. Vous pouvez remplacer `1337` par n'importe quelle valeur comprise entre `0` et `2147483647`.
```
sudo docker run --detach --env APPMESH_RESOURCE_ARN=mesh/apps/virtualNode/serviceB \
-u 1337 --network host 772975370895.dkr.ecr.me-south-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
+ Région `ap-east-1`. Vous pouvez remplacer `1337` par n'importe quelle valeur comprise entre `0` et `2147483647`.
```
sudo docker run --detach --env APPMESH_RESOURCE_ARN=mesh/apps/virtualNode/serviceB \
-u 1337 --network host 856666278305.dkr.ecr.ap-east-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
**Note**
La `APPMESH_RESOURCE_ARN` 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é](envoy.md).
**Important**
Seule la version v1.9.0.0-prod ou ultérieure est prise en charge pour une utilisation avec App Mesh.
1. Sélectionnez `Show more` ci-dessous. Créez un fichier nommé `envoy-networking.sh` sur votre instance avec le contenu suivant. *8000*Remplacez-le par le port utilisé par le code de votre application pour le trafic entrant. Vous pouvez modifier la valeur de `APPMESH_IGNORE_UID`, mais la valeur doit être la même que celle que vous avez spécifiée à l'étape précédente, par exemple `1337`. Vous pouvez ajouter des adresses supplémentaires `APPMESH_EGRESS_IGNORED_IP` si nécessaire. Ne modifiez pas d'autres lignes.
```
#!/bin/bash -e
#
# Start of configurable options
#
#APPMESH_START_ENABLED="0"
APPMESH_IGNORE_UID="1337"
APPMESH_APP_PORTS="8000"
APPMESH_ENVOY_EGRESS_PORT="15001"
APPMESH_ENVOY_INGRESS_PORT="15000"
APPMESH_EGRESS_IGNORED_IP="169.254.169.254,169.254.170.2"
# Enable routing on the application start.
[ -z "$APPMESH_START_ENABLED" ] && APPMESH_START_ENABLED="0"
# Enable IPv6.
[ -z "$APPMESH_ENABLE_IPV6" ] && APPMESH_ENABLE_IPV6="0"
# Egress traffic from the processess owned by the following UID/GID will be ignored.
if [ -z "$APPMESH_IGNORE_UID" ] && [ -z "$APPMESH_IGNORE_GID" ]; then
echo "Variables APPMESH_IGNORE_UID and/or APPMESH_IGNORE_GID must be set."
echo "Envoy must run under those IDs to be able to properly route it's egress traffic."
exit 1
fi
# Port numbers Application and Envoy are listening on.
if [ -z "$APPMESH_ENVOY_EGRESS_PORT" ]; then
echo "APPMESH_ENVOY_EGRESS_PORT must be defined to forward traffic from the application to the proxy."
exit 1
fi
# If an app port was specified, then we also need to enforce the proxies ingress port so we know where to forward traffic.
if [ ! -z "$APPMESH_APP_PORTS" ] && [ -z "$APPMESH_ENVOY_INGRESS_PORT" ]; then
echo "APPMESH_ENVOY_INGRESS_PORT must be defined to forward traffic from the APPMESH_APP_PORTS to the proxy."
exit 1
fi
# Comma separated list of ports for which egress traffic will be ignored, we always refuse to route SSH traffic.
if [ -z "$APPMESH_EGRESS_IGNORED_PORTS" ]; then
APPMESH_EGRESS_IGNORED_PORTS="22"
else
APPMESH_EGRESS_IGNORED_PORTS="$APPMESH_EGRESS_IGNORED_PORTS,22"
fi
#
# End of configurable options
#
function initialize() {
echo "=== Initializing ==="
if [ ! -z "$APPMESH_APP_PORTS" ]; then
iptables -t nat -N APPMESH_INGRESS
if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then
ip6tables -t nat -N APPMESH_INGRESS
fi
fi
iptables -t nat -N APPMESH_EGRESS
if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then
ip6tables -t nat -N APPMESH_EGRESS
fi
}
function enable_egress_routing() {
# Stuff to ignore
[ ! -z "$APPMESH_IGNORE_UID" ] && \
iptables -t nat -A APPMESH_EGRESS \
-m owner --uid-owner $APPMESH_IGNORE_UID \
-j RETURN
[ ! -z "$APPMESH_IGNORE_GID" ] && \
iptables -t nat -A APPMESH_EGRESS \
-m owner --gid-owner $APPMESH_IGNORE_GID \
-j RETURN
[ ! -z "$APPMESH_EGRESS_IGNORED_PORTS" ] && \
for IGNORED_PORT in $(echo "$APPMESH_EGRESS_IGNORED_PORTS" | tr "," "\n"); do
iptables -t nat -A APPMESH_EGRESS \
-p tcp \
-m multiport --dports "$IGNORED_PORT" \
-j RETURN
done
if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then
# Stuff to ignore ipv6
[ ! -z "$APPMESH_IGNORE_UID" ] && \
ip6tables -t nat -A APPMESH_EGRESS \
-m owner --uid-owner $APPMESH_IGNORE_UID \
-j RETURN
[ ! -z "$APPMESH_IGNORE_GID" ] && \
ip6tables -t nat -A APPMESH_EGRESS \
-m owner --gid-owner $APPMESH_IGNORE_GID \
-j RETURN
[ ! -z "$APPMESH_EGRESS_IGNORED_PORTS" ] && \
for IGNORED_PORT in $(echo "$APPMESH_EGRESS_IGNORED_PORTS" | tr "," "\n"); do
ip6tables -t nat -A APPMESH_EGRESS \
-p tcp \
-m multiport --dports "$IGNORED_PORT" \
-j RETURN
done
fi
# The list can contain both IPv4 and IPv6 addresses. We will loop over this list
# to add every IPv4 address into `iptables` and every IPv6 address into `ip6tables`.
[ ! -z "$APPMESH_EGRESS_IGNORED_IP" ] && \
for IP_ADDR in $(echo "$APPMESH_EGRESS_IGNORED_IP" | tr "," "\n"); do
if [[ $IP_ADDR =~ .*:.* ]]
then
[ "$APPMESH_ENABLE_IPV6" == "1" ] && \
ip6tables -t nat -A APPMESH_EGRESS \
-p tcp \
-d "$IP_ADDR" \
-j RETURN
else
iptables -t nat -A APPMESH_EGRESS \
-p tcp \
-d "$IP_ADDR" \
-j RETURN
fi
done
# Redirect everything that is not ignored
iptables -t nat -A APPMESH_EGRESS \
-p tcp \
-j REDIRECT --to $APPMESH_ENVOY_EGRESS_PORT
# Apply APPMESH_EGRESS chain to non local traffic
iptables -t nat -A OUTPUT \
-p tcp \
-m addrtype ! --dst-type LOCAL \
-j APPMESH_EGRESS
if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then
# Redirect everything that is not ignored ipv6
ip6tables -t nat -A APPMESH_EGRESS \
-p tcp \
-j REDIRECT --to $APPMESH_ENVOY_EGRESS_PORT
# Apply APPMESH_EGRESS chain to non local traffic ipv6
ip6tables -t nat -A OUTPUT \
-p tcp \
-m addrtype ! --dst-type LOCAL \
-j APPMESH_EGRESS
fi
}
function enable_ingress_redirect_routing() {
# Route everything arriving at the application port to Envoy
iptables -t nat -A APPMESH_INGRESS \
-p tcp \
-m multiport --dports "$APPMESH_APP_PORTS" \
-j REDIRECT --to-port "$APPMESH_ENVOY_INGRESS_PORT"
# Apply AppMesh ingress chain to everything non-local
iptables -t nat -A PREROUTING \
-p tcp \
-m addrtype ! --src-type LOCAL \
-j APPMESH_INGRESS
if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then
# Route everything arriving at the application port to Envoy ipv6
ip6tables -t nat -A APPMESH_INGRESS \
-p tcp \
-m multiport --dports "$APPMESH_APP_PORTS" \
-j REDIRECT --to-port "$APPMESH_ENVOY_INGRESS_PORT"
# Apply AppMesh ingress chain to everything non-local ipv6
ip6tables -t nat -A PREROUTING \
-p tcp \
-m addrtype ! --src-type LOCAL \
-j APPMESH_INGRESS
fi
}
function enable_routing() {
echo "=== Enabling routing ==="
enable_egress_routing
if [ ! -z "$APPMESH_APP_PORTS" ]; then
enable_ingress_redirect_routing
fi
}
function disable_routing() {
echo "=== Disabling routing ==="
iptables -t nat -F APPMESH_INGRESS
iptables -t nat -F APPMESH_EGRESS
if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then
ip6tables -t nat -F APPMESH_INGRESS
ip6tables -t nat -F APPMESH_EGRESS
fi
}
function dump_status() {
echo "=== iptables FORWARD table ==="
iptables -L -v -n
echo "=== iptables NAT table ==="
iptables -t nat -L -v -n
if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then
echo "=== ip6tables FORWARD table ==="
ip6tables -L -v -n
echo "=== ip6tables NAT table ==="
ip6tables -t nat -L -v -n
fi
}
function clean_up() {
disable_routing
ruleNum=$(iptables -L PREROUTING -t nat --line-numbers | grep APPMESH_INGRESS | cut -d " " -f 1)
iptables -t nat -D PREROUTING $ruleNum
ruleNum=$(iptables -L OUTPUT -t nat --line-numbers | grep APPMESH_EGRESS | cut -d " " -f 1)
iptables -t nat -D OUTPUT $ruleNum
iptables -t nat -X APPMESH_INGRESS
iptables -t nat -X APPMESH_EGRESS
if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then
ruleNum=$(ip6tables -L PREROUTING -t nat --line-numbers | grep APPMESH_INGRESS | cut -d " " -f 1)
ip6tables -t nat -D PREROUTING $ruleNum
ruleNum=$(ip6tables -L OUTPUT -t nat --line-numbers | grep APPMESH_EGRESS | cut -d " " -f 1)
ip6tables -t nat -D OUTPUT $ruleNum
ip6tables -t nat -X APPMESH_INGRESS
ip6tables -t nat -X APPMESH_EGRESS
fi
}
function main_loop() {
echo "=== Entering main loop ==="
while read -p '> ' cmd; do
case "$cmd" in
"quit")
clean_up
break
;;
"status")
dump_status
;;
"enable")
enable_routing
;;
"disable")
disable_routing
;;
*)
echo "Available commands: quit, status, enable, disable"
;;
esac
done
}
function print_config() {
echo "=== Input configuration ==="
env | grep APPMESH_ || true
}
print_config
initialize
if [ "$APPMESH_START_ENABLED" == "1" ]; then
enable_routing
fi
main_loop
```
1. Pour configurer les règles `iptables` afin d'acheminer le trafic d'application vers le proxy Envoy, exécutez le script que vous avez créé à l'étape précédente.
```
sudo ./envoy-networking.sh
```
1. Démarrez votre code d'application de nœud virtuel.
**Note**
Pour plus d'exemples et de procédures pas à pas pour App Mesh, consultez le référentiel d'[exemples d'App Mesh](https://github.com/aws/aws-app-mesh-examples).