Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Primeros pasos con AWS App Mesh Amazon ECS
**importante**
Aviso de fin del soporte: el 30 de septiembre de 2026, AWS suspenderemos el soporte para AWS App Mesh. Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visite esta entrada del blog [Migración desde AWS App Mesh a Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Este tema le ayuda a utilizarlo AWS App Mesh con un servicio real que se ejecuta en Amazon ECS. Este tutorial abarca las características básicas de varios tipos de recursos de App Mesh.
## Escenario
Para ilustrar cómo usar App Mesh, suponga que tiene una aplicación con las siguientes características:
+ Consta de dos servicios denominados `serviceA` y `serviceB`.
+ Ambos servicios están registrados en un espacio de nombres denominado `apps.local`.
+ `ServiceA` se comunica con `serviceB` a través de HTTP/2, puerto 80.
+ Ya ha implementado la versión 2 de `serviceB` y la ha registrado con el nombre `serviceBv2` en el espacio de nombres `apps.local`.
Tiene los siguientes requisitos:
+ Desea enviar el 75 por ciento del tráfico desde `serviceA` `serviceB` y el 25 por ciento del tráfico hacia `serviceBv2` First. Si solo envías el 25 por ciento a`serviceBv2`, puedes validar que está libre de errores antes de enviar el 100 por ciento del tráfico desde allí`serviceA`.
+ Desea poder ajustar fácilmente la proporción del tráfico para que el 100 % del tráfico vaya hacia `serviceBv2` una vez que se demuestre que es de confianza. Una vez que se envía todo el tráfico a `serviceBv2`, desea suspender `serviceB`.
+ No quiere tener que cambiar ningún código de aplicación existente o registro de detección de servicios para que sus servicios reales cumplan los requisitos anteriores.
Para satisfacer sus requisitos, ha decidido crear una malla de servicios de App Mesh con servicios virtuales, nodos virtuales, un enrutador virtual y una ruta. Después de implementar la malla, actualiza los servicios para utilizar el proxy de Envoy. Una vez actualizados, sus servicios se comunican entre sí a través del proxy de Envoy en lugar de directamente.
## Requisitos previos
**importante**
Aviso de fin del soporte: el 30 de septiembre de 2026, AWS dejaremos de ofrecer soporte para AWS App Mesh. Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visite esta entrada del blog [Migración desde AWS App Mesh a Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
+ Comprensión previa de los conceptos de App Mesh. Para obtener más información, consulte [¿Qué es AWS App Mesh?](what-is-app-mesh.md).
+ Una comprensión actual de los ECSs conceptos de Amazon. Para obtener más información, consulte [Qué es Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) en la Guía para desarrolladores de Amazon Elastic Container Service.
+ App Mesh es compatible con los servicios de Linux que están registrados con DNS o con ambos. AWS Cloud Map Para utilizar esta guía de introducción, le recomendamos que tenga tres servicios existentes que estén registrados con DNS. En los procedimientos de este tema se presupone que los servicios existentes se llaman `serviceA`, `serviceB` y `serviceBv2`, y que todos los servicios son detectables a través de un espacio de nombres denominado `apps.local`.
Puede crear una malla de servicios y sus recursos incluso aunque los servicios no existan, pero no puede usar la malla hasta que haya implementado servicios reales. Para obtener más información acerca de la detección de servicios en Amazon ECS, consulte [Detección de servicios](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html). Para crear un servicio de Amazon ECS con la detección de servicios, consulte [Tutorial: Creación de un servicio mediante la detección de servicios](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-discovery.html). Si aún no tiene los servicios en ejecución, puede [Crear un servicio de Amazon ECS mediante la detección de servicios](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-discovery.html).
## Paso 1: Crear una malla y un servicio virtual
Una malla de servicios es un límite lógico para el tráfico de red entre los servicios que residen dentro de ella. Para obtener más información, consulte [Mallas de servicios](meshes.md). Un servicio virtual es una abstracción de un servicio real. Para obtener más información, consulte [Servicios virtuales](virtual_services.md).
Cree los siguientes recursos :
+ Una malla denominada `apps`, ya que todos los servicios del escenario están registrados en el espacio de nombres `apps.local`.
+ Un servicio virtual llamado `serviceb.apps.local`, ya que el servicio virtual representa un servicio que se puede detectar con ese nombre y no desea cambiar el código para hacer referencia a otro nombre. Un servicio virtual llamado `servicea.apps.local` se agrega en un paso posterior.
Puedes usar la AWS CLI versión 1.18.116 Consola de administración de AWS o superior o la 2.0.38 o superior para completar los siguientes pasos. Si utiliza el AWS CLI, utilice el `aws --version` comando para comprobar la versión instalada. AWS CLI Si no tiene instalada 1.18.116 o posterior o bien la 2.0.38 o posterior, debe [instalar o actualizar la AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/appmesh/cli-chap-install.html). Seleccione la pestaña de la herramienta que desea utilizar.
------
#### [ Consola de administración de AWS ]
1. Abre el asistente de primera ejecución de la consola App Mesh al comenzar [https://console.aws.amazon.com/appmesh/.](https://console.aws.amazon.com/appmesh/get-started)
1. Para **Nombre de malla**, escriba **apps**.
1. En **Nombre del servicio virtual**, escriba **serviceb.apps.local**.
1. Para continuar, elija **Siguiente**.
------
#### [ AWS CLI ]
1. Cree una malla con el comando `[create-mesh](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-mesh.html)`.
```
aws appmesh create-mesh --mesh-name apps
```
1. Cree un servicio virtual con el comando `[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 {}
```
------
## Paso 2: Crear un nodo virtual
Un nodo virtual actúa como un puntero lógico a un servicio real. Para obtener más información, consulte [Nodos virtuales](virtual_nodes.md).
Cree un nodo virtual denominado `serviceB`, ya que uno de los nodos virtuales representa el servicio real denominado `serviceB`. El servicio real que representa el nodo virtual es detectable a través de `DNS` con un nombre de host de `serviceb.apps.local`. Como alternativa, puede descubrir los servicios reales utilizando. AWS Cloud Map El nodo virtual atenderá el tráfico utilizando el protocolo HTTP/2 en el puerto 80. También se admiten otros protocolos, así como comprobaciones de estado. Creará nodos virtuales para `serviceA` y `serviceBv2` en un paso posterior.
------
#### [ Consola de administración de AWS ]
1. En **Nombre del nodo virtual**, escriba **serviceB**.
1. En **Método de detección de servicios**, elija **DNS** y escriba **serviceb.apps.local** en **Nombre de host DNS**.
1. En **Configuración del agente de escucha**, elija **http2** en **Protocolo** y escriba **80** en **Puerto**.
1. Para continuar, elija **Siguiente**.
------
#### [ AWS CLI ]
1. Cree un archivo denominado `create-virtual-node-serviceb.json` con el siguiente contenido:
```
{
"meshName": "apps",
"spec": {
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "http2"
}
}
],
"serviceDiscovery": {
"dns": {
"hostname": "serviceB.apps.local"
}
}
},
"virtualNodeName": "serviceB"
}
```
1. Cree el nodo virtual con el [create-virtual-node](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-node.html)comando utilizando el archivo JSON como entrada.
```
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-serviceb.json
```
------
## Paso 3: Crear un enrutador virtual y una ruta
Los routers virtuales enrutan el tráfico de uno o más servicios virtuales dentro de la malla. Para obtener más información, consulte [Enrutadores virtuales](virtual_routers.md) y [Rutas](routes.md).
Cree los siguientes recursos :
+ Un enrutador virtual llamado `serviceB`, ya que el servicio virtual `serviceB.apps.local` no inicia la comunicación saliente con ningún otro servicio. Recuerde que el servicio virtual que creó anteriormente es una abstracción de su servicio `serviceb.apps.local` real. El servicio virtual envía tráfico al router virtual. El enrutador virtual escucha el tráfico utilizando el protocolo HTTP/2 en el puerto 80. También se admiten otros protocolos.
+ Una ruta llamada `serviceB`. Enruta el cien por cien de su tráfico al nodo virtual `serviceB`. La ponderación se realiza en un paso posterior una vez que haya añadido el nodo virtual `serviceBv2`. Aunque no se incluye en esta guía, puede agregar criterios de filtro adicionales para la ruta y agregar una política de reintento para que el proxy de Envoy realice varios intentos de enviar tráfico a un nodo virtual cuando experimenta un problema de comunicación.
------
#### [ Consola de administración de AWS ]
1. En **Nombre del enrutador virtual**, escriba **serviceB**.
1. En **Configuración del agente de escucha**, elija **http2** en **Protocolo** y especifique **80** en **Puerto**.
1. En **Nombre de ruta**, escriba **serviceB**.
1. En **Tipo de ruta**, elija **http2**.
1. En **Nombre de nodo virtual**, en **Configuración de destino**, seleccione `serviceB` y escriba **100** para **Ponderación**.
1. En **Configuración de coincidencia**, elija un **Método**.
1. Para continuar, elija **Siguiente**.
------
#### [ AWS CLI ]
1. Cree un router virtual.
1. Cree un archivo denominado `create-virtual-router.json` con el siguiente contenido:
```
{
"meshName": "apps",
"spec": {
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "http2"
}
}
]
},
"virtualRouterName": "serviceB"
}
```
1. Cree el router virtual con el [create-virtual-router](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-router.html)comando utilizando el archivo JSON como entrada.
```
aws appmesh create-virtual-router --cli-input-json file://create-virtual-router.json
```
1. Cree una ruta.
1. Cree un archivo denominado `create-route.json` con el siguiente contenido:
```
{
"meshName" : "apps",
"routeName" : "serviceB",
"spec" : {
"httpRoute" : {
"action" : {
"weightedTargets" : [
{
"virtualNode" : "serviceB",
"weight" : 100
}
]
},
"match" : {
"prefix" : "/"
}
}
},
"virtualRouterName" : "serviceB"
}
```
1. Cree la ruta con el comando [create-route](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-route.html) utilizando el archivo JSON como entrada.
```
aws appmesh create-route --cli-input-json file://create-route.json
```
------
## Paso 4: Revisar y crear
Revise la configuración comparándola con las instrucciones anteriores.
------
#### [ Consola de administración de AWS ]
Elija **Editar** si necesita realizar cambios en cualquier sección. Una vez esté satisfecho con la configuración, elija **Crear malla**.
La pantalla **Estado** muestra todos los recursos de malla que se han creado. Puede ver los recursos creados en la consola seleccionando **Ver malla**.
------
#### [ AWS CLI ]
Revise la configuración de la malla que creó con el comando [describe-mesh](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-mesh.html).
```
aws appmesh describe-mesh --mesh-name apps
```
Revise la configuración del servicio virtual que creó con el [describe-virtual-service](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-service.html)comando.
```
aws appmesh describe-virtual-service --mesh-name apps --virtual-service-name serviceb.apps.local
```
Revise la configuración del nodo virtual que creó con el [describe-virtual-node](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-node.html)comando.
```
aws appmesh describe-virtual-node --mesh-name apps --virtual-node-name serviceB
```
Revise la configuración del router virtual que creó con el [describe-virtual-router](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-router.html)comando.
```
aws appmesh describe-virtual-router --mesh-name apps --virtual-router-name serviceB
```
Revise la configuración de la ruta que creó con el comando [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
```
------
## Paso 5: Crear recursos adicionales
Para completar el escenario, debe:
+ Crear un nodo virtual denominado `serviceBv2` y otro denominado `serviceA`. Ambos nodos virtuales escuchan las solicitudes a través del puerto HTTP/2 80. Para el nodo virtual `serviceA`, configure un backend de `serviceb.apps.local`. Todo el tráfico saliente del nodo virtual `serviceA` se envía al servicio virtual denominado `serviceb.apps.local`. Aunque no se trata en esta guía, también puede especificar una ruta de acceso de archivo en la que escribir registros de acceso para un nodo virtual.
+ Cree un servicio virtual adicional llamado `servicea.apps.local`, que envíe todo el tráfico directamente al nodo virtual `serviceA`.
+ Actualizar la ruta de `serviceB` que creó en un paso anterior para enviar el 75 % de su tráfico al nodo virtual `serviceB` y el 25 % de su tráfico al nodo virtual `serviceBv2`. Con el tiempo, puede continuar modificando las proporciones hasta que `serviceBv2` reciba el 100 % del tráfico. Una vez que se envíe todo el tráfico hacia `serviceBv2`, puede cerrar y suspender el nodo virtual `serviceB` y el servicio real. Cuando cambia las ponderaciones, el código no requiere ninguna modificación, ya que los nombres del servicio real y virtual `serviceb.apps.local` no cambian. Recuerde que el servicio virtual `serviceb.apps.local` envía tráfico al router virtual, que enruta el tráfico a los nodos virtuales. Los nombres de detección de servicios para los nodos virtuales se pueden cambiar en cualquier momento.
------
#### [ Consola de administración de AWS ]
1. En el panel de navegación izquierdo, seleccione **Mallas**.
1. Seleccione la malla `apps` que creó en un paso anterior.
1. En el panel de navegación izquierdo, seleccione **Nodos virtuales**.
1. Elija **Crear nodo virtual**.
1. En **Nombre del nodo virtual**, escriba **serviceBv2**, en **Método de detección de servicios**, elija **DNS**, y en **Nombre de host DNS** escriba **servicebv2.apps.local**.
1. En **Configuración del agente de escucha**, seleccione **http2** para **Protocolo** y escriba **80** para **Puerto**.
1. Elija **Crear nodo virtual**.
1. Elija de nuevo **Crear nodo virtual**. Escriba **serviceA** en el **Nombre del nodo virtual**. En **Método de detección de servicios**, elija **DNS** y en **Nombre de host DNS**, escriba **servicea.apps.local**.
1. En **Escriba un nombre de servicio virtual**, en **Nuevo backend**, escriba **serviceb.apps.local**.
1. En **Configuración del agente de escucha**, elija **http2** para **Protocolo**, escriba **80** para **Puerto** y, a continuación, elija **Crear nodo virtual**.
1. En el panel de navegación izquierdo, seleccione** Routers virtuales** y, a continuación, seleccione el router virtual `serviceB` de la lista.
1. En **Rutas**, seleccione la ruta llamada `ServiceB` que creó en un paso anterior y elija **Editar**.
1. En **Destinos**, **Nombre del nodo virtual**, cambie el valor de **Ponderación** de `serviceB` a **75**.
1. Elija **Agregar objetivo**, elija `serviceBv2` en la lista desplegable y establezca el valor de **Ponderación** en **25**.
1. Seleccione **Save**.
1. En el panel de navegación izquierdo, seleccione** Servicios virtuales** y, a continuación, elija **Crear servicio virtual**.
1. Escriba **servicea.apps.local** en **Nombre del servicio virtual**, seleccione **Nodo virtual** en **Proveedor**, seleccione `serviceA` en **Nodo virtual** y, a continuación, elija **Crear servicio virtual.**
------
#### [ AWS CLI ]
1. Cree el nodo virtual `serviceBv2`.
1. Cree un archivo denominado `create-virtual-node-servicebv2.json` con el siguiente contenido:
```
{
"meshName": "apps",
"spec": {
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "http2"
}
}
],
"serviceDiscovery": {
"dns": {
"hostname": "serviceBv2.apps.local"
}
}
},
"virtualNodeName": "serviceBv2"
}
```
1. Cree el nodo virtual.
```
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicebv2.json
```
1. Cree el nodo virtual `serviceA`.
1. Cree un archivo denominado `create-virtual-node-servicea.json` con el siguiente contenido:
```
{
"meshName" : "apps",
"spec" : {
"backends" : [
{
"virtualService" : {
"virtualServiceName" : "serviceb.apps.local"
}
}
],
"listeners" : [
{
"portMapping" : {
"port" : 80,
"protocol" : "http2"
}
}
],
"serviceDiscovery" : {
"dns" : {
"hostname" : "servicea.apps.local"
}
}
},
"virtualNodeName" : "serviceA"
}
```
1. Cree el nodo virtual.
```
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicea.json
```
1. Actualice el servicio virtual `serviceb.apps.local` que creó en un paso anterior para enviar su tráfico al router virtual `serviceB`. Cuando el servicio virtual se creó originalmente, no envió tráfico a ninguna parte, ya que el router virtual `serviceB` aún no se había creado.
1. Cree un archivo denominado `update-virtual-service.json` con el siguiente contenido:
```
{
"meshName" : "apps",
"spec" : {
"provider" : {
"virtualRouter" : {
"virtualRouterName" : "serviceB"
}
}
},
"virtualServiceName" : "serviceb.apps.local"
}
```
1. Actualice el servicio virtual con el [update-virtual-service](https://docs.aws.amazon.com/cli/latest/reference/appmesh/update-virtual-service.html)comando.
```
aws appmesh update-virtual-service --cli-input-json file://update-virtual-service.json
```
1. Actualice la ruta `serviceB` que creó en un paso anterior.
1. Cree un archivo denominado `update-route.json` con el siguiente contenido:
```
{
"meshName" : "apps",
"routeName" : "serviceB",
"spec" : {
"http2Route" : {
"action" : {
"weightedTargets" : [
{
"virtualNode" : "serviceB",
"weight" : 75
},
{
"virtualNode" : "serviceBv2",
"weight" : 25
}
]
},
"match" : {
"prefix" : "/"
}
}
},
"virtualRouterName" : "serviceB"
}
```
1. Actualice la ruta con el comando [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. Cree el servicio virtual `serviceA`.
1. Cree un archivo denominado `create-virtual-servicea.json` con el siguiente contenido:
```
{
"meshName" : "apps",
"spec" : {
"provider" : {
"virtualNode" : {
"virtualNodeName" : "serviceA"
}
}
},
"virtualServiceName" : "servicea.apps.local"
}
```
1. Cree el servicio virtual.
```
aws appmesh create-virtual-service --cli-input-json file://create-virtual-servicea.json
```
------
**Resumen de malla**
Antes de crear la malla de servicio, tenía tres servicios reales denominados `servicea.apps.local`, `serviceb.apps.local` y `servicebv2.apps.local`. Además de los servicios reales, ahora tiene una malla de servicio que contiene los siguientes recursos que representan los servicios reales:
+ Dos servicios virtuales. El proxy envía todo el tráfico desde el servicio virtual `servicea.apps.local` al servicio virtual `serviceb.apps.local` a través de un router virtual.
+ Tres nodos virtuales denominados `serviceA`, `serviceB` y `serviceBv2`. El proxy de Envoy utiliza la información de detección de servicios configurada para los nodos virtuales para buscar las direcciones IP de los servicios reales.
+ Un router virtual con una ruta que indica al proxy de Envoy que enrute el 75 % del tráfico entrante al nodo virtual `serviceB` y el 25 % del tráfico al nodo virtual `serviceBv2`.
## Paso 6: Actualizar los servicios
Después de crear su malla, debe realizar las siguientes tareas:
+ Autorice al proxy de Envoy que implementa con cada tarea de Amazon ECS a que lea la configuración de uno o más nodos virtuales. Para obtener más información acerca de cómo autorizar el proxy, consulte [Autorización del proxy](https://docs.aws.amazon.com/app-mesh/latest/userguide/proxy-authorization.html).
+ Actualice cada una de sus definiciones de tareas de Amazon ECS para que utilicen el proxy de Envoy.
**Credenciales**
El contenedor Envoy requiere AWS Identity and Access Management credenciales para firmar las solicitudes que se envían al servicio App Mesh. Para las tareas de Amazon ECS implementadas con el tipo de lanzamiento de Amazon EC2, las credenciales pueden provenir del [rol de instancia](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/instance_IAM_role.html) o de un [rol de IAM de la tarea](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). Las tareas de Amazon ECS implementadas con Fargate en contenedores de Linux no tienen acceso al servidor de metadatos de Amazon EC2 que proporciona las credenciales del perfil de IAM de la instancia. Para proporcionar las credenciales, debe asociar un rol de tarea de IAM a cualquier tarea implementada con el tipo de contenedor Fargate en Linux.
Si una tarea se implementa con el tipo de lanzamiento de Amazon EC2 y se bloquea el acceso al servidor de metadatos de Amazon EC2, tal y como se describe en la anotación *Importante* en [Rol de IAM para tareas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html), también debe asociarse a la tarea un rol de IAM de tarea. El rol que asigne a la instancia o tarea debe tener una política de IAM asociada como se describe en [Autorización de proxy](https://docs.aws.amazon.com/app-mesh/latest/userguide/proxy-authorization.html).
**Para actualizar la definición de la tarea mediante el AWS CLI**
Utiliza el AWS CLI comando 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). El ejemplo de definición de tarea que aparece a continuación muestra cómo configurar App Mesh para su servicio.
**nota**
La configuración de App Mesh para Amazon ECS a través de la consola no está disponible.
### json de definición de tarea
**Configuración del proxy**
Para configurar su servicio de Amazon ECS para que utilice App Mesh, la definición de tarea del servicio debe tener la siguiente sección de configuración de proxy. Establezca la configuración de proxy `type` en `APPMESH` y `containerName` en `envoy`. Establezca los siguientes valores de propiedad según corresponda.
`IgnoredUID`
El proxy de Envoy no enruta el tráfico de los procesos que utilizan este ID de usuario. Puede elegir cualquier identificador de usuario que desee para este valor de propiedad, pero este identificador debe ser el mismo que el ID de `user` del contenedor de Envoy en la definición de tarea. Este emparejamiento permite a Envoy pasar por alto su propio tráfico sin utilizar el proxy. Nuestros ejemplos utilizan `1337` con fines históricos.
`ProxyIngressPort`
Este es el puerto de entrada del contenedor de proxy de Envoy. Ajuste este valor en `15000`.
`ProxyEgressPort`
Este es el puerto de salida del contenedor de proxy de Envoy. Ajuste este valor en `15001`.
`AppPorts`
Especifique los puertos de entrada de escucha de los contenedores de aplicación. En este ejemplo, el contenedor de aplicación escucha en el puerto `9080`. El puerto que especifique debe coincidir con el puerto configurado en el agente de escucha de nodo virtual.
`EgressIgnoredIPs`
Envoy no utiliza un proxy para el tráfico en estas direcciones IP. Establezca este valor en `169.254.170.2,169.254.169.254`, que ignora el servidor de metadatos de Amazon EC2 y el punto de conexión de metadatos de la tarea de Amazon ECS. El punto de conexión de metadatos proporciona roles de IAM para las credenciales de tareas. Puede añadir direcciones adicionales.
`EgressIgnoredPorts`
Puede añadir una lista de puertos separados por comas. Envoy no utiliza un proxy para el tráfico en estas direcciones IP. El puerto 22 no se tiene en cuenta aunque no aparezca ningún puerto.
El número máximo de puertos de salida que se pueden ignorar es 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"
}
]
}
```
**Dependencia de Envoy de contenedor de aplicación**
Los contenedores de aplicación en las definiciones de tarea deben esperar a que arranque y comience el proxy de Envoy antes de poder comenzar. Para asegurarse de que esto ocurra, establezca una sección `dependsOn` en cada definición de contenedor de la aplicación para que espere a que el contenedor de Envoy notifique el estado `HEALTHY`. El siguiente código muestra un ejemplo de definición de contenedor de aplicación con esta dependencia. Todas las propiedades del siguiente ejemplo son necesarias. Algunos de los valores de las propiedades también son obligatorios, pero otros sí*replaceable*.
```
{
"name": "appName",
"image": "appImage",
"portMappings": [{
"containerPort": 9080,
"hostPort": 9080,
"protocol": "tcp"
}],
"essential": true,
"dependsOn": [{
"containerName": "envoy",
"condition": "HEALTHY"
}]
}
```
**Definición de contenedor de Envoy**
Las definiciones de tareas de Amazon ECS deben incluir una imagen del contenedor de App Mesh Envoy.
Todas las regiones [compatibles](https://docs.aws.amazon.com/general/latest/gr/appmesh.html) se pueden *Region-code* sustituir por cualquier región que no sea `me-south-1` `ap-east-1``ap-southeast-3`,`eu-south-1`,`il-central-1`, y`af-south-1`.
Standard
```
840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
Cumple con las normas 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
```
Cumple con FIPS
```
public.ecr.aws/appmesh/aws-appmesh-envoy:v1.34.13.0-prod-fips
```
**importante**
Solo se admite el uso de la versión v1.9.0.0-prod o posterior con App Mesh.
Debe usar la imagen del contenedor de App Mesh Envoy hasta que el equipo del proyecto de Envoy fusione los cambios compatibles con App Mesh. [Para obtener más información, consulta el tema de la GitHub hoja de ruta.](https://github.com/aws/aws-app-mesh-roadmap/issues/10)
Todas las propiedades del siguiente ejemplo son necesarias. Algunos de los valores de las propiedades también son obligatorios, pero otros sí. *replaceable*
**nota**
La definición de contenedor de Envoy se debe marcar como `essential`.
Recomendamos asignar unidades de CPU de `512` y al menos `64` MiB de memoria al contenedor de Envoy. En Fargate, el valor más bajo que podrá establecer son `1024` MiB de memoria.
El nombre del nodo virtual del servicio de Amazon ECS debe establecerse en el valor de la propiedad `APPMESH_RESOURCE_ARN`. Esta propiedad requiere la versión `1.15.0` o posterior de la imagen de Envoy. Para obtener más información, consulte [Imagen de Envoy](envoy.md).
El valor de la configuración `user` debe coincidir con el valor `IgnoredUID` de la configuración del proxy de definición de tarea. En este ejemplo, usaremos `1337`.
La comprobación de estado que se muestra aquí espera a que el contenedor de Envoy arranque correctamente antes de notificar a Amazon ECS que el contenedor de Envoy está en buen estado y listo para que se inicien los contenedores de la aplicación.
De forma predeterminada, App Mesh utiliza el nombre del recurso que se especificó en `APPMESH_RESOURCE_ARN` cuando Envoy hace referencia a sí mismo en métricas y registros de seguimiento. Puede anular este comportamiento estableciendo la variable de entorno `APPMESH_RESOURCE_CLUSTER` con su propio nombre. Esta propiedad requiere la versión `1.15.0` o posterior de la imagen de Envoy. Para obtener más información, consulte [Imagen de Envoy](envoy.md).
En el siguiente bloque se muestra un ejemplo de definición de contenedor de 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"
}
```
**Ejemplos de definiciones de tarea**
Las definiciones de tareas de Amazon ECS de ejemplo siguientes muestran cómo combinar los ejemplos de arriba en una definición de tarea para `taskB`. Se proporcionan ejemplos para crear tareas para ambos tipos de lanzamiento de Amazon ECS con o sin uso de AWS X-Ray. Cambie los *replaceable* valores, según proceda, para crear definiciones de tareas para las tareas nombradas `taskBv2` y `taskA` del escenario. Sustituya el nombre de malla y el nombre del nodo virtual por el valor `APPMESH_RESOURCE_ARN` y una lista de los puertos donde la aplicación escucha el valor `AppPorts` de la configuración de proxy. De forma predeterminada, App Mesh utiliza el nombre del recurso que se especificó en `APPMESH_RESOURCE_ARN` cuando Envoy hace referencia a sí mismo en métricas y registros de seguimiento. Puede anular este comportamiento estableciendo la variable de entorno `APPMESH_RESOURCE_CLUSTER` con su propio nombre. Todas las propiedades de los siguientes ejemplos son necesarias. Algunos de los valores de las propiedades también son obligatorios, pero otros sí*replaceable*.
Si está ejecutando una tarea de Amazon ECS como se describe en la sección Credenciales, debe agregar un [rol de IAM de tarea](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) existente a los ejemplos.
**importante**
Fargate debe usar un valor de puerto superior a 1024.
**Example Definición de tareas de JSON para Amazon ECS: Fargate en contenedores de 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 Definición de tareas de JSON para Amazon ECS con AWS X-Ray contenedores Fargate en Linux**
X-Ray permite recopilar datos sobre las solicitudes que una aplicación sirve y proporciona herramientas que puede utilizar para visualizar el flujo de tráfico. Utilizar el controlador de X-Ray para Envoy permite a Envoy facilitar información de rastreo a X-Ray. Puede habilitar el rastreo de X-Ray mediante la [Configuración de Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html). En función de la configuración, Envoy envía datos de rastreo al daemon de X-Ray que se ejecuta como un contenedor [sidecar](https://docs.aws.amazon.com/xray/latest/devguide/xray-daemon-ecs.html) y el daemon reenvía los rastreos al servicio de X-Ray. Una vez que los rastreos se publican en X-Ray, puede utilizar la consola de X-Ray para visualizar el gráfico de llamada al servicio y solicitar detalles de rastreo. El siguiente JSON representa una definición de tarea para habilitar la integración 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 JSON para la definición de tarea de Amazon ECS: tipo de lanzamiento de 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 Definición de tareas de JSON para Amazon ECS con AWS X-Ray tipo de lanzamiento 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"
}
```
## Temas avanzados
### Implementaciones de valores controlados mediante App Mesh
Las versiones e implementaciones de valores controlados ayudan a cambiar el tráfico entre una versión antigua de una aplicación y una versión recién implementada. También monitoriza el estado de la versión recién implementada. Si hay algún problema con la nueva versión, la implementación de valores controlados puede devolver automáticamente el tráfico a la versión anterior. Las implementaciones de valores controlados permiten cambiar el tráfico entre versiones de la aplicación con más control.
Para obtener más información sobre cómo aplicar las implementaciones de valores controlados para Amazon ECS mediante App Mesh, consulte [Crear una canalización con las implementaciones de valores controlados para Amazon ECS mediante App Mesh](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/)
**nota**
Para ver más ejemplos y tutoriales de App Mesh, consulte el [repositorio de ejemplos de App Mesh](https://github.com/aws/aws-app-mesh-examples).