Componentes do Amazon ECS Service Connect

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 AWS CloudFormation. A descoberta e a acessibilidade públicas devem ser criadas por último pelo AWS 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 AWS 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 AWS Management Console, 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 AWS Management Console, 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

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

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

Repetições

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

Timeout (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.

nota

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

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 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 ter mais informações, consulte Função do IAM de instância de contêiner do Amazon ECS.

• Somente serviços que usam implantações contínuas são compatíveis com o Service Connect.

• 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 ter mais informações, consulte Proxy do Service Connect.

• 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 ter mais informações, consulte Proxy do Service Connect.

• É possível configurar o Service Connect para usar qualquer namespace do AWS Cloud Map em uma mesma região na mesma Conta da AWS.

• 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 ter mais informações, consulte Componentes do Amazon ECS Service Connect.

• 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 na configuração de serviço do Service Connect.

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 e externa

• Instâncias de contêiner External para Amazon ECS Anywhere não são compatíveis com o Service Connect.

• PPv2

Regiões com Service Connect

O Amazon ECS Service Connect está disponível nas seguintes regiões da AWS:

Nome da região	Região
Leste dos EUA (Ohio)	us-east-2
Leste dos EUA (N. da Virgínia)	us-east-1
Oeste dos EUA (N. da Califórnia)	us-west-1
Oeste dos EUA (Oregon)	us-west-2
África (Cidade do Cabo)	af-south-1
Ásia-Pacífico (Hong Kong)	ap-east-1
Ásia-Pacífico (Jacarta)	ap-southeast-3
Ásia-Pacífico (Mumbai)	ap-south-1
Ásia-Pacífico (Hyderabad)	ap-south-2
Ásia-Pacífico (Osaka)	ap-northeast-3
Ásia-Pacífico (Seul)	ap-northeast-2
Ásia-Pacífico (Singapura)	ap-southeast-1
Ásia-Pacífico (Sydney)	ap-southeast-2
Ásia-Pacífico (Melbourne)	ap-southeast-4
Ásia-Pacífico (Tóquio)	ap-northeast-1
Canadá (Central)	ca-central-1
Oeste do Canadá (Calgary)	ca-west-1
China (Pequim)	cn-north-1 (Observação: o TLS do Service Connect não está disponível nesta região.)
China (Ningxia)	cn-northwest-1 (Observação: o TLS do Service Connect não está disponível nesta região.)
Europa (Frankfurt)	eu-central-1
Europa (Irlanda)	eu-west-1
Europa (Londres)	eu-west-2
Europa (Paris)	eu-west-3
Europa (Milão)	eu-south-1
Europa (Espanha)	eu-south-2
Europa (Estocolmo)	eu-north-1
Europa (Zurique)	eu-central-2
Israel (Tel Aviv)	il-central-1
Oriente Médio (Barém)	me-south-1
Oriente Médio (Emirados Árabes Unidos)	me-central-1
América do Sul (São Paulo)	sa-east-1