Introducción a AWS App Mesh Amazon ECS - AWS App Mesh
EscenarioRequisitos previosPaso 1: Crear una malla y un servicio virtualPaso 2: Crear un nodo virtualPaso 3: Crear un enrutador virtual y una rutaPaso 4: Revisar y crearPaso 5: Crear recursos adicionalesPaso 6: Actualizar los serviciosTemas avanzados

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.

Introducción a AWS App Mesh Amazon ECS

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 % del tráfico de serviceA a serviceB y el 25 % del tráfico a serviceBv2 para validar que serviceBv2 está libre de errores antes de enviar el cien por cien del tráfico de serviceA a él mismo.

  • 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

  • Comprensión previa de los conceptos de App Mesh. Para obtener más información, consulte ¿Qué es AWS App Mesh?.

  • Comprensión previa de los conceptos de Amazon ECSs. Para obtener más información, consulte Qué es Amazon ECS 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. 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. Si aún no tiene los servicios en ejecución, puede Crear un servicio de Amazon ECS mediante la detección de servicios.

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. Un servicio virtual es una abstracción de un servicio real. Para obtener más información, consulte Servicios virtuales.

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 AWS Management Console 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. Seleccione la pestaña de la herramienta que desea utilizar.

AWS Management Console

  1. Abra el asistente de primera ejecución de la consola de App Mesh en https://console.aws.amazon.com/appmesh/get-started.

  2. Para Nombre de malla, escriba apps.

  3. En Nombre del servicio virtual, escriba serviceb.apps.local.

  4. Para continuar, elija Siguiente.

AWS CLI

  1. Cree una malla con el comando create-mesh.

    aws appmesh create-mesh --mesh-name apps

  2. Cree un servicio virtual con el comando create-virtual-service.

    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.

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.

AWS Management Console

  1. En Nombre del nodo virtual, escriba serviceB.

  2. En Método de detección de servicios, elija DNS y escriba serviceb.apps.local en Nombre de host DNS.

  3. En Configuración del agente de escucha, elija http2 en Protocolo y escriba 80 en Puerto.

  4. 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"
}

  2. Cree el nodo virtual con el create-virtual-nodecomando 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 y Rutas.

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.

AWS Management Console

  1. En Nombre del enrutador virtual, escriba serviceB.

  2. En Configuración del agente de escucha, elija http2 en Protocolo y especifique 80 en Puerto.

  3. En Nombre de ruta, escriba serviceB.

  4. En Tipo de ruta, elija http2.

  5. En Nombre de nodo virtual, en Configuración de destino, seleccione serviceB y escriba 100 para Ponderación.

  6. En Configuración de coincidencia, elija un Método.

  7. 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"
}

    2. Cree el router virtual con el create-virtual-routercomando utilizando el archivo JSON como entrada.

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

  2. 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"
}

    2. Cree la ruta con el comando create-route 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.

AWS Management Console

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.

aws appmesh describe-mesh --mesh-name apps

Revise la configuración del servicio virtual que creó con el describe-virtual-servicecomando.

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-nodecomando.

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-routercomando.

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.

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.

AWS Management Console

  1. En el panel de navegación izquierdo, seleccione Mallas.

  2. Seleccione la malla apps que creó en un paso anterior.

  3. En el panel de navegación izquierdo, seleccione Nodos virtuales.

  4. Elija Crear nodo virtual.

  5. 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.

  6. En Configuración del agente de escucha, seleccione http2 para Protocolo y escriba 80 para Puerto.

  7. Elija Crear nodo virtual.

  8. 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.

  9. En Escriba un nombre de servicio virtual, en Nuevo backend, escriba serviceb.apps.local.

  10. En Configuración del agente de escucha, elija http2 para Protocolo, escriba 80 para Puerto y, a continuación, elija Crear nodo virtual.

  11. En el panel de navegación izquierdo, seleccione Routers virtuales y, a continuación, seleccione el router virtual serviceB de la lista.

  12. En Rutas, seleccione la ruta llamada ServiceB que creó en un paso anterior y elija Editar.

  13. En Destinos, Nombre del nodo virtual, cambie el valor de Ponderación de serviceB a 75.

  14. Elija Agregar objetivo, elija serviceBv2 en la lista desplegable y establezca el valor de Ponderación en 25.

  15. Seleccione Guardar.

  16. En el panel de navegación izquierdo, seleccione Servicios virtuales y, a continuación, elija Crear servicio virtual.

  17. 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"
}

    2. Cree el nodo virtual.

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

  2. 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"
}

    2. Cree el nodo virtual.

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

  3. 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"
}

    2. Actualice el servicio virtual con el update-virtual-servicecomando.

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

  4. 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"
}

    2. Actualice la ruta con el comando update-route.

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

  5. 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"
}

    2. 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.

  • 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 o de un rol de IAM de la tarea. 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, 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.

Para actualizar la definición de la tarea mediante el AWS CLI

Utiliza el AWS CLI comando Amazon ECS register-task-definition. 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.

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.

nota

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 propiedad también son necesarios, pero algunos son reemplazables.

{
	"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 admitidas distintas de me-south-1, ap-east-1, ap-southeast-3, eu-south-1, il-central-1 y af-south-1. Puede reemplazar el código de región 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.

Estándar

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

Compatible con FIPS

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

Estándar

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

Cumple con FIPS

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

Estándar

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

Cumple con FIPS

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

Estándar

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

Cumple con FIPS

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

Estándar

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

Cumple con FIPS

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

Estándar

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

Cumple con FIPS

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

Estándar

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

Cumple con FIPS

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

Estándar

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

Cumple con FIPS

public.ecr.aws/appmesh/aws-appmesh-envoy:v1.29.6.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.

Todas las propiedades del siguiente ejemplo son necesarias. Algunos de los valores de propiedad también son necesarios, pero algunos son reemplazables.

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.

  • 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.

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.29.6.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 valores reemplazables según corresponda, para crear definiciones de tareas para las tareas nombradas taskBv2 y taskA desde el 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 propiedad también son necesarios, pero algunos son reemplazables.

Si está ejecutando una tarea de Amazon ECS como se describe en la sección Credenciales, debe agregar un rol de IAM de tarea existente a los ejemplos.

importante

Fargate debe usar un valor de puerto superior a 1024.

ejemplo 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.29.6.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"
}
ejemplo 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. 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 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.29.6.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"
}
ejemplo 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.29.6.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"
}
ejemplo 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.29.6.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

nota

Para ver más ejemplos y tutoriales de App Mesh, consulte el repositorio de ejemplos de App Mesh.