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.
# Commencer à utiliser App Mesh
**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).
Vous pouvez utiliser App Mesh avec des applications que vous déployez sur Amazon ECS, Kubernetes (que vous déployez sur vos propres instances Amazon EC2 ou exécutées sur Amazon EKS) et Amazon EC2. Pour commencer à utiliser App Mesh, sélectionnez l'un des services sur lesquels des applications sont déployées et que vous souhaitez utiliser avec App Mesh. Vous pouvez toujours activer les applications des autres services pour qu'elles fonctionnent également avec App Mesh après avoir terminé l'un des guides de démarrage.
**Topics**
+ [Commencer à utiliser Amazon ECS AWS App Mesh et à utiliser Amazon ECS](getting-started-ecs.md)
+ [Premiers pas avec AWS App Mesh Kubernetes](getting-started-kubernetes.md)
+ [Premiers pas avec AWS App Mesh Amazon EC2](getting-started-ec2.md)
+ [Exemples d'App Mesh](examples.md)
# Commencer à utiliser Amazon ECS AWS App Mesh et à utiliser Amazon ECS
**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 AWS App Mesh à utiliser 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 :
+ 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
**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).
+ Compréhension existante des concepts de l'App Mesh. Pour de plus amples informations, veuillez consulter [Qu'est-ce que c'est AWS App Mesh ?](what-is-app-mesh.md).
+ Compréhension existante des ECSs concepts d'Amazon. Pour plus d'informations, consultez la section [Qu'est-ce qu'Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) dans le manuel Amazon Elastic Container Service Developer Guide.
+ 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. 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](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html). Pour créer un service Amazon ECS avec service discovery, consultez [Tutoriel : Création d'un service à l'aide de Service Discovery](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-discovery.html). Si aucun service n'est déjà en cours d'exécution, vous pouvez [créer un service Amazon ECS avec service discovery](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-discovery.html).
## É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 écoutera le trafic en utilisant le protocole HTTP/2 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.
------
#### [ 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 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](https://docs.aws.amazon.com/app-mesh/latest/userguide/proxy-authorization.html).
+ 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](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/instance_IAM_role.html) [IAM de tâche](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). Les tâches Amazon ECS déployées avec Fargate sur les 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 sur 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 le* rôle [IAM pour les tâches, un rôle](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) 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 [Autorisation du proxy](https://docs.aws.amazon.com/app-mesh/latest/userguide/proxy-authorization.html).
**Pour mettre à jour votre définition de tâche à l'aide du AWS CLI**
Vous utilisez la AWS CLI commande Amazon ECS [https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html). 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.
### Définition de tâche json
**Configuration du proxy**
Pour configurer votre service Amazon ECS afin d'utiliser App Mesh, la définition de tâche 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 les ports entrants que 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 sur`169.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é.
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 assurer que cela se produise, vous définissez une `dependsOn` section dans chaque définition de conteneur d'application pour attendre que le conteneur Envoy soit signalé sous le nom de`HEALTHY`. 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 sont*replaceable*.
```
{
"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](https://docs.aws.amazon.com/general/latest/gr/appmesh.html) peuvent être *Region-code* remplacées par n'importe quelle région autre que `me-south-1` `ap-east-1``ap-southeast-3`,`eu-south-1`,`il-central-1`,, et`af-south-1`.
Standard
```
840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
Conforme à la norme FIPS
```
840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod-fips
```
`me-south-1`
Standard
```
772975370895.dkr.ecr.me-south-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`ap-east-1`
Standard
```
856666278305.dkr.ecr.ap-east-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`ap-southeast-3`
Standard
```
909464085924.dkr.ecr.ap-southeast-3.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`eu-south-1`
Standard
```
422531588944.dkr.ecr.eu-south-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`il-central-1`
Standard
```
564877687649.dkr.ecr.il-central-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`af-south-1`
Standard
```
924023996002.dkr.ecr.af-south-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`Public repository`
Standard
```
public.ecr.aws/appmesh/aws-appmesh-envoy:v1.34.13.0-prod
```
Conforme à la norme FIPS
```
public.ecr.aws/appmesh/aws-appmesh-envoy:v1.34.13.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 compatibles avec App Mesh. Pour plus de détails, consultez le [numéro de la GitHub feuille de route](https://github.com/aws/aws-app-mesh-roadmap/issues/10).
Toutes les propriétés de l'exemple suivant sont obligatoires. Certaines valeurs de propriété sont également obligatoires, mais d'autres le sont*replaceable*.
**Note**
La définition de conteneur Envoy doit être marquée comme `essential`.
Nous recommandons d'allouer des unités de `512` processeur et au moins des `64` MiB de mémoire au conteneur Envoy. Sur Fargate, le minimum que vous pourrez définir est le `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é](envoy.md).
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 test de santé présenté ici attend que le conteneur Envoy démarre correctement avant de signaler à Amazon ECS que le conteneur Envoy est sain et prêt pour le démarrage des 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é](envoy.md).
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.34.13.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 de définitions de tâches Amazon ECS suivants montrent comment fusionner les exemples ci-dessus dans une définition de tâche pour`taskB`. Des exemples sont fournis pour créer des tâches pour les deux types de lancement Amazon ECS avec ou sans utilisation AWS X-Ray. Modifiez les *replaceable* valeurs, le cas échéant, pour 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 sont*replaceable*.
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](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) existant aux exemples.
**Important**
Fargate doit utiliser une valeur de port supérieure à 1024.
**Example Définition de tâche 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.34.13.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"
}
```
**Example Définition de tâches JSON pour Amazon ECS avec AWS X-Ray - Fargate sur des 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 pilote X-Ray pour Envoy permet à Envoy de communiquer des informations de suivi à X-Ray. Vous pouvez activer le suivi X-Ray à l'aide de la [configuration Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html). Sur la base de la configuration, Envoy envoie des données de suivi au daemon X-Ray qui fonctionne comme [un conteneur annexe](https://docs.aws.amazon.com/xray/latest/devguide/xray-daemon-ecs.html) et le daemon transmet les traces au service X-Ray. Une fois les traces publiées sur X-Ray, vous pouvez utiliser la console X-Ray pour visualiser le graphique des appels de service et demander les détails du suivi. Le JSON suivant représente une définition de tâche pour activer l'intégration de 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.34.13.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"
}
```
**Example 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.34.13.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"
}
```
**Example Définition de tâche JSON pour Amazon ECS avec le 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.34.13.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 aident à transférer 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 faire revenir le trafic à l'ancienne version. Les déploiements Canary vous permettent de transférer le trafic entre les versions de l'application avec un meilleur contrôle.
Pour plus d'informations sur la mise en œuvre de déploiements Canary pour Amazon ECS à l'aide d'App Mesh, consultez [Créer un pipeline avec des déploiements Canary pour Amazon ECS à l'aide](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/) d'App Mesh
**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).
# Premiers pas avec AWS App Mesh Kubernetes
**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).
Lorsque vous intégrez AWS App Mesh Kubernetes à l'aide du contrôleur App Mesh pour Kubernetes, vous gérez les ressources App Mesh, telles que les maillages, les services virtuels, les nœuds virtuels, les routeurs virtuels et les itinéraires via Kubernetes. Vous ajoutez également automatiquement les images du conteneur App Mesh aux spécifications du pod Kubernetes. Ce didacticiel vous guide tout au long de l'installation du contrôleur App Mesh pour Kubernetes afin de permettre cette intégration.
Le contrôleur est accompagné par le déploiement des définitions de ressources personnalisées Kubernetes suivantes : `meshes`, `virtual services`, `virtual nodes` et `virtual routers`. Le contrôleur surveille la création, la modification et la suppression des ressources personnalisées et apporte des modifications aux ressources App Mesh[Maillages de service](meshes.md),[Services virtuels](virtual_services.md),[Nœuds virtuels](virtual_nodes.md), [Passerelles virtuelles](virtual_gateways.md)[Routes de passerelle](gateway-routes.md), [Routeurs virtuels](virtual_routers.md) (y compris[Routes](routes.md)) correspondantes via l'API App Mesh. Pour en savoir plus ou contribuer au contrôleur, consultez le [GitHubprojet](https://github.com/aws/aws-app-mesh-controller-for-k8s).
Le contrôleur installe également un webhook qui injecte les conteneurs suivants dans les pods Kubernetes étiquetés avec un nom que vous spécifiez.
+ **Proxy App Mesh Envoy** — Envoy utilise la configuration définie dans le plan de contrôle App Mesh pour déterminer où envoyer le trafic de votre application.
+ **Gestionnaire de routes proxy App Mesh** : met à jour `iptables` les règles de l'espace de noms réseau d'un pod qui acheminent le trafic entrant et sortant via Envoy. Ce conteneur fonctionne comme un conteneur init Kubernetes à l'intérieur du pod.
## Conditions préalables
+ Compréhension existante des concepts de l'App Mesh. Pour de plus amples informations, veuillez consulter [Qu'est-ce que c'est AWS App Mesh ?](what-is-app-mesh.md).
+ Connaissances des concepts Kubernetes. Pour plus d'informations, consultez [Qu'est-ce que Kubernetes dans la documentation de Kubernetes](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/).
+ Un cluster Kubernetes existant. Si vous n'avez pas de cluster existant, consultez [Getting Started with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) dans le *guide de l'utilisateur Amazon EKS*. Si vous utilisez votre propre cluster Kubernetes sur Amazon EC2, assurez-vous que Docker est authentifié auprès du référentiel Amazon ECR dans lequel se trouve l'image Envoy. Pour plus d'informations, consultez [l'image d'Envoy, l'](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html)[authentification du registre](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth) dans le guide de l'utilisateur d'Amazon Elastic Container Registry [et l'extraction d'une image d'un registre privé](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) dans la documentation de Kubernetes.
+ 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. 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.
+ La AWS CLI version 1.18.116 ou ultérieure ou 2.0.38 ou ultérieure est installée. Pour installer ou mettre à niveau le AWS CLI, reportez-vous à la section [Installation du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html).
+ Un client `kubectl` configuré pour communiquer avec votre cluster Kubernetes. Si vous utilisez Amazon Elastic Kubernetes Service, vous pouvez suivre les instructions d'installation et de configuration d'un fichier. `[kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)` `[kubeconfig](https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html)`
+ Helm version 3.0 ou ultérieure installée. Si Helm n'est pas installé, consultez la section [Utilisation de Helm avec Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html) dans le *guide de l'utilisateur Amazon EKS*.
+ Amazon EKS ne prend actuellement en charge `IPv6_ONLY` que `IPv4_ONLY` les préférences IP, car Amazon EKS ne prend actuellement en charge que les pods capables de traiter uniquement du `IPv4` trafic ou uniquement `IPv6` du trafic.
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 : Installer les composants d'intégration
Installez les composants d'intégration une fois sur chaque cluster hébergeant les pods que vous souhaitez utiliser avec App Mesh.
**Pour installer les composants d'intégration**
1. Les étapes restantes de cette procédure nécessitent un cluster sans qu'une version préalable du contrôleur soit installée. Si vous avez installé une version préliminaire, ou si vous n'êtes pas certain de l'avoir fait, vous pouvez télécharger et exécuter un script qui vérifie si une version préliminaire est installée sur votre cluster.
```
curl -o pre_upgrade_check.sh https://raw.githubusercontent.com/aws/eks-charts/master/stable/appmesh-controller/upgrade/pre_upgrade_check.sh
sh ./pre_upgrade_check.sh
```
Si le script retourne `Your cluster is ready for upgrade. Please proceed to the installation instructions`, vous pouvez passer à l'étape suivante. Si un autre message est renvoyé, vous devrez effectuer les étapes de mise à niveau avant de continuer. Pour plus d'informations sur la mise à niveau d'une version préliminaire, consultez la section [Mise à niveau](https://github.com/aws/eks-charts/blob/master/stable/appmesh-controller/README.md#upgrade) sur GitHub.
1. Ajoutez le référentiel `eks-charts` à Helm.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. Installez les définitions de ressources personnalisées (CRD) App Mesh Kubernetes.
```
kubectl apply -k "https://github.com/aws/eks-charts/stable/appmesh-controller/crds?ref=master"
```
1. Créez un espace de noms Kubernetes pour le contrôleur.
```
kubectl create ns appmesh-system
```
1. Définissez les variables suivantes à utiliser pour les étapes ultérieures. Remplacez `cluster-name` et `Region-code` par les valeurs de votre cluster existant.
```
export CLUSTER_NAME=cluster-name
export AWS_REGION=Region-code
```
1. (Facultatif) Si vous souhaitez exécuter le contrôleur sur Fargate, vous devez créer un profil Fargate. Si ce n'est pas le cas, consultez la section [Installation ou mise à niveau `eksctl`](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl) dans le *guide de l'utilisateur Amazon EKS*. `eksctl` Si vous préférez créer le profil à l'aide de la console, consultez la section [Création d'un profil Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html#create-fargate-profile) dans le guide de l'utilisateur *Amazon EKS*.
```
eksctl create fargateprofile --cluster $CLUSTER_NAME --name appmesh-system --namespace appmesh-system
```
1. Créez un fournisseur d'identité OpenID Connect (OIDC) pour votre cluster. Si ce n'est pas le cas, vous pouvez l'installer en suivant les instructions de la section [Installation ou mise `eksctl` à niveau](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl) du *guide de l'utilisateur Amazon EKS*. `eksctl` Si vous préférez créer le fournisseur à l'aide de la console, consultez la section [Activation des rôles IAM pour les comptes de service de votre cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html) dans le *guide de l'utilisateur Amazon EKS*.
```
eksctl utils associate-iam-oidc-provider \
--region=$AWS_REGION \
--cluster $CLUSTER_NAME \
--approve
```
1. Créez un rôle IAM, associez-y les politiques [https://console.aws.amazon.com/iam/home?#policies/arn:aws:iam::aws:policy/AWSCloudMapFullAccess$jsonEditor](https://console.aws.amazon.com/iam/home?#policies/arn:aws:iam::aws:policy/AWSCloudMapFullAccess$jsonEditor) AWS gérées [https://console.aws.amazon.com/iam/home?#policies/arn:aws:iam::aws:policy/AWSAppMeshFullAccess$jsonEditor](https://console.aws.amazon.com/iam/home?#policies/arn:aws:iam::aws:policy/AWSAppMeshFullAccess$jsonEditor)et liez-le au compte de service `appmesh-controller` Kubernetes. Le rôle permet au contrôleur d'ajouter, de supprimer et de modifier des ressources App Mesh.
**Note**
La commande crée un rôle AWS IAM avec un nom généré automatiquement. Vous ne pouvez pas spécifier le nom de rôle IAM créé.
```
eksctl create iamserviceaccount \
--cluster $CLUSTER_NAME \
--namespace appmesh-system \
--name appmesh-controller \
--attach-policy-arn arn:aws:iam::aws:policy/AWSCloudMapFullAccess,arn:aws:iam::aws:policy/AWSAppMeshFullAccess \
--override-existing-serviceaccounts \
--approve
```
Si vous préférez créer le compte de service à l'aide du AWS Management Console ou AWS CLI, consultez la section [Création d'un rôle et d'une politique IAM pour votre compte de service](https://docs.aws.amazon.com/eks/latest/userguide/create-service-account-iam-policy-and-role.html#create-service-account-iam-role) dans le *guide de l'utilisateur Amazon EKS*. Si vous utilisez le AWS Management Console ou AWS CLI pour créer le compte, vous devez également associer le rôle à un compte de service Kubernetes. Pour plus d'informations, consultez la section [Spécification d'un rôle IAM pour votre compte de service](https://docs.aws.amazon.com/eks/latest/userguide/specify-service-account-role.html) dans le *guide de l'utilisateur Amazon EKS*.
1.
**Déployez le contrôleur App Mesh. Pour obtenir la liste de toutes les options de configuration, voir [Configuration](https://github.com/aws/eks-charts/blob/master/stable/appmesh-controller/README.md#configuration) activée GitHub.**
1. Pour déployer le contrôleur App Mesh pour un cluster privé, vous devez d'abord activer les points de terminaison Amazon VPC App Mesh et Service Discovery sur le sous-réseau privé lié. Vous devez également définir le`accountId`.
```
--set accountId=$AWS_ACCOUNT_ID
```
Pour activer le suivi X-Ray dans un cluster privé, activez les points de terminaison Amazon VPC X-Ray et Amazon ECR. Le contrôleur l'utilise `public.ecr.aws/xray/aws-xray-daemon:latest` par défaut, alors extrayez cette image en local et [insérez-la dans votre référentiel ECR personnel](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html).
**Note**
Les [points de terminaison Amazon VPC](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) ne sont actuellement pas compatibles avec les référentiels publics Amazon ECR.
L'exemple suivant montre le déploiement du contrôleur avec des configurations pour X-Ray.
```
helm upgrade -i appmesh-controller eks/appmesh-controller \
--namespace appmesh-system \
--set region=$AWS_REGION \
--set serviceAccount.create=false \
--set serviceAccount.name=appmesh-controller \
--set accountId=$AWS_ACCOUNT_ID \
--set log.level=debug \
--set tracing.enabled=true \
--set tracing.provider=x-ray \
--set xray.image.repository=your-account-id.dkr.ecr.your-region.amazonaws.com/your-repository \
--set xray.image.tag=your-xray-daemon-image-tag
```
Vérifiez si le daemon X-Ray est correctement injecté lorsque vous liez le déploiement de l'application à votre nœud virtuel ou à votre passerelle.
Pour plus d'informations, consultez la section [Clusters privés](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html) dans le *guide de l'utilisateur Amazon EKS*.
1. Déployez le contrôleur App Mesh pour d'autres clusters. Pour obtenir la liste de toutes les options de configuration, voir [Configuration](https://github.com/aws/eks-charts/blob/master/stable/appmesh-controller/README.md#configuration) activée GitHub.
```
helm upgrade -i appmesh-controller eks/appmesh-controller \
--namespace appmesh-system \
--set region=$AWS_REGION \
--set serviceAccount.create=false \
--set serviceAccount.name=appmesh-controller
```
**Note**
Si votre famille de clusters Amazon EKS l'est`IPv6`, veuillez définir le nom du cluster lors du déploiement du contrôleur App Mesh en ajoutant l'option suivante à la commande précédente`--set clusterName=$CLUSTER_NAME`.
**Important**
Si votre cluster se trouve dans les `af-south-1` régions`me-south-1`,,,,,,,`ap-east-1`,,`ap-southeast-3`,,`eu-south-1`,,`il-central-1`,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Remplacez *account-id* et *Region-code* par l'un des ensembles de valeurs appropriés.
```
--set image.repository=account-id.dkr.ecr.Region-code.amazonaws.com/amazon/appmesh-controller
```
772975370895.dkr. ecr.me-south-1.amazonaws.com /:v1.34.13.0-prod aws-appmesh-envoy
856666278305.dkr. ecr.ap-east-1.amazonaws.com /:v1.34.13.0-prod aws-appmesh-envoy
909464085924.dkr. ecr.ap-southeast-3.amazonaws.com /:v1.34.13.0-prod aws-appmesh-envoy
422531588944.dkr. ecr.eu-south-1.amazonaws.com /:v1.34.13.0-prod aws-appmesh-envoy
564877687649.dkr. ecr.il-central-1.amazonaws.com /:v1.34.13.0-prod aws-appmesh-envoy
924023996002.dkr. ecr.af-south-1.amazonaws.com /:v1.34.13.0-prod aws-appmesh-envoy
L'ancienne image URIs se trouve dans le [journal des modifications](https://github.com/aws/aws-app-mesh-controller-for-k8s/releases) GitHub. Les AWS comptes sur lesquels les images sont présentes ont changé de version`v1.5.0`. Les anciennes versions des images sont hébergées sur des AWS comptes figurant dans les registres d'images de conteneurs Amazon Elastic Kubernetes [Service](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-images.html) Amazon.
```
--set sidecar.image.repository=account-id.dkr.ecr.Region-code.amazonaws.com/aws-appmesh-envoy
```
772975370895.dkr.ecr.me-south-1.amazonaws. com/amazon/appmesh-contrôleur : v1.13.1
856666278305 .dkr.ecr.ap-east-1.amazonaws. com/amazon/appmesh-contrôleur : v1.13.1
909464085924.dkr.ecr.ap-southeast-3.amazonaws. com/amazon/appmesh-contrôleur : v1.13.1
422531588944.dkr.ecr.eu-south-1.amazonaws. com/amazon/appmesh-contrôleur : v1.13.1
564877687649.dkr.ecr.il-central-1.amazonaws. com/amazon/appmesh-contrôleur : v1.13.1
924023996002.dkr.ecr.af-south-1.amazonaws. com/amazon/appmesh-contrôleur : v1.13.1
```
--set sidecar.image.repository=account-id.dkr.ecr.Region-code.amazonaws.com/aws-appmesh-envoy
```
772975370895.dkr. ecr.me-south-1.amazonaws.com/-manager:v7-prod aws-appmesh-proxy-route
856666278305.dkr. ecr.ap-east-1.amazonaws.com/-manager:v7-prod aws-appmesh-proxy-route
909464085924.dkr. ecr.ap-southeast-3.amazonaws.com/-manager:v7-prod aws-appmesh-proxy-route
422531588944.dkr. ecr.eu-south-1.amazonaws.com/-manager:v7-prod aws-appmesh-proxy-route
564877687649.dkr. ecr.il-central-1.amazonaws.com/-manager:v7-prod aws-appmesh-proxy-route
924023996002.dkr. ecr.af-south-1.amazonaws.com/-manager:v7-prod aws-appmesh-proxy-route
**Important**
Seule la version v1.9.0.0-prod ou ultérieure est prise en charge pour une utilisation avec App Mesh.
1. Vérifiez que la version du contrôleur est `v1.4.0` ou une version ultérieure. Vous pouvez consulter le [journal des modifications](https://github.com/aws/aws-app-mesh-controller-for-k8s/releases) GitHub.
```
kubectl get deployment appmesh-controller \
-n appmesh-system \
-o json | jq -r ".spec.template.spec.containers[].image" | cut -f2 -d ':'
```
**Note**
Si vous affichez le journal du conteneur en cours d'exécution, une ligne contenant le texte suivant peut s'afficher. Vous pouvez l'ignorer en toute sécurité.
```
Neither -kubeconfig nor -master was specified. Using the inClusterConfig. This might not work.
```
## Étape 2 : Déployer les ressources App Mesh
Lorsque vous déployez une application dans Kubernetes, vous créez également les ressources personnalisées Kubernetes afin que le contrôleur puisse créer les ressources App Mesh correspondantes. La procédure suivante vous aide à déployer des ressources App Mesh avec certaines de leurs fonctionnalités. Vous pouvez trouver des exemples de manifestes pour le déploiement d'autres fonctionnalités des ressources App Mesh dans les `v1beta2` sous-dossiers de nombreux dossiers de fonctionnalités répertoriés dans les procédures pas à pas d'[App Mesh sur.](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs) GitHub
**Important**
Une fois que le contrôleur a créé une ressource App Mesh, nous vous recommandons de ne modifier ou de supprimer la ressource App Mesh qu'à l'aide du contrôleur. Si vous modifiez ou supprimez la ressource à l'aide d'App Mesh, le contrôleur ne modifiera ni ne recréera la ressource App Mesh modifiée ou supprimée pendant dix heures, par défaut. Vous pouvez configurer cette durée afin qu'elle soit inférieure. Pour plus d'informations, consultez [la section Configuration](https://github.com/aws/eks-charts/blob/master/stable/appmesh-controller/README.md#configuration) sur GitHub.
**Pour déployer des ressources App Mesh**
1. Créez un espace de noms Kubernetes dans lequel déployer les ressources App Mesh.
1. Enregistrez le contenu suivant dans un fichier nommé `namespace.yaml` sur votre ordinateur.
```
apiVersion: v1
kind: Namespace
metadata:
name: my-apps
labels:
mesh: my-mesh
appmesh.k8s.aws/sidecarInjectorWebhook: enabled
```
1. Créez l'espace de noms.
```
kubectl apply -f namespace.yaml
```
1. Créez un maillage de service App Mesh.
1. Enregistrez le contenu suivant dans un fichier nommé `mesh.yaml` sur votre ordinateur. Le fichier est utilisé pour créer une ressource de maillage nommée`my-mesh`. Un maillage de service est une limite logique pour le trafic réseau entre les services qui résident dans celui-ci.
```
apiVersion: appmesh.k8s.aws/v1beta2
kind: Mesh
metadata:
name: my-mesh
spec:
namespaceSelector:
matchLabels:
mesh: my-mesh
```
1. Créez le maillage.
```
kubectl apply -f mesh.yaml
```
1. Affichez les détails de la ressource de maillage Kubernetes créée.
```
kubectl describe mesh my-mesh
```
Output
```
Name: my-mesh
Namespace:
Labels:
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"appmesh.k8s.aws/v1beta2","kind":"Mesh","metadata":{"annotations":{},"name":"my-mesh"},"spec":{"namespaceSelector":{"matchLa...
API Version: appmesh.k8s.aws/v1beta2
Kind: Mesh
Metadata:
Creation Timestamp: 2020-06-17T14:51:37Z
Finalizers:
finalizers.appmesh.k8s.aws/mesh-members
finalizers.appmesh.k8s.aws/aws-appmesh-resources
Generation: 1
Resource Version: 6295
Self Link: /apis/appmesh.k8s.aws/v1beta2/meshes/my-mesh
UID: 111a11b1-c11d-1e1f-gh1i-j11k1l111m711
Spec:
Aws Name: my-mesh
Namespace Selector:
Match Labels:
Mesh: my-mesh
Status:
Conditions:
Last Transition Time: 2020-06-17T14:51:37Z
Status: True
Type: MeshActive
Mesh ARN: arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh
Observed Generation: 1
Events:
```
1. Consultez les détails du maillage de service App Mesh créé par le contrôleur.
```
aws appmesh describe-mesh --mesh-name my-mesh
```
Output
```
{
"mesh": {
"meshName": "my-mesh",
"metadata": {
"arn": "arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh",
"createdAt": "2020-06-17T09:51:37.920000-05:00",
"lastUpdatedAt": "2020-06-17T09:51:37.920000-05:00",
"meshOwner": "111122223333",
"resourceOwner": "111122223333",
"uid": "111a11b1-c11d-1e1f-gh1i-j11k1l111m711",
"version": 1
},
"spec": {},
"status": {
"status": "ACTIVE"
}
}
}
```
1. Créez un nœud virtuel App Mesh. Un nœud virtuel agit comme un pointeur logique vers un déploiement Kubernetes.
1. Enregistrez le contenu suivant dans un fichier nommé `virtual-node.yaml` sur votre ordinateur. Le fichier est utilisé pour créer un nœud virtuel App Mesh nommé `my-service-a` dans l'espace de *`my-apps`* noms. Le nœud virtuel représente un service Kubernetes créé dans une étape ultérieure. La valeur de `hostname` est le nom d'hôte DNS complet du service réel que ce nœud virtuel représente.
```
apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualNode
metadata:
name: my-service-a
namespace: my-apps
spec:
podSelector:
matchLabels:
app: my-app-1
listeners:
- portMapping:
port: 80
protocol: http
serviceDiscovery:
dns:
hostname: my-service-a.my-apps.svc.cluster.local
```
Les nœuds virtuels possèdent des fonctionnalités, telles que le end-to-end chiffrement et les contrôles de santé, qui ne sont pas abordées dans ce didacticiel. Pour de plus amples informations, veuillez consulter [Nœuds virtuels](virtual_nodes.md). Pour afficher tous les paramètres disponibles pour un nœud virtuel que vous pouvez définir dans la spécification précédente, exécutez la commande suivante.
```
aws appmesh create-virtual-node --generate-cli-skeleton yaml-input
```
1. Déployez le nœud virtuel.
```
kubectl apply -f virtual-node.yaml
```
1. Affichez les détails de la ressource de nœud virtuel Kubernetes créée.
```
kubectl describe virtualnode my-service-a -n my-apps
```
Output
```
Name: my-service-a
Namespace: my-apps
Labels:
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"appmesh.k8s.aws/v1beta2","kind":"VirtualNode","metadata":{"annotations":{},"name":"my-service-a","namespace":"my-apps"},"s...
API Version: appmesh.k8s.aws/v1beta2
Kind: VirtualNode
Metadata:
Creation Timestamp: 2020-06-17T14:57:29Z
Finalizers:
finalizers.appmesh.k8s.aws/aws-appmesh-resources
Generation: 2
Resource Version: 22545
Self Link: /apis/appmesh.k8s.aws/v1beta2/namespaces/my-apps/virtualnodes/my-service-a
UID: 111a11b1-c11d-1e1f-gh1i-j11k1l111m711
Spec:
Aws Name: my-service-a_my-apps
Listeners:
Port Mapping:
Port: 80
Protocol: http
Mesh Ref:
Name: my-mesh
UID: 111a11b1-c11d-1e1f-gh1i-j11k1l111m711
Pod Selector:
Match Labels:
App: nginx
Service Discovery:
Dns:
Hostname: my-service-a.my-apps.svc.cluster.local
Status:
Conditions:
Last Transition Time: 2020-06-17T14:57:29Z
Status: True
Type: VirtualNodeActive
Observed Generation: 2
Virtual Node ARN: arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualNode/my-service-a_my-apps
Events:
```
1. Affichez les détails du nœud virtuel créé par le contrôleur dans App Mesh.
**Note**
Même si le nom du nœud virtuel créé dans Kubernetes est `my-service-a`, le nom du nœud virtuel créé dans App Mesh est `my-service-a_my-apps`. Le contrôleur ajoute le nom de l'espace de noms Kubernetes au nom du nœud virtuel App Mesh lorsqu'il crée la ressource App Mesh. Le nom de l'espace de noms est ajouté car dans Kubernetes, vous pouvez créer des nœuds virtuels portant le même nom dans différents espaces de noms, mais dans App Mesh, le nom d'un nœud virtuel doit être unique au sein d'un maillage.
```
aws appmesh describe-virtual-node --mesh-name my-mesh --virtual-node-name my-service-a_my-apps
```
Output
```
{
"virtualNode": {
"meshName": "my-mesh",
"metadata": {
"arn": "arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualNode/my-service-a_my-apps",
"createdAt": "2020-06-17T09:57:29.840000-05:00",
"lastUpdatedAt": "2020-06-17T09:57:29.840000-05:00",
"meshOwner": "111122223333",
"resourceOwner": "111122223333",
"uid": "111a11b1-c11d-1e1f-gh1i-j11k1l111m711",
"version": 1
},
"spec": {
"backends": [],
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "http"
}
}
],
"serviceDiscovery": {
"dns": {
"hostname": "my-service-a.my-apps.svc.cluster.local"
}
}
},
"status": {
"status": "ACTIVE"
},
"virtualNodeName": "my-service-a_my-apps"
}
}
```
1. Créez un routeur virtuel App Mesh. Les routeurs virtuels gèrent le trafic d'un ou de plusieurs services virtuels au sein de votre mesh.
1. Enregistrez le contenu suivant dans un fichier nommé `virtual-router.yaml` sur votre ordinateur. Le fichier est utilisé pour créer un routeur virtuel afin d'acheminer le trafic vers le nœud virtuel nommé `my-service-a` qui a été créé à l'étape précédente. Le contrôleur crée le routeur virtuel App Mesh et achemine les ressources. Vous pouvez spécifier beaucoup d'autres fonctionnalités pour vos routages et utiliser des protocoles autres que `http`. Pour plus d’informations, consultez [Routeurs virtuels](virtual_routers.md) et [Routes](routes.md). Notez que le nom du nœud virtuel référencé est le nom du nœud virtuel Kubernetes, et non le nom du nœud virtuel App Mesh créé dans App Mesh par le contrôleur.
```
apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualRouter
metadata:
namespace: my-apps
name: my-service-a-virtual-router
spec:
listeners:
- portMapping:
port: 80
protocol: http
routes:
- name: my-service-a-route
httpRoute:
match:
prefix: /
action:
weightedTargets:
- virtualNodeRef:
name: my-service-a
weight: 1
```
(Facultatif) Pour voir tous les paramètres disponibles pour un routeur virtuel que vous pouvez définir dans la spécification précédente, exécutez la commande suivante.
```
aws appmesh create-virtual-router --generate-cli-skeleton yaml-input
```
Pour voir tous les paramètres disponibles pour un itinéraire que vous pouvez définir dans la spécification précédente, exécutez la commande suivante.
```
aws appmesh create-route --generate-cli-skeleton yaml-input
```
1. Déployez le routeur virtuel.
```
kubectl apply -f virtual-router.yaml
```
1. Affichez la ressource de routeur virtuel Kubernetes qui a été créée.
```
kubectl describe virtualrouter my-service-a-virtual-router -n my-apps
```
Sortie abrégée
```
Name: my-service-a-virtual-router
Namespace: my-apps
Labels:
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"appmesh.k8s.aws/v1beta2","kind":"VirtualRouter","metadata":{"annotations":{},"name":"my-service-a-virtual-router","namespac...
API Version: appmesh.k8s.aws/v1beta2
Kind: VirtualRouter
...
Spec:
Aws Name: my-service-a-virtual-router_my-apps
Listeners:
Port Mapping:
Port: 80
Protocol: http
Mesh Ref:
Name: my-mesh
UID: 111a11b1-c11d-1e1f-gh1i-j11k1l111m711
Routes:
Http Route:
Action:
Weighted Targets:
Virtual Node Ref:
Name: my-service-a
Weight: 1
Match:
Prefix: /
Name: my-service-a-route
Status:
Conditions:
Last Transition Time: 2020-06-17T15:14:01Z
Status: True
Type: VirtualRouterActive
Observed Generation: 1
Route AR Ns:
My - Service - A - Route: arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualRouter/my-service-a-virtual-router_my-apps/route/my-service-a-route
Virtual Router ARN: arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualRouter/my-service-a-virtual-router_my-apps
Events:
```
1. Affichez la ressource de routeur virtuel créée par le contrôleur dans App Mesh. Vous spécifiez `my-service-a-virtual-router_my-apps` pour`name`, car lorsque le contrôleur a créé le routeur virtuel dans App Mesh, il a ajouté le nom de l'espace de noms Kubernetes au nom du routeur virtuel.
```
aws appmesh describe-virtual-router --virtual-router-name my-service-a-virtual-router_my-apps --mesh-name my-mesh
```
Output
```
{
"virtualRouter": {
"meshName": "my-mesh",
"metadata": {
"arn": "arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualRouter/my-service-a-virtual-router_my-apps",
"createdAt": "2020-06-17T10:14:01.547000-05:00",
"lastUpdatedAt": "2020-06-17T10:14:01.547000-05:00",
"meshOwner": "111122223333",
"resourceOwner": "111122223333",
"uid": "111a11b1-c11d-1e1f-gh1i-j11k1l111m711",
"version": 1
},
"spec": {
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "http"
}
}
]
},
"status": {
"status": "ACTIVE"
},
"virtualRouterName": "my-service-a-virtual-router_my-apps"
}
}
```
1. Affichez la ressource d'itinéraire créée par le contrôleur dans App Mesh. Une ressource de route n'a pas été créée dans Kubernetes car la route fait partie de la configuration du routeur virtuel dans Kubernetes. Les informations de route ont été affichées dans le détail de la ressource Kubernetes dans la sous-étape `c`. Le contrôleur n'a pas ajouté le nom de l'espace de noms Kubernetes au nom de l'itinéraire App Mesh lorsqu'il a créé l'itinéraire dans App Mesh, car les noms des itinéraires sont uniques à un routeur virtuel.
```
aws appmesh describe-route \
--route-name my-service-a-route \
--virtual-router-name my-service-a-virtual-router_my-apps \
--mesh-name my-mesh
```
Output
```
{
"route": {
"meshName": "my-mesh",
"metadata": {
"arn": "arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualRouter/my-service-a-virtual-router_my-apps/route/my-service-a-route",
"createdAt": "2020-06-17T10:14:01.577000-05:00",
"lastUpdatedAt": "2020-06-17T10:14:01.577000-05:00",
"meshOwner": "111122223333",
"resourceOwner": "111122223333",
"uid": "111a11b1-c11d-1e1f-gh1i-j11k1l111m711",
"version": 1
},
"routeName": "my-service-a-route",
"spec": {
"httpRoute": {
"action": {
"weightedTargets": [
{
"virtualNode": "my-service-a_my-apps",
"weight": 1
}
]
},
"match": {
"prefix": "/"
}
}
},
"status": {
"status": "ACTIVE"
},
"virtualRouterName": "my-service-a-virtual-router_my-apps"
}
}
```
1. Créez un service virtuel App Mesh. Un service virtuel est une abstraction d'un service réel qui est fournie directement ou indirectement par un nœud virtuel, via un routeur virtuel. Les services dépendants appellent votre service virtuel par son nom. Bien que le nom n'ait pas d'importance pour App Mesh, nous recommandons de nommer le service virtuel comme le nom de domaine complet du service réel que le service virtuel représente. En nommant vos services virtuels de cette façon, vous n'avez pas besoin de modifier votre code d'application pour référencer un autre nom. Ces demandes sont acheminées vers le nœud virtuel ou le routeur virtuel qui est spécifié en tant que fournisseur pour le service virtuel.
1. Enregistrez le contenu suivant dans un fichier nommé `virtual-service.yaml` sur votre ordinateur. Le fichier est utilisé pour créer un service virtuel qui utilise un fournisseur de routeur virtuel pour acheminer le trafic vers le nœud virtuel nommé `my-service-a` qui a été créé à l'étape précédente. La valeur de `awsName` dans le `spec` correspond au nom de domaine complet (FQDN) du service Kubernetes réel que ce service virtuel résume. Le service Kubernetes est créé dans [Étape 3 : Créer ou mettre à jour des services](#create-update-services). Pour de plus amples informations, veuillez consulter [Services virtuels](virtual_services.md).
```
apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualService
metadata:
name: my-service-a
namespace: my-apps
spec:
awsName: my-service-a.my-apps.svc.cluster.local
provider:
virtualRouter:
virtualRouterRef:
name: my-service-a-virtual-router
```
Pour afficher tous les paramètres disponibles pour un nœud virtuel que vous pouvez définir dans la spécification précédente, exécutez la commande suivante.
```
aws appmesh create-virtual-service --generate-cli-skeleton yaml-input
```
1. Créez le service virtuel.
```
kubectl apply -f virtual-service.yaml
```
1. Affichez les détails de la ressource de service virtuel Kubernetes créée.
```
kubectl describe virtualservice my-service-a -n my-apps
```
Output
```
Name: my-service-a
Namespace: my-apps
Labels:
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"appmesh.k8s.aws/v1beta2","kind":"VirtualService","metadata":{"annotations":{},"name":"my-service-a","namespace":"my-apps"}...
API Version: appmesh.k8s.aws/v1beta2
Kind: VirtualService
Metadata:
Creation Timestamp: 2020-06-17T15:48:40Z
Finalizers:
finalizers.appmesh.k8s.aws/aws-appmesh-resources
Generation: 1
Resource Version: 13598
Self Link: /apis/appmesh.k8s.aws/v1beta2/namespaces/my-apps/virtualservices/my-service-a
UID: 111a11b1-c11d-1e1f-gh1i-j11k1l111m711
Spec:
Aws Name: my-service-a.my-apps.svc.cluster.local
Mesh Ref:
Name: my-mesh
UID: 111a11b1-c11d-1e1f-gh1i-j11k1l111m711
Provider:
Virtual Router:
Virtual Router Ref:
Name: my-service-a-virtual-router
Status:
Conditions:
Last Transition Time: 2020-06-17T15:48:40Z
Status: True
Type: VirtualServiceActive
Observed Generation: 1
Virtual Service ARN: arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualService/my-service-a.my-apps.svc.cluster.local
Events:
```
1. Affichez les détails de la ressource de service virtuel créée par le contrôleur dans App Mesh. Le contrôleur Kubernetes n'a pas ajouté le nom de l'espace de noms Kubernetes au nom du service virtuel App Mesh lorsqu'il a créé le service virtuel dans App Mesh, car le nom du service virtuel est un FQDN unique.
```
aws appmesh describe-virtual-service --virtual-service-name my-service-a.my-apps.svc.cluster.local --mesh-name my-mesh
```
Output
```
{
"virtualService": {
"meshName": "my-mesh",
"metadata": {
"arn": "arn:aws:appmesh:us-west-2:111122223333:mesh/my-mesh/virtualService/my-service-a.my-apps.svc.cluster.local",
"createdAt": "2020-06-17T10:48:40.182000-05:00",
"lastUpdatedAt": "2020-06-17T10:48:40.182000-05:00",
"meshOwner": "111122223333",
"resourceOwner": "111122223333",
"uid": "111a11b1-c11d-1e1f-gh1i-j11k1l111m711",
"version": 1
},
"spec": {
"provider": {
"virtualRouter": {
"virtualRouterName": "my-service-a-virtual-router_my-apps"
}
}
},
"status": {
"status": "ACTIVE"
},
"virtualServiceName": "my-service-a.my-apps.svc.cluster.local"
}
}
```
Bien que cela ne soit pas abordé dans ce didacticiel, le contrôleur peut également déployer App Mesh [Passerelles virtuelles](virtual_gateways.md) et[Routes de passerelle](gateway-routes.md). Pour une présentation détaillée du déploiement de ces ressources avec le contrôleur, voir [Configuration de la passerelle entrante](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-ingress-gateway) ou un [exemple de manifeste](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/howto-k8s-ingress-gateway/v1beta2/manifest.yaml.template) incluant les ressources sur. GitHub
## Étape 3 : Créer ou mettre à jour des services
Les conteneurs annexes App Mesh doivent être ajoutés à tous les pods que vous souhaitez utiliser avec App Mesh. L'injecteur ajoute automatiquement les conteneurs sidecar à n'importe quel pod déployé dans un espace de noms avec l'étiquette que vous spécifiez.
1. Activez l'autorisation proxy. Nous vous recommandons d'activer chaque déploiement Kubernetes pour diffuser uniquement la configuration de son propre nœud virtuel App Mesh.
1. Enregistrez le contenu suivant dans un fichier nommé `proxy-auth.json` sur votre ordinateur. Assurez-vous de le remplacer *alternate-colored values* par le vôtre.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "appmesh:StreamAggregatedResources",
"Resource": [
"arn:aws:appmesh:us-east-1:111122223333:mesh/my-mesh/virtualNode/my-service-a_my-apps"
]
}
]
}
```
------
1. Créez la politique.
```
aws iam create-policy --policy-name my-policy --policy-document file://proxy-auth.json
```
1. Créez un rôle IAM, associez-y la politique que vous avez créée à l'étape précédente, créez un compte de service Kubernetes et liez la politique au compte de service Kubernetes. Le rôle permet au contrôleur d'ajouter, de supprimer et de modifier des ressources App Mesh.
```
eksctl create iamserviceaccount \
--cluster $CLUSTER_NAME \
--namespace my-apps \
--name my-service-a \
--attach-policy-arn arn:aws:iam::111122223333:policy/my-policy \
--override-existing-serviceaccounts \
--approve
```
Si vous préférez créer le compte de service à l'aide du AWS Management Console ou AWS CLI, consultez la section [Création d'un rôle et d'une politique IAM pour votre compte de service](https://docs.aws.amazon.com/eks/latest/userguide/create-service-account-iam-policy-and-role.html#create-service-account-iam-role) dans le *guide de l'utilisateur Amazon EKS*. Si vous utilisez le AWS Management Console ou AWS CLI pour créer le compte, vous devez également associer le rôle à un compte de service Kubernetes. Pour plus d'informations, consultez la section [Spécification d'un rôle IAM pour votre compte de service](https://docs.aws.amazon.com/eks/latest/userguide/specify-service-account-role.html) dans le *guide de l'utilisateur Amazon EKS*.
1. (Facultatif) Si vous souhaitez déployer votre déploiement sur des pods Fargate, vous devez créer un profil Fargate. Si ce n'est pas le cas, vous pouvez l'installer en suivant les instructions de la section [Installation ou mise `eksctl` à niveau](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl) du *guide de l'utilisateur Amazon EKS*. `eksctl` Si vous préférez créer le profil à l'aide de la console, consultez la section [Création d'un profil Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html#create-fargate-profile) dans le guide de l'utilisateur *Amazon EKS*.
```
eksctl create fargateprofile --cluster my-cluster --region Region-code --name my-service-a --namespace my-apps
```
1. Créez un service et un déploiement Kubernetes. Si vous avez un déploiement existant que vous souhaitez utiliser avec App Mesh, vous devez déployer un nœud virtuel, comme vous l'avez fait à la sous-étape `3` de[Étape 2 : Déployer les ressources App Mesh](#configure-app-mesh). Mettez à jour votre déploiement pour vous assurer que son étiquette correspond à celle que vous avez définie sur le nœud virtuel, afin que les conteneurs annexes soient automatiquement ajoutés aux pods et que les pods soient redéployés.
1. Enregistrez le contenu suivant dans un fichier nommé `example-service.yaml` sur votre ordinateur. Si vous modifiez le nom de l'espace de noms et que vous utilisez des pods Fargate, assurez-vous que le nom de l'espace de noms correspond à celui défini dans votre profil Fargate.
```
apiVersion: v1
kind: Service
metadata:
name: my-service-a
namespace: my-apps
labels:
app: my-app-1
spec:
selector:
app: my-app-1
ports:
- protocol: TCP
port: 80
targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-service-a
namespace: my-apps
labels:
app: my-app-1
spec:
replicas: 3
selector:
matchLabels:
app: my-app-1
template:
metadata:
labels:
app: my-app-1
spec:
serviceAccountName: my-service-a
containers:
- name: nginx
image: nginx:1.19.0
ports:
- containerPort: 80
```
**Important**
La valeur de la spécification `app` `matchLabels` `selector` dans la spécification doit correspondre à la valeur que vous avez spécifiée lors de la création du nœud virtuel dans la sous-étape `3` de [Étape 2 : Déployer les ressources App Mesh](#configure-app-mesh), sinon les conteneurs sidecar ne seront pas injectés dans le conteneur. Dans l'exemple précédent, la valeur de l'étiquette est `my-app-1`. Si vous déployez une passerelle virtuelle plutôt qu'un nœud virtuel, le `Deployment` manifeste ne doit inclure que le conteneur Envoy. Pour plus d'informations sur l'image à utiliser, consultez[Image de l'envoyé](envoy.md). Pour un exemple de manifeste, consultez l'[exemple de déploiement](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/howto-k8s-ingress-gateway/v1beta2/manifest.yaml.template#L585) sur GitHub.
1. Déployez le service.
```
kubectl apply -f example-service.yaml
```
1. Consultez le service et le déploiement.
```
kubectl -n my-apps get pods
```
Output
```
NAME READY STATUS RESTARTS AGE
my-service-a-54776556f6-2cxd9 2/2 Running 0 10s
my-service-a-54776556f6-w26kf 2/2 Running 0 18s
my-service-a-54776556f6-zw5kt 2/2 Running 0 26s
```
1. Consultez les détails de l'un des pods qui a été déployé.
```
kubectl -n my-apps describe pod my-service-a-54776556f6-2cxd9
```
Sortie abrégée
```
Name: my-service-a-54776556f6-2cxd9
Namespace: my-app-1
Priority: 0
Node: ip-192-168-44-157.us-west-2.compute.internal/192.168.44.157
Start Time: Wed, 17 Jun 2020 11:08:59 -0500
Labels: app=nginx
pod-template-hash=54776556f6
Annotations: kubernetes.io/psp: eks.privileged
Status: Running
IP: 192.168.57.134
IPs:
IP: 192.168.57.134
Controlled By: ReplicaSet/my-service-a-54776556f6
Init Containers:
proxyinit:
Container ID: docker://e0c4810d584c21ae0cb6e40f6119d2508f029094d0e01c9411c6cf2a32d77a59
Image: 111345817488.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-proxy-route-manager:v2
Image ID: docker-pullable://111345817488.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-proxy-route-manager
Port:
Host Port:
State: Terminated
Reason: Completed
Exit Code: 0
Started: Fri, 26 Jun 2020 08:36:22 -0500
Finished: Fri, 26 Jun 2020 08:36:22 -0500
Ready: True
Restart Count: 0
Requests:
cpu: 10m
memory: 32Mi
Environment:
APPMESH_START_ENABLED: 1
APPMESH_IGNORE_UID: 1337
APPMESH_ENVOY_INGRESS_PORT: 15000
APPMESH_ENVOY_EGRESS_PORT: 15001
APPMESH_APP_PORTS: 80
APPMESH_EGRESS_IGNORED_IP: 169.254.169.254
APPMESH_EGRESS_IGNORED_PORTS: 22
AWS_ROLE_ARN: arn:aws:iam::111122223333:role/eksctl-app-mesh-addon-iamserviceaccount-my-a-Role1-NMNCVWB6PL0N
AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
...
Containers:
nginx:
Container ID: docker://be6359dc6ecd3f18a1c87df7b57c2093e1f9db17d5b3a77f22585ce3bcab137a
Image: nginx:1.19.0
Image ID: docker-pullable://nginx
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Fri, 26 Jun 2020 08:36:28 -0500
Ready: True
Restart Count: 0
Environment:
AWS_ROLE_ARN: arn:aws:iam::111122223333:role/eksctl-app-mesh-addon-iamserviceaccount-my-a-Role1-NMNCVWB6PL0N
AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
...
envoy:
Container ID: docker://905b55cbf33ef3b3debc51cb448401d24e2e7c2dbfc6a9754a2c49dd55a216b6
Image: 840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.12.4.0-prod
Image ID: docker-pullable://840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy
Port: 9901/TCP
Host Port: 0/TCP
State: Running
Started: Fri, 26 Jun 2020 08:36:36 -0500
Ready: True
Restart Count: 0
Requests:
cpu: 10m
memory: 32Mi
Environment:
APPMESH_RESOURCE_ARN: arn:aws:iam::111122223333:mesh/my-mesh/virtualNode/my-service-a_my-apps
APPMESH_PREVIEW: 0
ENVOY_LOG_LEVEL: info
AWS_REGION: us-west-2
AWS_ROLE_ARN: arn:aws:iam::111122223333:role/eksctl-app-mesh-addon-iamserviceaccount-my-a-Role1-NMNCVWB6PL0N
AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulling 30s kubelet, ip-192-168-44-157.us-west-2.compute.internal Pulling image "111345817488.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-proxy-route-manager:v2"
Normal Pulled 23s kubelet, ip-192-168-44-157.us-west-2.compute.internal Successfully pulled image "111345817488.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-proxy-route-manager:v2"
Normal Created 21s kubelet, ip-192-168-44-157.us-west-2.compute.internal Created container proxyinit
Normal Started 21s kubelet, ip-192-168-44-157.us-west-2.compute.internal Started container proxyinit
Normal Pulling 20s kubelet, ip-192-168-44-157.us-west-2.compute.internal Pulling image "nginx:1.19.0"
Normal Pulled 16s kubelet, ip-192-168-44-157.us-west-2.compute.internal Successfully pulled image "nginx:1.19.0"
Normal Created 15s kubelet, ip-192-168-44-157.us-west-2.compute.internal Created container nginx
Normal Started 15s kubelet, ip-192-168-44-157.us-west-2.compute.internal Started container nginx
Normal Pulling 15s kubelet, ip-192-168-44-157.us-west-2.compute.internal Pulling image "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.12.4.0-prod"
Normal Pulled 8s kubelet, ip-192-168-44-157.us-west-2.compute.internal Successfully pulled image "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.12.4.0-prod"
Normal Created 7s kubelet, ip-192-168-44-157.us-west-2.compute.internal Created container envoy
Normal Started 7s kubelet, ip-192-168-44-157.us-west-2.compute.internal Started container envoy
```
Dans la sortie précédente, vous pouvez voir que les conteneurs `proxyinit` et `envoy` ont été ajoutés au pod. Si vous avez déployé l'exemple de service sur Fargate, `envoy` le conteneur a été ajouté au pod par le contrôleur, mais pas `proxyinit` le conteneur.
1. (Facultatif) Installez des modules complémentaires tels que Prometheus, Grafana, Jaeger et AWS X-Ray Datadog. Pour plus d'informations, consultez les [modules complémentaires App Mesh](https://github.com/aws/eks-charts#app-mesh-add-ons) GitHub et la section [Observabilité](https://docs.aws.amazon.com/app-mesh/latest/userguide/observability.html) du guide de l'utilisateur d'App Mesh.
**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).
## Étape 4 : nettoyer
Supprimez toutes les ressources d'exemple créées dans ce didacticiel. Le contrôleur supprime également les ressources créées dans le maillage du service `my-mesh` App Mesh.
```
kubectl delete namespace my-apps
```
Si vous avez créé un profil Fargate pour le service d'exemple, supprimez-le.
```
eksctl delete fargateprofile --name my-service-a --cluster my-cluster --region Region-code
```
Supprimez le maillage.
```
kubectl delete mesh my-mesh
```
(Facultatif) Vous pouvez supprimer les composants d'intégration Kubernetes.
```
helm delete appmesh-controller -n appmesh-system
```
(Facultatif) Si vous avez déployé les composants d'intégration Kubernetes sur Fargate, supprimez le profil Fargate.
```
eksctl delete fargateprofile --name appmesh-system --cluster my-cluster --region Region-code
```
# 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).
# Exemples d'App Mesh
**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).
Vous trouverez des end-to-end procédures pas à pas illustrées AWS App Mesh en action et des exemples de code pour l'intégration à différents AWS services dans le référentiel suivant :
[Exemples d'App Mesh](https://github.com/aws/aws-app-mesh-examples)