As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Começando a usar AWS App Mesh o Amazon ECS
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Este tópico ajuda você a usar AWS App Mesh com um serviço real que está sendo executado no Amazon ECS. Esse tutorial aborda os atributos básicos de vários tipos de recursos do App Mesh.
## Cenário
Para ilustrar como usar o App Mesh, suponha que você tenha um aplicativo com as seguintes características:
+ Consiste em dois serviços chamados `serviceA` e `serviceB`.
+ Ambos os serviços estão registrados em um namespace chamado `apps.local`.
+ O `ServiceA` se comunica com o `serviceB` por HTTP/2, porta 80.
+ Você já implantou a versão 2 do `serviceB` e a registrou com o nome de `serviceBv2` no namespace `apps.local`.
Você tem os seguintes requisitos:
+ Você quer enviar 75 por cento do tráfego de `serviceA` para `serviceB` e 25 por cento do tráfego para o `serviceBv2` primeiro. Ao enviar apenas 25% para`serviceBv2`, você pode validar que está livre de bugs antes de enviar 100% do tráfego de`serviceA`.
+ Você quer poder ajustar facilmente a ponderação do tráfego para que 100% do tráfego vá para o `serviceBv2` quando for comprovado que ele é confiável. Depois que todo o tráfego estiver sendo enviado para o `serviceBv2`, você deseja descontinuar o `serviceB`.
+ Você não quer ter que alterar nenhum código de aplicativo ou registro de descoberta de serviços existente para que seus serviços reais atendam aos requisitos anteriores.
Para atender às suas necessidades, você decide criar uma malha de serviços do App Mesh com serviços virtuais, nós virtuais, um roteador virtual e uma rota. Depois de implementar a malha, você atualiza os serviços que usam o proxy do Envoy. Assim que forem atualizados, os serviços se comunicarão entre si por meio do proxy Envoy em vez de diretamente entre si.
## Pré-requisitos
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
+ Uma compreensão existente dos conceitos do App Mesh. Para obter mais informações, consulte [O que é AWS App Mesh?](what-is-app-mesh.md).
+ Uma compreensão existente dos ECSs conceitos da Amazon. Para obter mais informações, consulte [O que é o Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) no Guia do desenvolvedor do Amazon Elastic Container Service.
+ O App Mesh oferece suporte a serviços Linux registrados com DNS ou ambos. AWS Cloud Map Para usar este guia de conceitos básicos, recomendamos que você tenha três serviços existentes registrados no DNS. Para os procedimentos nesse tópico, espera-se que os serviços existentes sejam nomeados `serviceA`, `serviceB` e `serviceBv2`; e que todos os serviços sejam detectáveis por meio de um namespace chamado `apps.local`.
É possível criar uma malha de serviço e seus recursos mesmo que os serviços não existam, mas não será possível usar a malha enquanto não tiver implantado serviços reais. Para mais informações sobre a descoberta de serviços no Amazon ECS, consulte [Descoberta de serviços](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html). Para criar um serviço do Amazon ECS com descoberta de serviços, consulte [Tutorial: Como criar um serviço usando a descoberta de serviços](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-discovery.html). Se você ainda não tem serviços em execução, você pode [Criar um serviço Amazon ECS com a descoberta de serviços](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-discovery.html).
## Etapa 1: Criar uma malha e um serviço virtual
Uma malha de serviços é um limite lógico para o tráfego de rede entre os serviços que residem nela. Para obter mais informações, consulte [Malhas de serviço](meshes.md). Um serviço virtual é uma abstração de um serviço real. Para obter mais informações, consulte [Serviços virtuais](virtual_services.md).
Crie os recursos da a seguir:
+ Uma malha chamada `apps`, uma vez que todos os serviços no cenário estão registrados no namespace `apps.local`.
+ Um serviço virtual chamado `serviceb.apps.local`, uma vez que o serviço virtual representa um serviço que é detectável com esse nome e você não quer alterar o código para fazer referência a outro nome. Um serviço virtual chamado `servicea.apps.local` será adicionado em uma etapa posterior.
Você pode usar a AWS CLI versão 1.18.116 Console de gerenciamento da AWS ou superior ou 2.0.38 ou superior para concluir as etapas a seguir. Se estiver usando o AWS CLI, use o `aws --version` comando para verificar sua AWS CLI versão instalada. Se você não tiver a versão 1.18.116 ou superior ou a versão 2.0.38 ou superior instalada, será necessário [instalar ou atualizar a AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/appmesh/cli-chap-install.html). Selecione a guia da ferramenta que deseja usar.
------
#### [ Console de gerenciamento da AWS ]
1. Abra o assistente de primeira execução do console App Mesh ao [https://console.aws.amazon.com/appmesh/começar](https://console.aws.amazon.com/appmesh/get-started).
1. Em **Mesh name (Nome da malha)**, insira **apps**.
1. Em **Virtual service name (Nome do serviço virtual)**, insira **serviceb.apps.local**.
1. Para continuar, escolha **Avançar**.
------
#### [ AWS CLI ]
1. Crie uma malha com o comando `[create-mesh](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-mesh.html)`.
```
aws appmesh create-mesh --mesh-name apps
```
1. Crie um serviço virtual com o 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 {}
```
------
## Etapa 2: Criar um nó virtual
Um nó virtual funciona como um apontador lógico para um serviço real. Para obter mais informações, consulte [Nós virtuais](virtual_nodes.md).
Crie um nó virtual chamado `serviceB`, uma vez que um dos nós virtuais representa o serviço real chamado `serviceB`. O serviço real que o nó virtual representa é detectável por meio do `DNS` com um nome de host de `serviceb.apps.local`. Como alternativa, você pode descobrir serviços reais usando. AWS Cloud Map O nó virtual escutará o tráfego usando o protocolo HTTP/2 na porta 80. Outros protocolos, assim como verificações de integridade, também são compatíveis. Você criará nós virtuais para `serviceA` e `serviceBv2` em uma etapa posterior.
------
#### [ Console de gerenciamento da AWS ]
1. Em **Virtual node name (Nome do nó virtual)**, insira **serviceB**.
1. Em **Service discovery method (Método de descoberta de serviços)**, escolha **DNS** e insira **serviceb.apps.local** para **DNS hostname (Nome de host do DNS)**.
1. Em **Listener configuration (Configuração do Listener)**, escolha **http2** para **Protocol (Protocolo)** e digite **80** para **Port (Porta)**.
1. Para continuar, escolha **Avançar**.
------
#### [ AWS CLI ]
1. Crie um arquivo denominado `create-virtual-node-serviceb.json` com o conteúdo a seguir:
```
{
"meshName": "apps",
"spec": {
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "http2"
}
}
],
"serviceDiscovery": {
"dns": {
"hostname": "serviceB.apps.local"
}
}
},
"virtualNodeName": "serviceB"
}
```
1. Crie o nó virtual com o [create-virtual-node](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-node.html)comando usando o arquivo JSON como entrada.
```
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-serviceb.json
```
------
## Etapa 3: Criar um roteador virtual e uma rota
Os roteadores virtuais cuidam do tráfego de um ou mais serviços virtuais dentro da malha. Para obter mais informações, consulte [Roteadores virtuais](virtual_routers.md) e [Rotas](routes.md).
Crie os recursos da a seguir:
+ Um roteador virtual denominado `serviceB`, uma vez que o serviço virtual do `serviceB.apps.local` não inicia a comunicação de saída com nenhum outro serviço. Lembre-se de que o serviço virtual criado anteriormente é uma abstração do serviço `serviceb.apps.local` real. O serviço virtual envia tráfego para o roteador virtual. O roteador virtual recebe o tráfego usando o protocolo HTTP/2 na porta 80. Outros protocolos também são compatíveis.
+ Uma rota chamada `serviceB`. Ela roteia 100% de seu tráfego para o nó virtual do `serviceB`. O peso será alterado em uma etapa posterior, depois de adicionar o nó virtual do `serviceBv2`. Embora não seja abordado neste guia, é possível adicionar critérios de filtro adicionais para a rota e adicionar uma política de novas tentativas para fazer com que o proxy Envoy faça várias tentativas de enviar tráfego para um nó virtual quando ele tiver um problema de comunicação.
------
#### [ Console de gerenciamento da AWS ]
1. Em **Virtual router name (Nome do roteador virtual)**, insira **serviceB**.
1. Em **Listener configuration (Configuração do Listener)**, escolha **http2** para **Protocol (Protocolo)** e especifique **80** para **Port (Porta)**.
1. Em **Route name (Nome da rota)**, insira **serviceB**.
1. Em **Route type (Tipo de rota)**, escolha **http2**.
1. Para o **nome do nó virtual** em **Configuração de destino**, selecione `serviceB` e digite **100** para **Peso**.
1. Em **Configuração de correspondência**, escolha um **Método**.
1. Para continuar, escolha **Avançar**.
------
#### [ AWS CLI ]
1. Crie um roteador virtual.
1. Crie um arquivo denominado `create-virtual-router.json` com o conteúdo a seguir:
```
{
"meshName": "apps",
"spec": {
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "http2"
}
}
]
},
"virtualRouterName": "serviceB"
}
```
1. Crie o roteador virtual com o [create-virtual-router](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-router.html)comando usando o arquivo JSON como entrada.
```
aws appmesh create-virtual-router --cli-input-json file://create-virtual-router.json
```
1. Crie uma rota.
1. Crie um arquivo denominado `create-route.json` com o conteúdo a seguir:
```
{
"meshName" : "apps",
"routeName" : "serviceB",
"spec" : {
"httpRoute" : {
"action" : {
"weightedTargets" : [
{
"virtualNode" : "serviceB",
"weight" : 100
}
]
},
"match" : {
"prefix" : "/"
}
}
},
"virtualRouterName" : "serviceB"
}
```
1. Crie a rota com o comando [create-route](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-route.html) usando o arquivo JSON como entrada.
```
aws appmesh create-route --cli-input-json file://create-route.json
```
------
## Etapa 4: revisar e criar
Revise as configurações em relação às instruções anteriores.
------
#### [ Console de gerenciamento da AWS ]
Se precisar fazer alterações em qualquer seção, selecione **Edit (Editar)**. Quando estiver satisfeito com as configurações, escolha **Create mesh (Criar malha)**.
A tela **Status** mostra todos os recursos de malha que foram criados. Você pode ver no console os recursos criados selecionando **View mesh (Exibir malha)**.
------
#### [ AWS CLI ]
Revise as configurações da malha criada com o comando [describe-mesh](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-mesh.html).
```
aws appmesh describe-mesh --mesh-name apps
```
Revise as configurações do serviço virtual que você criou com o [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 as configurações do nó virtual que você criou com o [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 as configurações do roteador virtual que você criou com o [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 as configurações da rota criada com o 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
```
------
## Etapa 5: Criar recursos adicionais
Para concluir o cenário, é necessário:
+ Criar um nó virtual chamado `serviceBv2` e outro chamado `serviceA`. Ambos os nós virtuais escutam solicitações por meio da porta 80 do HTTP/2. Para o nó virtual `serviceA`, configure um back-end do `serviceb.apps.local`. Todo o tráfego de saída do nó virtual `serviceA` é enviado para o serviço virtual chamado `serviceb.apps.local`. Embora não seja abordado neste guia, também é possível especificar um caminho de arquivo para gravar logs de acesso para um nó virtual.
+ Crie um serviço virtual adicional chamado `servicea.apps.local`, que enviará todo o tráfego diretamente para o nó virtual do `serviceA`.
+ Atualizar a rota do `serviceB` criada em uma etapa anterior para enviar 75% de seu tráfego para o nó virtual do `serviceB` e 25% de seu tráfego para o nó virtual do `serviceBv2`. Com o passar do tempo, você poderá continuar a modificar os pesos até que o `serviceBv2` receba 100% do tráfego. Depois que todo o tráfego for enviado para o `serviceBv2`, você poderá descontinuar o nó virtual do `serviceB` e o serviço real. Conforme você altera os pesos, o código não exigirá nenhuma modificação, porque os nomes de serviço `serviceb.apps.local` virtual e real não são alterados. Lembre-se de que o serviço virtual `serviceb.apps.local` envia tráfego para o roteador virtual, que roteia o tráfego para os nós virtuais. Os nomes de descoberta de serviço para os nós virtuais podem ser alterados a qualquer momento.
------
#### [ Console de gerenciamento da AWS ]
1. No painel de navegação à esquerda, selecione **Meshes (Malhas)**.
1. Selecione a malha `apps` criada em uma etapa anterior.
1. No painel de navegação esquerdo, selecione **Virtual nodes (Nós virtuais)**.
1. Selecione **Create nó virtual (Criar nó virtual)**.
1. Em **Virtual node name (Nome do nó virtual)**, insira **serviceBv2**, em **Service discovery method (Método de descoberta de serviço)**, escolha **DNS** e, em **DNS hostname (Nome de host do DNS)**, insira **servicebv2.apps.local**.
1. Em **Listener configuration (Configuração do Listener)**, selecione **http2** para **Protocol (Protocolo)** e digite **80** para **Port (Porta)**.
1. Selecione **Create nó virtual (Criar nó virtual)**.
1. Selecione **Create nó virtual (Criar nó virtual)** novamente. Digite **serviceA** para o o **Virtual node name (Nome do nó virtual)**. Em **Service discovery method (Método de descoberta de serviços)**, escolha **DNS** e, para **DNS hostname (Nome de host do DNS)**, insira **servicea.apps.local**.
1. Para **Enter a virtual service name (Digite um nome de serviço virtual)** em **New backend (Novo back-end)**, digite **serviceb.apps.local**.
1. Em **Listener configuration (Configuração do Listener)**, escolha **http2** para **Protocol (Protocolo)**, digite **80** para **Port (Porta)** e escolha **Create virtual node (Criar nó virtual)**.
1. No painel de navegação esquerdo, selecione **Virtual routers (Roteadores virtuais)** e, depois, selecione o roteador virtual `serviceB` na lista.
1. Em **Routes (Rotas)**, selecione a rota chamada `ServiceB` criada em uma etapa anterior e escolha **Edit (Editar)**.
1. Em **Targets (Destinos)**, **Virtual node name (Nome do nó virtual)**, altere o valor de **Weight (Peso)** de `serviceB` para **75**.
1. Escolha **Adicionar destino**, depois escolha `serviceBv2` na lista suspensa e defina o valor de **Peso** como **25**.
1. Escolha **Salvar**.
1. No painel de navegação esquerdo, selecione **Virtual services (Serviços virtuais)** e escolha **Create virtual service (Criar serviço virtual)**.
1. Insira **servicea.apps.local** para **Virtual service name (Nome do serviço virtual)**, selecione **Virtual node** para **Provider (Provedor)**, selecione `serviceA` para **Virtual node (Nó virtual)** e escolha **Create virtual service (Criar serviço virtual)**.
------
#### [ AWS CLI ]
1. Crie o nó virtual `serviceBv2`.
1. Crie um arquivo denominado `create-virtual-node-servicebv2.json` com o conteúdo a seguir:
```
{
"meshName": "apps",
"spec": {
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "http2"
}
}
],
"serviceDiscovery": {
"dns": {
"hostname": "serviceBv2.apps.local"
}
}
},
"virtualNodeName": "serviceBv2"
}
```
1. Crie o nó virtual.
```
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicebv2.json
```
1. Crie o nó virtual `serviceA`.
1. Crie um arquivo denominado `create-virtual-node-servicea.json` com o conteúdo a seguir:
```
{
"meshName" : "apps",
"spec" : {
"backends" : [
{
"virtualService" : {
"virtualServiceName" : "serviceb.apps.local"
}
}
],
"listeners" : [
{
"portMapping" : {
"port" : 80,
"protocol" : "http2"
}
}
],
"serviceDiscovery" : {
"dns" : {
"hostname" : "servicea.apps.local"
}
}
},
"virtualNodeName" : "serviceA"
}
```
1. Crie o nó virtual.
```
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicea.json
```
1. Atualize o serviço virtual `serviceb.apps.local` criado em uma etapa anterior para enviar seu tráfego para o roteador virtual `serviceB`. Quando o serviço virtual foi criado originalmente, ele não enviava tráfego para nenhum lugar, já que o roteador virtual `serviceB` ainda não tinha sido criado.
1. Crie um arquivo denominado `update-virtual-service.json` com o conteúdo a seguir:
```
{
"meshName" : "apps",
"spec" : {
"provider" : {
"virtualRouter" : {
"virtualRouterName" : "serviceB"
}
}
},
"virtualServiceName" : "serviceb.apps.local"
}
```
1. Atualize o serviço virtual com o [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. Atualize a rota `serviceB` criada em uma etapa anterior.
1. Crie um arquivo denominado `update-route.json` com o conteúdo a seguir:
```
{
"meshName" : "apps",
"routeName" : "serviceB",
"spec" : {
"http2Route" : {
"action" : {
"weightedTargets" : [
{
"virtualNode" : "serviceB",
"weight" : 75
},
{
"virtualNode" : "serviceBv2",
"weight" : 25
}
]
},
"match" : {
"prefix" : "/"
}
}
},
"virtualRouterName" : "serviceB"
}
```
1. Atualize a rota com o 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. Crie o serviço virtual `serviceA`.
1. Crie um arquivo denominado `create-virtual-servicea.json` com o conteúdo a seguir:
```
{
"meshName" : "apps",
"spec" : {
"provider" : {
"virtualNode" : {
"virtualNodeName" : "serviceA"
}
}
},
"virtualServiceName" : "servicea.apps.local"
}
```
1. Crie o serviço virtual.
```
aws appmesh create-virtual-service --cli-input-json file://create-virtual-servicea.json
```
------
**Resumo da malha**
Antes de criar a malha de serviço, você tinha três serviços reais chamados `servicea.apps.local`, `serviceb.apps.local` e `servicebv2.apps.local`. Além dos serviços reais, agora você tem uma malha de serviços que contém os seguintes recursos que representam os serviços reais:
+ Dois serviços virtuais. O proxy envia todo o tráfego do serviço virtual `servicea.apps.local` para o serviço virtual `serviceb.apps.local` por meio de um roteador virtual.
+ Três nós virtuais chamados `serviceA`, `serviceB` e `serviceBv2`. O proxy Envoy usa as informações de descoberta de serviço configuradas para os nós virtuais para pesquisar os endereços IP dos serviços reais.
+ Um roteador virtual com uma rota que instrui o proxy Envoy a rotear 75% do tráfego de entrada para o nó virtual `serviceB` e 25% do tráfego para o nó virtual `serviceBv2`.
## Etapa 6: Atualizar os serviços
Depois de criar a malha, é necessário concluir as seguintes tarefas:
+ Autorize o proxy Envoy implantado com cada tarefa do Amazon ECS para ler a configuração de um ou mais nós virtuais. Para mais informações sobre como autorizar o proxy, consulte [Autorização de proxy](https://docs.aws.amazon.com/app-mesh/latest/userguide/proxy-authorization.html).
+ Atualize cada uma das definições de tarefa do Amazon ECS existentes para usar o proxy Envoy.
**Credenciais**
O contêiner Envoy exige AWS Identity and Access Management credenciais para assinar solicitações que são enviadas ao serviço App Mesh. Para tarefas do Amazon ECS implantadas com o tipo de execução do Amazon EC2, as credenciais podem vir da [função da instância](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/instance_IAM_role.html) ou de um [perfil do IAM da tarefa](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). As tarefas do Amazon ECS implantadas com o Fargate em contêineres Linux não têm acesso ao servidor de metadados do Amazon EC2 que fornece credenciais de perfil do IAM da instância. Para fornecer as credenciais, você deve associar uma função de tarefa do IAM a qualquer tarefa implantada com o Fargate no tipo de contêiner Linux.
Se uma tarefa for implantada com o tipo de inicialização do Amazon EC2 e o acesso for bloqueado para o servidor de metadados do Amazon EC2, conforme descrito na anotação *Importante* em [Perfil do IAM para tarefas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html), um perfil do IAM de tarefa também deverá ser associada à tarefa. A função que você atribui à instância ou à tarefa deve ter uma política do IAM anexada a ela, conforme descrito em [Autorização de proxy](https://docs.aws.amazon.com/app-mesh/latest/userguide/proxy-authorization.html).
**Para atualizar sua definição de tarefa usando o AWS CLI**
Você usa o AWS CLI comando [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)Amazon ECS. O exemplo de definição de tarefa abaixo mostra como configurar o App Mesh para seu serviço.
**nota**
A configuração do App Mesh para o Amazon ECS por meio do console não está disponível.
### Json da definição de tarefas
**Configuração do proxy**
Para configurar seu serviço do Amazon ECS para usar o App Mesh, a definição de tarefa do serviço deverá ter a seção de configuração de proxy a seguir. Defina a configuração de proxy `type` como `APPMESH` e `containerName` como `envoy`. Defina os seguintes valores de propriedade da maneira adequada.
`IgnoredUID`
O proxy Envoy não roteia o tráfego de processos que usam esse ID de usuário. É possível escolher qualquer ID de usuário que você quiser para esse valor de propriedade, mas esse ID deve ser o mesmo que o ID de `user` do contêiner do Envoy na definição de tarefa. Essa correspondência permite que o Envoy ignore seu próprio tráfego sem usar o proxy. Nossos exemplos usam `1337` para fins históricos.
`ProxyIngressPort`
Essa é a porta de entrada para o contêiner do proxy Envoy. Defina este valor como `15000`.
`ProxyEgressPort`
Essa é a porta de saída para o contêiner do proxy Envoy. Defina este valor como `15001`.
`AppPorts`
Especifique as portas de entrada em que seus contêineres de aplicativos recebem. Neste exemplo, o contêiner do aplicativo escuta na porta `9080`. A porta especificada deve corresponder à porta configurada no listener do nó virtual.
`EgressIgnoredIPs`
O Envoy não faz a intermediação do tráfego para esses endereços IP. Defina esse valor como `169.254.170.2,169.254.169.254`, que ignora o servidor de metadados do EC2 e o endpoint de metadados da tarefa do ECS. O endpoint de metadados fornece perfis do IAM para credenciais de tarefas. É possível adicionar outros endereços.
`EgressIgnoredPorts`
É possível adicionar uma lista de portas separada por vírgulas. O Envoy não faz a intermediação do tráfego para essas portas. Mesmo que você não liste nenhuma porta, a porta 22 será ignorada.
O número máximo de portas de saída que podem ser ignoradas é 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"
}
]
}
```
**Dependência de contêiner de aplicativos do Envoy**
Os contêineres de aplicativos em suas definições de tarefas devem aguardar o bootstrap e o início do proxy Envoy para que possam ser iniciados. Para garantir que isso aconteça, você define uma seção `dependsOn` em cada definição de contêiner de aplicativos para aguardar que o contêiner do Envoy seja relatado como `HEALTHY`. O código a seguir mostra um exemplo de definição de contêiner de aplicativos com essa dependência. Todas as propriedades no exemplo a seguir são necessárias. Alguns dos valores da propriedade também são obrigatórios, mas alguns são*replaceable*.
```
{
"name": "appName",
"image": "appImage",
"portMappings": [{
"containerPort": 9080,
"hostPort": 9080,
"protocol": "tcp"
}],
"essential": true,
"dependsOn": [{
"containerName": "envoy",
"condition": "HEALTHY"
}]
}
```
**Definição de contêiner do Envoy**
Suas definições de tarefas do Amazon ECS devem conter uma imagem de contêiner do App Mesh Envoy.
Todas as regiões [suportadas](https://docs.aws.amazon.com/general/latest/gr/appmesh.html) podem ser *Region-code* substituídas por qualquer região que não seja `me-south-1` `ap-east-1``ap-southeast-3`,`eu-south-1`,`il-central-1`,, `af-south-1` e.
Standard
```
840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
Compatível com 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
```
Compatível com FIPS
```
public.ecr.aws/appmesh/aws-appmesh-envoy:v1.34.13.0-prod-fips
```
**Importante**
Somente a versão v1.9.0.0-prod ou posterior é compatível para uso com o App Mesh.
Você deve usar a imagem do contêiner do App Mesh Envoy até que a equipe do projeto Envoy mescle as alterações compatíveis com o App Mesh. Para obter detalhes adicionais, consulte a [edição do GitHub roteiro](https://github.com/aws/aws-app-mesh-roadmap/issues/10).
Todas as propriedades no exemplo a seguir são necessárias. Alguns dos valores da propriedade também são obrigatórios, mas alguns são*replaceable*.
**nota**
A definição de contêiner do Envoy deve ser marcada como `essential`.
Recomendamos a alocação de `512` unidades de CPU e pelo menos `64` MiB de memória para o contêiner do Envoy. No Fargate, o mínimo que você poderá definir é `1024` MiB de memória.
O nome do nó virtual para o serviço do Amazon ECS deve ser definido como o valor da propriedade `APPMESH_RESOURCE_ARN`. Essa propriedade requer uma versão `1.15.0` ou posterior da imagem do Envoy. Para obter mais informações, consulte [Imagem do Envoy](envoy.md).
O valor da configuração de `user` deve corresponder ao valor `IgnoredUID` da configuração de proxy da definição de tarefa. Neste exemplo, usamos `1337`.
A verificação de integridade mostrada aqui aguarda o contêiner do Envoy ser inicializado corretamente antes de relatar ao Amazon ECS que o contêiner do Envoy está íntegro e pronto para que os contêineres de aplicativos sejam iniciados.
Por padrão, o App Mesh usa o nome do recurso especificado em `APPMESH_RESOURCE_ARN` quando o Envoy está se referindo a si mesmo em métricas e rastreamentos. É possível substituir esse comportamento definindo a variável de ambiente `APPMESH_RESOURCE_CLUSTER` com seu próprio nome. Essa propriedade requer uma versão `1.15.0` ou posterior da imagem do Envoy. Para obter mais informações, consulte [Imagem do Envoy](envoy.md).
O código a seguir mostra um exemplo de definição de contêiner do 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"
}
```
**Exemplos de definições de tarefa**
O exemplo de definições de tarefa do Amazon ECS a seguir mostra como mesclar os exemplos acima em uma definição de tarefa para `taskB`. São fornecidos exemplos de criação de tarefas para ambos os tipos de inicialização do Amazon ECS, com ou sem o uso do AWS X-Ray. Altere os *replaceable* valores, conforme apropriado, para criar definições de tarefas para as tarefas nomeadas `taskBv2` e `taskA` do cenário. Substitua o nome da malha e o nome do nó virtual pelo valor `APPMESH_RESOURCE_ARN` e uma lista de portas em que seu aplicativo escuta pelo valor `AppPorts` da configuração de proxy. Por padrão, o App Mesh usa o nome do recurso especificado em `APPMESH_RESOURCE_ARN` quando o Envoy está se referindo a si mesmo em métricas e rastreamentos. É possível substituir esse comportamento definindo a variável de ambiente `APPMESH_RESOURCE_CLUSTER` com seu próprio nome. Todas as propriedades nos exemplos a seguir são necessárias. Alguns dos valores da propriedade também são obrigatórios, mas alguns são*replaceable*.
Se você estiver executando uma tarefa do Amazon ECS conforme descrito na seção Credenciais, será necessário adicionar um [perfil do IAM de tarefa](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) existente aos exemplos.
**Importante**
O Fargate deve usar um valor de porta maior que 1024.
**Example JSON para definição de tarefas do Amazon ECS: Fargate em contêineres 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 Definição de tarefas JSON para Amazon ECS com - AWS X-Ray Fargate em contêineres Linux**
O X-Ray permite que você colete dados sobre solicitações que um aplicativo atende e fornece ferramentas que você pode usar para visualizar o fluxo de tráfego. O uso do driver X-Ray para Envoy permite que o Envoy relate informações de rastreamento ao X-Ray. Para habilitar o rastreamento do X-Ray, use a [configuração do Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html). Com base na configuração, o Envoy envia dados de rastreamento para o daemon do X-Ray em execução como um contêiner [sidecar](https://docs.aws.amazon.com/xray/latest/devguide/xray-daemon-ecs.html), e o daemon encaminha os rastreamentos para o serviço X-Ray. Assim que os rastreamentos são publicados no X-Ray, você pode usar o console do X-Ray para visualizar o gráfico de chamada de serviço e solicitar detalhes de rastreamento. O seguinte JSON representa uma definição de tarefa para habilitar a integração do 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 definição de tarefa do Amazon ECS: tipo de inicialização do 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 JSON para definição de tarefas do Amazon ECS com AWS X-Ray - tipo de execução 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"
}
```
## Tópicos avançados
### Implantações canário usando o App Mesh
As implantações e lançamentos canário ajudam você a alternar o tráfego entre uma versão antiga de um aplicativo e uma versão recém-implantada. Ele também monitora a integridade da versão recém-implantada. Se houver algum problema com a nova versão, a implantação canário poderá redirecionar automaticamente o tráfego para a versão antiga. As implantações canário oferecem a capacidade de alternar o tráfego entre as versões do aplicativo com mais controle.
Para mais informações sobre como implementar implantações canário para o Amazon ECS usando o App Mesh, consulte [Criar um pipeline com implantações canário para o Amazon ECS usando o App Mesh](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/)
**nota**
Para ver mais exemplos e orientações sobre o App Mesh, consulte o [repositório de exemplos do App Mesh](https://github.com/aws/aws-app-mesh-examples).