

# Componentes do Amazon ECS Service Connect
<a name="service-connect-concepts-deploy"></a>

Ao usar o Amazon ECS Service Connect, você configura cada serviço do Amazon ECS para executar uma aplicação de servidor que recebe solicitações de rede (serviço cliente-servidor) ou para executar uma aplicação cliente que faz as solicitações (serviço cliente).

Quando você se preparar para começar a usar o Service Connect, comece com um serviço de cliente-servidor. É possível adicionar uma configuração do Service Connect a um novo serviço ou a um serviço existente. O Amazon ECS cria um endpoint do Service Connect no namespace. Além disso, o Amazon ECS cria uma nova implantação no serviço para substituir as tarefas que estão em execução no momento.

As tarefas existentes e outras aplicações podem continuar a se conectar aos endpoints existentes e a aplicações externas. Se um serviço cliente-servidor adicionar tarefas por meio da ação de aumentar a escala horizontalmente, novas conexões de clientes serão balanceadas entre todas as tarefas. Se um serviço cliente-servidor for atualizado, as novas conexões de clientes serão balanceadas entre as tarefas da nova versão.

As tarefas existentes não podem ser resolvidas e conectadas ao novo endpoint. Somente novas tarefas com uma configuração do Service Connect no mesmo namespace e que começam a ser executadas após essa implantação podem ser resolvidas e fazer conexão com esse endpoint. 

Isso significa que o operador da aplicação cliente determina quando a configuração da aplicação muda, mesmo que o operador da aplicação do servidor possa alterar sua configuração a qualquer momento. A lista de endpoints no namespace poderá sofrer alterações sempre que qualquer serviço no namespace for implantado. As tarefas existentes e as tarefas de substituição mantêm o mesmo comportamento após a implantação mais recente.

Considere os seguintes exemplos:

Primeiro, suponha que você esteja criando uma aplicação que esteja disponível para a Internet pública em um único modelo do AWS CloudFormation e em uma única pilha do CloudFormation. A descoberta e a acessibilidade públicas devem ser criadas por último pelo CloudFormation, incluindo o serviço de cliente de frontend. Os serviços precisam ser criados nessa ordem para evitar um período em que o serviço do cliente de frontend esteja em execução e disponível ao público, mas um backend não. Isso evita que mensagens de erro sejam enviadas ao público durante esse período. No AWS CloudFormation, você deve usar `dependsOn` para indicar ao CloudFormation que vários serviços do Amazon ECS não podem ser executados em paralelo ou simultaneamente. Você deve adicionar `dependsOn` ao serviço de cliente de frontend para cada serviço cliente-servidor de backend ao qual as tarefas do cliente se conectam.

Em segundo lugar, suponha que exista um serviço de frontend sem a configuração do Service Connect. As tarefas estão se conectando a um serviço de backend existente. Adicione primeiro uma configuração do Service Connect de cliente-servidor ao serviço de backend, usando o mesmo nome no **DNS** ou o `clientAlias` que o frontend usa. Isso cria uma nova implantação para que toda a detecção de reversão da implantação ou o Console de gerenciamento da AWS, a AWS CLI, AWS SDKs e outros métodos revertam o serviço de backend para a implantação e a configuração anteriores. Se você estiver satisfeito com a performance e o comportamento do serviço de backend, adicione uma configuração do Service Connect de cliente ou cliente-servidor ao serviço de frontend. Somente as tarefas da nova implantação usam o proxy do Service Connect que é adicionado a essas novas tarefas. Se você tiver problemas com essa configuração, poderá reverter para sua configuração anterior usando a detecção de reversão de implantação ou o Console de gerenciamento da AWS, a AWS CLI, AWS SDKs e outros métodos para reverter o serviço de backend para a implantação e a configuração anteriores. Se você usar outro sistema de descoberta de serviços baseado no DNS em vez de no Service Connect, qualquer aplicação de frontend ou cliente começará a usar novos endpoints e uma configuração alterada do endpoint após a expiração do cache de DNS local, que normalmente leva várias horas.

## Redes
<a name="service-connect-concepts-network"></a>

Por padrão, o proxy do Service Connect atua como receptor na `containerPort` usando o mapeamento da porta de definição de tarefa. As regras do seu grupo de segurança devem permitir o tráfego de entrada (ingresso) para esta porta proveniente das sub-redes em que os clientes serão executados.

Mesmo se você definir um número de porta na configuração do serviço do Service Connect, isso não alterará a porta do serviço cliente-servidor que o proxy do Service Connect recebe. Quando você define esse número de porta, o Amazon ECS altera a porta do endpoint ao qual os serviços do cliente se conectam no proxy do Service Connect dentro dessas tarefas. O proxy no serviço cliente se conecta ao proxy no serviço cliente-servidor usando a `containerPort`.

Se você quiser alterar a porta na qual o proxy do Service Connect recebe, altere a `ingressPortOverride` na configuração do Service Connect do serviço cliente-servidor. Se você alterar esse número de porta, deverá permitir o tráfego de entrada na porta que está sendo usada pelo tráfego para esse serviço.

O tráfego que suas aplicações enviam para os serviços do Amazon ECS configurados para o Service Connect exige que a Amazon VPC e as sub-redes tenham regras de tabela de rotas e regras de ACL de rede que permitam os números de porta `containerPort` e `ingressPortOverride` que você está usando.

 É possível usar o Service Connect para enviar tráfego entre VPCs. Os mesmos requisitos para as regras da tabela de rotas, para as ACLs da rede e para os grupos de segurança se aplicam a ambas as VPCs.

Por exemplo, dois clusters criam tarefas em VPCs diferentes. Um serviço em cada cluster é configurado para usar o mesmo namespace. As aplicações nesses dois serviços podem resolver todos os endpoints no namespace sem qualquer configuração DNS da VPC. No entanto, os proxies não podem se conectar, a menos que o emparelhamento de VPC, as tabelas de rotas de VPC ou de sub-rede e as ACLs da rede da VPC permitam o tráfego nos números de porta `containerPort` e `ingressPortOverride`.

Para tarefas que usam o modo de rede `bridge`, você deve criar um grupo de segurança com uma regra de entrada que permita tráfego no intervalo dinâmico superior de portas. Em seguida, atribua o grupo de segurança a todas as instâncias do EC2 no cluster do Service Connect.

## Proxy do Service Connect
<a name="service-connect-concepts-proxy"></a>

Se você criar ou atualizar um serviço com a configuração do Service Connect, o Amazon ECS adicionará um novo contêiner a cada nova tarefa à medida que elas forem iniciadas. Esse padrão de uso de um contêiner separado é chamado de um `sidecar`. Esse contêiner não está presente na definição da tarefa e você não pode configurá-lo. O Amazon ECS gerencia a configuração do Contêiner no serviço. Isso permite reutilizar as mesmas definições de tarefa entre diversos serviços, namespaces e tarefas sem a necessidade de usar o Service Connect.

**Recursos de proxy**
+ Para definições de tarefas, é necessário configurar os parâmetros de CPU e de memória. 

  Recomendamos a adição de 256 unidades de CPU extras e pelo menos 64 MiB de memória à CPU e à memória da tarefa para o contêiner do proxy do Service Connect. No AWS Fargate, a menor quantidade de memória que você pode definir é 512 MiB. No Amazon EC2, a memória de definição de tarefa é obrigatória.
+ Para o serviço, você define a configuração do log na configuração do Service Connect.
+ Se você espera que as tarefas desse serviço recebam mais de 500 solicitações por segundo em sua carga máxima, recomendamos a adição de 512 unidades de CPU à sua CPU de tarefas nessa definição de tarefa para o contêiner do proxy do Service Connect.
+ Se você espera criar mais de 100 serviços do Service Connect no namespace ou 2.000 tarefas no total em todos os serviços do Amazon ECS dentro do namespace, recomendamos a adição de 128 MiB de memória à sua memória de tarefas para o contêiner do proxy do Service Connect. Você deve fazer isso em todas as definições de tarefa usadas por todos os serviços do Amazon ECS no namespace.

**Configuração do proxy**  
Suas aplicações se conectam ao proxy no contêiner de arquivo associado na mesma tarefa em que a aplicação está. O Amazon ECS configura a tarefa e os contêineres para que as aplicações se conectem ao proxy somente quando a aplicação estiver conectada aos nomes de endpoint no mesmo namespace. Todos os outros tráfegos não usam o proxy. O outro tráfego inclui endereços IP na mesma VPC, endpoints de serviço da AWS e tráfego externo.

**Balanceamento de carga**  
O Service Connect configura o proxy para usar a estratégia round-robin para balancear a carga entre as tarefas em um endpoint do Service Connect. O proxy local que está na tarefa de onde vem a conexão escolhe uma das tarefas no serviço cliente-servidor que fornece o endpoint.  
Por exemplo, considere uma tarefa que executa o WordPress em um serviço que está configurado como um *serviço cliente* em um namespace chamado *local*. Há outro serviço com duas tarefas que executam o banco de dados MySQL. Esse serviço é configurado para fornecer um endpoint chamado `mysql` por meio do Service Connect no mesmo namespace. Na tarefa do WordPress, a aplicação do WordPress se conecta ao banco de dados usando o nome do endpoint. As conexões para esse nome serão encaminhadas ao proxy que está em execução em um contêiner de arquivo associado na mesma tarefa. Em seguida, o proxy pode se conectar a qualquer uma das tarefas do MySQL usando a estratégia round-robin.  
Estratégias de balanceamento de carga: round-robin

**Detecção de discrepâncias**  
Esse recurso usa dados que o proxy tem sobre conexões falhadas anteriores para evitar o envio de novas conexões aos hosts que tiveram as conexões com falha. O Service Connect configura o recurso de detecção de valores discrepantes do proxy para fornecer verificações de integridade passivas.  
usando o exemplo anterior, o proxy pode se conectar a qualquer uma das tarefas do MySQL. Se o proxy fez várias conexões com uma tarefa específica do MySQL e 5 ou mais conexões falharam nos últimos 30 segundos, o proxy evitará essa tarefa do MySQL por 30 a 300 segundos.

**Novas tentativas**  
O Service Connect configura o proxy para tentar novamente a conexão que passa pelo proxy e falha, e a segunda tentativa evita o uso do host da conexão anterior. Isso garante que cada conexão por meio do Service Connect não falhe por motivos pontuais.  
Número de novas tentativas: 2

**Tempo limite**  
O Service Connect configura o proxy para aguardar o máximo de tempo até que suas aplicações cliente-servidor respondam. O valor de tempo limite padrão é 15 segundos, mas pode ser atualizado.  
Parâmetros opcionais:  
**idleTimeout**: o tempo, em segundos, durante o qual uma conexão permanece ativa, embora ociosa. Um valor de `0` desabilita `idleTimeout`.  
O padrão de `idleTimeout` para `HTTP`/`HTTP2`/`GRPC` é 5 minutos.  
O `idleTimeout` padrão para `TCP` é 1 hora.  
**perRequestTimeout**: a quantidade de tempo de espera para que o upstream responda com uma resposta completa por solicitação. Um valor `0` desativa o parâmetro `perRequestTimeout`. Isso poderá ser definido somente quando o `appProtocol` para o contêiner da aplicação for `HTTP`/`HTTP2`/`GRPC`. O padrão é 15 segundos.  
Se `idleTimeout` estiver definido para um tempo menor que `perRequestTimeout`, a conexão será fechada quando `idleTimeout` for atingido e não o `perRequestTimeout`.

## Considerações
<a name="service-connect-considerations"></a>

Considere o seguinte ao usar o Service Connect:
+ As tarefas que são executadas no Fargate devem usar a versão da plataforma `1.4.0` ou versões posteriores do Linux para Fargate a fim de usar o Service Connect.
+ A versão do agente do Amazon ECS na instância de contêiner deve ser `1.67.2` ou versões posteriores.
+ As instâncias de contêiner devem executar a versão `20230428` ou posterior da AMI do Amazon Linux 2023 otimizada para o Amazon ECS, ou a versão `2.0.20221115` da AMI do Amazon Linux 2 otimizada para o Amazon ECS para usar o Service Connect. Essas versões têm o agente do Service Connect, além do agente de contêiner do Amazon ECS. Para obter mais informações sobre o agente do Service Connect, consulte [Agente do Service Connect do Amazon ECS](https://github.com/aws/amazon-ecs-service-connect-agent) no GitHub.
+ As instâncias de contêiner devem ter a permissão `ecs:Poll` para o recurso `arn:aws:ecs:region:0123456789012:task-set/cluster/*`. Se você estiver usando `ecsInstanceRole`, não precisará adicionar outras permissões. A política gerenciada `AmazonEC2ContainerServiceforEC2Role` tem as permissões necessárias. Para obter mais informações, consulte [Função do IAM de instância de contêiner do Amazon ECS](instance_IAM_role.md).
+ As tarefas que usam o modo de rede `bridge` e o Service Connect não são compatíveis com parâmetro de definição de contêiner `hostname`.
+ As definições de tarefa devem definir o limite de memória da tarefa para usar o Service Connect. Para obter mais informações, consulte [Proxy do Service Connect](#service-connect-concepts-proxy).
+ Não há suporte para as definições de tarefas que estabelecem limites de memória do contêiner.

  É possível definir limites de memória nos seus contêineres, mas deve definir o limite de memória da tarefa como um número maior que a soma dos limites de memória dos contêineres. A CPU e a memória adicionais nos limites de tarefas que não são alocadas nos limites de contêineres são usadas pelo contêiner do proxy do Service Connect e por outros contêineres que não definem limites de contêineres. Para obter mais informações, consulte [Proxy do Service Connect](#service-connect-concepts-proxy).
+ É possível configurar o Service Connect para usar qualquer namespace do AWS Cloud Map na mesma região da mesma Conta da AWS ou compartilhado com sua Conta da AWS usando o AWS Resource Access Manager. Para obter mais informações sobre o uso de namespaces compartilhados, consulte [Amazon ECS Service Connect com Namespaces compartilhados do AWS Cloud Map](service-connect-shared-namespaces.md).
+ Cada serviço pode pertencer a somente um namespace.
+ Há suporte somente para as tarefas criadas pelos serviços. 
+ Todos os endpoints devem ser exclusivos dentro de um namespace.
+ Todos os nomes de descoberta devem ser exclusivos dentro de um namespace.
+ Você deve reimplantar os serviços existentes para que as aplicações possam resolver novos endpoints. Novos endpoints adicionados ao namespace após a implantacão mais recente não serão adicionados à configuração da tarefa. Para obter mais informações, consulte [Componentes do Amazon ECS Service Connect](#service-connect-concepts-deploy).
+ O Service Connect não exclui namespaces quando os clusters são excluídos. Você deve excluir os namespaces no AWS Cloud Map.
+ O tráfego do Application Load Balancer usa como padrão o roteamento por meio do agente do Service Connect no modo de rede `awsvpc`. Se quiser que o tráfego que não seja de serviço ignore o agente do Service Connect, use o parâmetro `[ingressPortOverride](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)` na configuração de serviço do Service Connect.
+ O Service Connect com TLS não é compatível com o modo de rede `bridge`. Só há compatibilidade com o modo de rede `awsvpc`.
+ No modo `awsvpc`, o proxy do Service Connect encaminha o tráfego para o host local IPv4 `127.0.0.1` para serviços em configurações somente IPv4 e de pilha dupla. Para serviços na configuração somente IPv6, o proxy encaminha o tráfego para o host local IPv6 `::1`. Recomendamos configurar suas aplicações para receber os dois hosts locais para uma experiência perfeita quando um serviço é atualizado da configuração somente IPv4 ou de pilha dupla para somente IPv6. Para obter mais informações, consulte [Opções da rede de tarefas do Amazon ECS para o EC2](task-networking.md) e [Opções de redes de tarefas do Amazon ECS para o Fargate](fargate-task-networking.md).

**O Service Connect não é compatível com:**
+ Contêineres do Windows
+ HTTP 1.0
+ Tarefas autônomas
+ Serviços que usam os tipos de implantação azul/verde baseada no CodeDeploy e externa
+ Instâncias de contêiner `External` para Amazon ECS Anywhere não são compatíveis com o Service Connect.
+ PPv2
+ Modo do FIPS