3 <= 0.5 * 1 => 200| 3 (o valor calculado é menor que o mínimo) | | 25 |
3 <= 0.5 * 25 => 200| 13 (o valor é arredondado para cima) | | 400 |
3 <= 0.5 * 400 => 200| 200 | | 800 |
3 <= 0.5 * 800 => 200| 200 (o valor calculado é maior do que o máximo) | Por exemplo, quando o limite é 3, o disjuntor começa com a contagem de falhas definida em 0. Quando uma tarefa não atinge o estado `RUNNING`, o disjuntor de implantação aumenta a contagem de falhas em um. Quando a contagem de falhas é igual a 3, a implantação é marcada como `FAILED`. Para obter exemplos adicionais sobre como usar a opção de reversão, consulte [Announcing Amazon ECS deployment circuit breaker](https://aws.amazon.com/blogs/containers/announcing-amazon-ecs-deployment-circuit-breaker/) (Anunciar o disjuntor de implantação do Amazon ECS). # Como os alarmes do CloudWatch realizam a detecção de falhas de implantação do Amazon ECS É possível configurar o Amazon ECS para definir que a implantação falhou quando ele detectar que um alarme especificado do CloudWatch entrou no estado de `ALARM`. Opcionalmente, você pode definir a configuração para reverter uma implantação com falha para a última implantação concluída. O seguinte exemplo de `create-service` da AWS CLI mostra como criar um serviço do Linux quando os alarmes de implantação são usados com a opção de reversão. ``` aws ecs create-service \ --service-name MyService \ --deployment-controller type=ECS \ --desired-count 3 \ --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \ --task-definition sample-fargate:1 \ --launch-type FARGATE \ --platform-family LINUX \ --platform-version 1.4.0 \ --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}" ``` Considere o seguinte quando usar o método de alarmes do Amazon CloudWatch em um serviço. + A duração em que as revisões de serviço azul e verde são executadas simultaneamente após a mudança do tráfego de produção. O Amazon ECS calcula esse período com base na configuração do alarme associada à implantação. Você não pode definir esse valor. + O parâmetro de solicitação `deploymentConfiguration` agora contém o tipo de dados `alarms`. É possível especificar os nomes dos alarmes, se deve usar o método e se deve iniciar uma reversão quando os alarmes indicarem uma falha na implantação. Para obter mais informações, consulte [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) na *Referência de API do Amazon Elastic Container Service*. + A resposta `DescribeServices` fornece um insight sobre o estado de uma implantação, o `rolloutState` e o `rolloutStateReason`. Quando uma nova implantação é iniciada, seu estado começa como `IN_PROGRESS`. Quando o serviço atinge um estado estacionário e o tempo de incorporação está concluído, o estado da implantação passa a ser `COMPLETED`. Se o serviço não conseguir alcançar um estado estacionário e o alarme entrar no estado `ALARM`, a implantação passará para o estado `FAILED`. Uma implantação em um estado `FAILED` não iniciará qualquer nova tarefa. + Além dos eventos de alteração de estado de implantação do serviço que o Amazon ECS envia para implantações que foram iniciadas e concluídas, o Amazon ECS também envia um evento quando uma implantação que usa alarmes apresenta falha. Esses eventos fornecem detalhes sobre o motivo da falha de uma implantação ou se uma implantação foi iniciada devido a uma reversão. Para obter mais informações, consulte [Eventos de alteração no estado da implantação do serviço do Amazon ECS](ecs_service_deployment_events.md). + Se uma nova implantação for iniciada porque uma implantação anterior tiver apresentado falha e a reversão tiver sido ativada, o campo `reason` do evento de alteração de estado de implantação do serviço indicará que a implantação foi iniciada devido a uma reversão. + Se você usar o disjuntor de implantação e os alarmes do Amazon CloudWatch para detectar falhas, qualquer um deles poderá iniciar uma falha de implantação assim que os critérios de qualquer um dos métodos forem atendidos. Uma reversão ocorre quando você usa a opção de reversão para o método que iniciou a falha de implantação. + Os alarmes do Amazon CloudWatch só são compatíveis com serviços do Amazon ECS que usam o controlador de implantação de atualização contínua (`ECS`). + É possível configurar essa opção usando o console do Amazon ECS ou a AWS CLI. Para obter mais informações, consulte [Criar um serviço usando parâmetros definidos](create-service-console-v2.md#create-custom-service) e [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) na *Referência da AWS Command Line Interface*. + É possível observar que o status da implantação permanece `IN_PROGRESS` por um período prolongado. A razão para isso é que o Amazon ECS não altera o status até que ele tenha excluído a implantação ativa e isso não acontece até depois do tempo de incorporação. Dependendo da configuração do alarme, a implantação aparentemente pode demorar alguns minutos a mais do que quando você não usa alarmes (mesmo que o novo conjunto de tarefas primárias tenha um aumento na escala verticalmente e a antiga implantação tenha uma redução na escala verticalmente). Se você usa os tempos limite do CloudFormation, considere aumentar os tempos limite. Para obter mais informações, consulte [Criar condições de espera em um modelo](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html) no *Guia do usuário do AWS CloudFormation*. + O Amazon ECS chama `DescribeAlarms` para pesquisar os alarmes. As chamadas para `DescribeAlarms` são contabilizadas nas cotas de serviço do CloudWatch associadas à sua conta. Se você tiver outros serviços da AWS que chamem `DescribeAlarms`, pode haver um impacto na pesquisa dos alarmes pelo Amazon ECS. Por exemplo, se outro serviço fizer chamadas para `DescribeAlarms` suficientes para atingir a cota, esse serviço será submetido a controle de utilização e o Amazon ECS também será submetido a controle de utilização e não poderá sondar alarmes. Se um alarme for gerado durante o período de controle de utilização, o Amazon ECS poderá perder o alarme e a reversão poderá não ocorrer. Não há outro impacto na implantação. Para obter mais informações sobre cotas de serviço do CloudWatch, consulte [Cotas de serviço do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm) no *Guia do usuário do CloudWatch*. + Se um alarme estiver no estado `ALARM` no início de uma implantação, o Amazon ECS não monitorará os alarmes durante a implantação (o Amazon ECS ignora a configuração do alarme). Esse comportamento aborda o caso em que você deseja iniciar uma nova implantação para corrigir uma falha de implantação inicial. ## Alarmes recomendados Recomendamos que você use as seguintes métricas de alarme: + Se você usa um Application Load Balancer, use as métricas `HTTPCode_ELB_5XX_Count` e`HTTPCode_ELB_4XX_Count` do Application Load Balancer. Essas métricas verificam picos de HTTP. Para obter mais informações sobre as métricas do Application Load Balancer, consulte [CloudWatch metrics for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) (Métricas do CloudWatch para seu Application Load Balancer) no *Guia do usuário para Application Load Balancers*. + Se você tiver uma aplicação existente, use as métricas `CPUUtilization` e `MemoryUtilization`. Essas métricas verificam a porcentagem de CPU e memória que o cluster ou serviço usa. Para obter mais informações, consulte [Considerações](cloudwatch-metrics.md#enable_cloudwatch). + Se você usa filas do Amazon Simple Queue Service nas suas tarefas, use a métrica `ApproximateNumberOfMessagesNotVisible` do Amazon SQS. Essa métrica verifica o número de mensagens na fila que estão atrasadas e indisponíveis para leitura imediata. Para obter mais informações sobre métricas do Amazon SQS, consulte [Métricas disponíveis do CloudWatch para o Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) no *Guia do desenvolvedor do Amazon Simple Queue Service*. ## Tempo de incorporação Quando você usa a opção de reversão para suas implantações de serviços, o Amazon ECS espera mais tempo após a implantação da revisão do serviço de destino antes de enviar um alarme do CloudWatch. Isso é conhecido como tempo de incorporação. Esse tempo começa depois que: + Todas as tarefas de uma revisão do serviço de destino estão em execução e em um estado íntegro + As revisões do serviço de origem são reduzidas para 0% O tempo de incorporação padrão é inferior a cinco minutos. A implantação do serviço é marcada como concluída após o término do tempo de incorporação. Você pode configurar o tempo de incorporação para uma implantação contínua. Ao usar os alarmes do CloudWatch para detectar falhas, se você alterar o tempo de incorporação e decidir que deseja o padrão do Amazon ECS, defina manualmente o tempo de incorporação. # Ganchos do ciclo de vida para implantações de serviços do Amazon ECS Quando uma implantação é iniciada, ela passa pelos estágios do ciclo de vida. Esses estágios podem estar em estados como IN\$1PROGRESS ou SUCCESSFUL. Você pode usar ganchos doe ciclo de vida, que são funções do Lambda que o Amazon ECS executa em seu nome em estágios específicos do ciclo de vida. As funções podem ser uma das seguintes: + Uma API assíncrona que valida a verificação de integridade em até 15 minutos. + Uma API de polling que inicia outro processo assíncrono que avalia a conclusão do gancho do ciclo de vida. Depois que a função terminar de ser executada, ela deve retornar a `hookStatus` para que a implantação continue. Se `hookStatus` não for retornado, ou se a função falhar, a implantação será revertida. Confira abaixo os valores de `hookStatus`: + `SUCCEEDED`: a implantação continua até o próximo estágio do ciclo de vida + `FAILED`: a implantação será revertida para a última implantação bem-sucedida. + `IN_PROGRESS`: o Amazon ECS executa a função novamente após um curto período. Por padrão, é um intervalo de 30 segundos, no entanto, esse valor é personalizável retornando um `callBackDelay` junto com `hookStatus`. O exemplo a seguir mostra como retornar um `hookStatus` com um atraso de retorno de chamada personalizado. Neste exemplo, o Amazon ECS tentaria novamente esse gancho em 60 segundos, em vez dos 30 segundos padrão: ``` { "hookStatus": "IN_PROGRESS", "callBackDelay": 60 } ``` Quando ocorre uma reversão, o Amazon ECS executa os ganchos do ciclo de vida para os seguintes estágios do ciclo de vida: + PRODUCTION\$1TRAFFIC\$1SHIFT + TEST\$1TRAFFIC\$1SHIFT ## Cargas úteis do ciclo de vida Quando você configura ganchos do ciclo de vida para suas implantações de serviços do ECS, o Amazon ECS invoca esses ganchos em estágios específicos do processo de implantação. Cada estágio do ciclo de vida fornece uma carga útil JSON com informações sobre o estado atual da implantação. Este documento descreve a estrutura da carga útil para cada estágio do ciclo de vida. ### Estrutura de carga útil comum Todas as cargas úteis do estágio do ciclo de vida incluem os seguintes campos comuns: + `serviceArn`: o nome do recurso da Amazon (ARN) do serviço. + `targetServiceRevisionArn`: o ARN da revisão do serviço de destino que está sendo implantada. + `testTrafficWeights`: um mapa dos ARNs de revisão de serviço com suas porcentagens de peso de tráfego de teste correspondentes. + `productionTrafficWeights`: um mapa dos ARNs de revisão de serviço com suas porcentagens de peso de tráfego de produção correspondentes. ### Cargas úteis do estágio do ciclo de vida #### RECONCILE\$1SERVICE Este estágio ocorre no início do processo de implantação, quando o serviço está sendo reconciliado. Veja a seguir um exemplo de carga útil para esse estágio do ciclo de vida. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 }, "productionTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 } } ``` **Expectativas nesta fase:** + O conjunto de tarefas primárias está na escala de 0% #### PRE\$1SCALE\$1UP Este estágio ocorre antes que as novas tarefas tenha a escala aumentada verticalmente. Veja a seguir um exemplo de carga útil para esse estágio do ciclo de vida. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Expectativas nesta fase:** + As tarefas de revisão do serviço verde estão em escala de 0% #### POST\$1SCALE\$1UP Este estágio ocorre após as novas tarefas terem tido a escala aumentada verticalmente e estarem íntegras. Veja a seguir um exemplo de carga útil para esse estágio do ciclo de vida. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Expectativas nesta fase:** + As tarefas de revisão do serviço verde estão em escala de 100% + As tarefas na revisão do serviço verde estão íntegras #### TEST\$1TRAFFIC\$1SHIFT Este estágio ocorre quando o tráfego de teste está sendo transferido para as tarefas de revisão do serviço verde. Veja a seguir um exemplo de carga útil para esse estágio do ciclo de vida. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 }, "productionTrafficWeights": {} } ``` **Expectativas nesta fase:** + O tráfego de teste está em processo de migração para as tarefas de revisão do serviço verde. #### POST\$1TEST\$1TRAFFIC\$1SHIFT Este estágio ocorre após o tráfego de teste ter sido totalmente transferido para as novas tarefas. Veja a seguir um exemplo de carga útil para esse estágio do ciclo de vida. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Expectativas nesta fase:** + 100% do tráfego de teste foi direcionado para as tarefas de revisão do serviço verde. #### PRODUCTION\$1TRAFFIC\$1SHIFT Este estágio ocorre quando o tráfego de produção está sendo transferido para as tarefas de revisão do serviço verde. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 } } ``` **Expectativas nesta fase:** + O tráfego de produção está em processo de migração para a revisão do serviço verde. #### POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT Este estágio ocorre após o tráfego de produção ter sido totalmente transferido para as tarefas de revisão do serviço verde. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **Expectativas nesta fase:** + 100% do tráfego de produção foi direcionado para as tarefas de revisão do serviço verde. ### Categorias de estágio do ciclo de vida Os estágios do ciclo de vida se encaixam em duas categorias: 1. **Estágios de invocação única**: estes estágios são invocados somente uma vez durante a implantação de um serviço: + PRE\$1SCALE\$1UP + POST\$1SCALE\$1UP + POST\$1TEST\$1TRAFFIC\$1SHIFT + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT 1. **Estágios de invocação recorrente**: estes estágios podem ser invocados várias vezes durante a implantação de um serviço, por exemplo, quando ocorre uma operação de reversão: + TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT ### Status de implantação durante ganchos do ciclo de vida Enquanto os ganchos do ciclo de vida estiverem em execução, o status de implantação será `IN_PROGRESS` para todos os estágios do ciclo de vida. | Estágio do ciclo de vida | Status da implantação | | --- | --- | | RECONCILE\$1SERVICE | IN\$1PROGRESS | | PRE\$1SCALE\$1UP | IN\$1PROGRESS | | POST\$1SCALE\$1UP | IN\$1PROGRESS | | TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | | POST\$1TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | | PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | # Parar implantações de serviços do Amazon ECS É possível interromper manualmente uma implantação quando uma implantação com falha não é detectada pelo disjuntor ou pelos alarmes do CloudWatch. Os seguintes tipos de paradas estão disponíveis: + Reversão: essa opção reverte a implantação do serviço para a revisão de serviço anterior. Você poderá usar essa opção mesmo que não tenha configurado a implantação do serviço para a opção de reversão. É possível interromper uma implantação que esta em qualquer um dos estados apresentados a seguir. Para obter mais informações sobre estados de implantações de serviços, consulte [Visualize o histórico de serviços usando implantações de serviços do Amazon ECS](service-deployment.md). + PENDING: a implantação do serviço passa para o estado ROLLBACK\$1REQUESTED e, em seguida, a operação de reversão é iniciada. + IN\$1PROGRESS: a implantação do serviço passa para o estado ROLLBACK\$1REQUESTED e, em seguida, a operação de reversão é iniciada. + STOP\$1REQUESTED: a implantação do serviço continua a parar. + ROLLBACK\$1REQUESTED: a implantação do serviço continua a operação de reversão. + ROLLBACK\$1IN\$1PROGRESS: a implantação do serviço continua a operação de reversão. ## Procedimento Antes de começar, configure as permissões necessárias para visualizar as implantações de serviços. Para obter mais informações, consulte [Permissões necessárias para visualizar implantações de serviço do Amazon ECS](service-deployment-permissions.md). ------ #### [ Amazon ECS Console ] 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. Na página de detalhes da implantação, escolha **Implantações**. A página de implantações é exibida. 1. Em **Implantação em andamento**, escolha **Reverter**. Em seguida, na janela janela de confirmação, escolha **Reverter**. ------ #### [ AWS CLI ] 1. Execute `list-service-deployments` para recuperar o ARN da implantação do serviço. Substitua os valores das *user-input* pelos seus. ``` aws ecs list-service-deployments --cluster cluster-name --service service-name ``` Observe o `serviceDeploymentArn` da implantação que deseja interromper. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/cluster-name/service-name", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/cluster-name", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/cluster-name/service-name/4980306466373577095", "status": "SUCCESSFUL" } ] } ``` 1. Executar `stop-service-deployments`. Use o `serviceDeploymentArn` que foi devolvido de `list-service-deployments`. Substitua os valores das *user-input* pelos seus. ``` aws ecs stop-service-deployment --service-deployment-arn arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 --stop-type ROLLBACK ``` ------ ## Próximas etapas Decida quais alterações precisam ser feitas no serviço e, em seguida, atualize-o. Para obter mais informações, consulte [Atualizar um serviço do Amazon ECS](update-service-console-v2.md). # Implantação de serviços do Amazon ECS por meio da substituição de tarefas Ao criar um serviço que usa o tipo de implantação *atualização cumulativa* (`ECS`), o agendador de serviços do Amazon ECS substitui as tarefas que estão em execução por novas tarefas. O número de tarefas que o Amazon ECS adiciona ou remove do serviço durante uma atualização contínua é controlado pela configuração de implantação do serviço. O Amazon ECS usa os seguintes parâmetros para determinar o número de tarefas: + O `minimumHealthyPercent` representa o limite inferior do número de tarefas que devem estar sendo executadas e íntegras para um serviço durante uma implantação incremental ou quando uma instância de contêiner está sendo drenada, como porcentagem do número desejado de tarefas para o serviço. Esse valor é arredondado para cima. Por exemplo, se a porcentagem mínima de integridade é `50` e a contagem de tarefas desejadas é quatro, o programador pode interromper duas tarefas existentes antes de iniciar duas novas tarefas. Da mesma forma, se a porcentagem mínima de integridade é 75% e a contagem de tarefas desejada é dois, o programador não pode parar quaisquer tarefas porque o valor resultante também é dois. + O `maximumPercent` representa o limite superior do número de tarefas que devem estar sendo executadas para um serviço durante uma implantação incremental ou quando uma instância de contêiner está sendo drenada, como porcentagem do número desejado de tarefas para um serviço. Esse valor é arredondado para baixo. Por exemplo, se a porcentagem máxima for `200` e a contagem de tarefas desejadas for quatro, o programador poderá iniciar quatro novas tarefas antes de interromper quatro tarefas existentes. Da mesma forma, se a porcentagem máxima de integridade é `125` e a contagem de tarefas desejada é três, o programador não pode iniciar quaisquer tarefas porque o valor resultante também é três. Durante uma implantação incremental, quando a integridade das tarefas é perdida, o Amazon ECS as substitui para manter a definição `minimumHealthyPercent` do serviço e proteger a disponibilidade. As tarefas não íntegras são substituídas usando a mesma revisão de serviço à qual pertencem. Isso garante que a substituição de tarefas não íntegras na revisão de origem seja independente de falhas das tarefas na revisão de destino. Quando a definição `maximumPercent` permite, o programador inicia as tarefas de substituição antes de interromper as não íntegras. Se o parâmetro `maximumPercent` limitar o programador a iniciar uma tarefa de substituição primeiro, o programador interromperá uma tarefa não íntegra, uma de cada vez, para liberar capacidade antes de iniciar uma tarefa de substituição. **Importante** Ao definir um percentual mínimo ou um percentual máximo de integridade, você deve garantir que o programador possa interromper ou iniciar pelo menos uma tarefa quando uma implantação for iniciada. Se seu serviço tiver uma implantação travada devido a uma configuração de implantação inválida, será enviada uma mensagem de evento de serviço. Para obter mais informações, consulte [O serviço (*service-name*) não conseguiu interromper ou iniciar tarefas durante uma implantação devido à configuração de implantação do serviço. Atualize o valor minimumHealthyPercent ou maximumPercent e tente novamente.](service-event-messages-list.md#service-event-messages-7). As implantações contínuas têm dois métodos que fornecem uma maneira de identificar rapidamente quando uma implantação de serviço falhou: + [Como o disjuntor de implantação do Amazon ECS realiza a detecção de falhas](deployment-circuit-breaker.md) + [Como os alarmes do CloudWatch realizam a detecção de falhas de implantação do Amazon ECS](deployment-alarm-failure.md) Os métodos podem ser usados separadamente ou em conjunto. Quando ambos os métodos são usados, a implantação é definida como falha assim que os critérios de falha de qualquer um dos métodos de falha são satisfeitos. Siga as diretrizes a seguir para ajudar a determinar qual método será usado: + Disjuntor: use este método se quiser interromper uma implantação quando as tarefas não puderem ser iniciadas. + Alarmes do CloudWatch: use este método quando quiser interromper uma implantação com base nas métricas da aplicação. Ambos os métodos permitem a reversão para a revisão de serviço anterior. ## Resolução da imagem do contêiner Por padrão, o Amazon ECS resolve tags de imagem de contêiner especificadas na definição da tarefa para resumos de imagens de contêiner. Se você criar um serviço que executa e mantém uma única tarefa, essa tarefa será usada para estabelecer resumos de imagem para as imagens no contêiner. Se você criar um serviço que executa e mantém várias tarefas, a primeira tarefa iniciada pelo agendador de serviços durante a implantação será usada para estabelecer resumos de imagens para os contêineres nas tarefas. Se três ou mais tentativas de estabelecer os resumos de imagens no contêiner falharem, a implantação continuará sem a resolução do resumo da imagem. Se o disjuntor de implantação estiver habilitado, a implantação também falhará e será revertida. Depois que os resumos de imagens no contêiner forem estabelecidos, o Amazon ECS usará os resumos para iniciar qualquer outra tarefa desejada e para qualquer atualização futura do serviço. Isso faz com que todas as tarefas em um serviço sempre executem imagens de contêiner idênticas, o que resultará na consistência de versões do seu software. É possível configurar esse comportamento para cada contêiner em sua tarefa usando o parâmetro `versionConsistency` na definição do contêiner. Para obter mais informações, consulte [versionConsistency](task_definition_parameters.md#ContainerDefinition-versionconsistency). **nota** Versões do Amazon ECS Agent anteriores à `1.31.0` não oferecem suporte à resolução de resumos de imagens. As versões do agente `1.31.0` a `1.69.0` oferecem suporte à resolução de resumos de imagens somente para imagens enviadas aos repositórios do Amazon ECR. As versões do agente `1.70.0` ou superiores oferecem suporte à resolução de resumos de imagens para todas as imagens. A versão mínima da plataforma Linux para o Fargate para resolução de resumos de imagens é `1.3.0`. A versão mínima da plataforma Windows para o Fargate para resolução de resumos de imagens é `1.0.0`. O Amazon ECS não captura resumos de contêineres auxiliares gerenciados pelo Amazon ECS, como o agente de segurança do Amazon GuardDuty ou o proxy do Service Connect. Para reduzir a latência potencial associada à resolução de imagens de contêineres em serviços com várias tarefas, execute o agente do Amazon ECS versão `1.83.0` ou superior em instâncias de contêiner do EC2. Para evitar latência potencial, especifique os resumos de imagens do contêiner na definição da tarefa. Se você criar um serviço com uma contagem de tarefas desejada igual a zero, o Amazon ECS não poderá estabelecer resumos do contêiner até que você acione outra implantação do serviço com uma contagem de tarefas desejada maior que zero. Para estabelecer resumos de imagens atualizados, é possível forçar uma nova implantação. Os resumos atualizados serão usados para iniciar novas tarefas e não afetará as tarefas já em execução. Para obter mais informações sobre forçar novas implantações, consulte [forceNewDeployment](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-forceNewDeployment) na *referência da API do Amazon ECS*. Ao usar provedores de capacidade do EC2, se não houver capacidade suficiente para iniciar uma tarefa durante a implantação inicial, a consistência da versão do software poderá falhar. Para garantir que a consistência da versão seja mantida mesmo quando a capacidade é limitada, defina explicitamente `versionConsistency: "enabled"` na configuração do contêiner da definição de tarefas em vez de confiar no comportamento padrão. Isso faz com que o Amazon ECS espere até que a capacidade esteja disponível antes de continuar com a implantação. # Práticas recomendadas para parâmetros de serviço do Amazon ECS Para garantir que não haja tempo de inatividade da aplicação, o processo de implantação é o seguinte: 1. Inicie os novos contêineres de aplicações enquanto mantém os contêineres existentes em execução. 1. Verifique se os novos contêineres estão íntegros. 1. Interrompa os contêineres antigos. Dependendo da configuração de implantação e da quantidade de espaço livre e não reservado no cluster, podem ser necessárias várias rodadas para concluir a substituição de todas as tarefas antigas por novas. Há duas opções de configuração do serviço que podem ser usadas para modificar o número: + `minimumHealthyPercent`: 100% (padrão) O limite inferior do número de tarefas do serviço que devem permanecer no estado `RUNNING` durante uma implantação. Essa é uma porcentagem da `desiredCount` arredondada para o número inteiro superior mais próximo. Esse parâmetro permite implantar sem usar a capacidade adicional de cluster. + `maximumPercent`: 200% (padrão) O limite superior do número de tarefas do serviço que são permitidas no estado `RUNNING` ou `PENDING` durante uma implantação. Essa é uma porcentagem da `desiredCount` arredondada para o número inteiro inferior mais próximo. **Exemplo: opções de configuração padrão** Considere o serviço a seguir, que tem seis tarefas, implantadas em um cluster com espaço para oito tarefas no total. As opções de configuração padrão do serviço não permitem que a implantação fique abaixo de 100% das seis tarefas desejadas. O processo de implantação é o seguinte: 1. O objetivo é substituir as seis tarefas. 1. O programador inicia duas novas tarefas porque as configurações padrão exigem que haja seis tarefas em execução. Agora há seis tarefas existentes e duas tarefas novas. 1. O programador interrompe duas das tarefas existentes. Agora há quatro tarefas existentes e duas novas. 1. O programador inicia duas tarefas novas adicionais. Agora há quatro tarefas existentes e quatro tarefas novas. 1. O programador encerra duas das tarefas existentes. Agora há duas tarefas existentes e quatro novas. 1. O programador inicia duas tarefas novas adicionais. Agora há duas tarefas existentes e seis tarefas novas. 1. O programador encerra as duas tarefas existentes restantes. Agora há seis tarefas novas. No exemplo acima, ao usar os valores padrão das opções, há uma espera de 2,5 minutos para cada nova tarefa iniciada. Além disso, o balanceador de carga pode ter que esperar cinco minutos para que a tarefa antiga seja encerrada. **Exemplo: Modificar `minimumHealthyPercent`** Você pode acelerar a implantação definindo o valor do `minimumHealthyPercent` como 50%. Considere o serviço a seguir, que tem seis tarefas, implantadas em um cluster com espaço para oito tarefas no total. O processo de implantação é o seguinte: 1. O objetivo é substituir seis tarefas. 1. O programador interrompe três das tarefas existentes. Ainda há três tarefas existentes em execução que atendem ao valor de `minimumHealthyPercent`. 1. O programador inicia cinco tarefas novas. Há três tarefas existentes e cinco tarefas novas. 1. O programador interrompe as três tarefas existentes restantes. Há cinco novas tarefas 1. O programador inicia as tarefas novas finais. Há seis tarefas novas. **Exemplo: modificar o espaço livre do cluster** Você também pode adicionar mais espaço livre para executar tarefas adicionais. Considere o serviço a seguir, que tem seis tarefas, implantadas em um cluster com espaço para dez tarefas no total. O processo de implantação é o seguinte: 1. O objetivo é substituir as tarefas existentes. 1. O programador interrompe três das tarefas existentes. Há três tarefas existentes. 1. O programador inicia seis tarefas novas. Há três tarefas existentes e seis tarefas novas. 1. O programador interrompe as três tarefas existentes. Há seis tarefas novas. **Recomendações** Use os valores a seguir nas opções de configuração do serviço quando as tarefas estiverem ociosas por algum tempo e não tiverem uma alta taxa de utilização. + `minimumHealthyPercent`: 50% + `maximumPercent`: 200% # Criação de uma implantação de atualização contínua do Amazon ECS Crie um serviço para executar e manter simultaneamente um número especificado de instâncias de uma definição de tarefa em um cluster. Se uma das suas tarefas falhar ou for interrompida, o programador de serviços do Amazon ECS executará outra instância da sua definição de tarefa para substituí-la. Isso ajuda a manter o número desejado de tarefas no serviço. Escolha os seguintes parâmetros de configuração antes de criar um serviço: + Há duas opções de computação que distribuem as tarefas. + Uma **estratégia de provedor de capacidade** faz com que o Amazon ECS distribua as tarefas em um ou entre vários provedores de capacidade. Para executar suas workloads nas instâncias gerenciadas do Amazon ECS, use a opção de estratégia do provedor de capacidade. + Um **tipo de execução** faz com que o Amazon ECS inicie as tarefas diretamente no Fargate ou nas instâncias do EC2 registradas nos seus clusters. Para executar suas workloads nas instâncias gerenciadas do Amazon ECS, use a opção de estratégia do provedor de capacidade. + Definições de tarefa que usam o modo de rede `awsvpc` ou serviços configurados para usar um balanceador de carga devem ter uma configuração de rede. Por padrão, o console seleciona a Amazon VPC padrão juntamente com todas as sub-redes e o grupo de segurança padrão na Amazon VPC padrão. + A estratégia padrão de posicionamento de tarefas distribui as tarefas uniformemente nas zonas de disponibilidade. Recomendamos usar o rebalanceamento de zonas de disponibilidade para ajudar a garantir a alta disponibilidade do seu serviço. Para obter mais informações, consulte [Balancear um serviço do Amazon ECS entre zonas de disponibilidade](service-rebalancing.md). + Quando você usa o **Launch Type** (Tipo de inicialização) para a implantação do serviço, por padrão, o serviço começa nas sub-redes da VPC do cluster. + Para **capacity provider strategy** (estratégia de provedor de capacidade), por padrão, o console seleciona uma opção de computação. Veja, a seguir, a descrição da ordem que o console usa para selecionar um padrão: + Se o cluster tiver uma estratégia padrão de provedor de capacidade definida, ela será selecionada. + Se o cluster não tiver uma estratégia de provedor de capacidade padrão definida, mas você tiver os provedores de capacidade do Fargate adicionados ao cluster, será selecionada uma estratégia de provedor de capacidade personalizada que use o provedor de capacidade do `FARGATE`. + Se o cluster não tiver uma estratégia de provedor de capacidade padrão definida, mas você tiver um ou mais provedores de capacidade do grupo do Auto Scaling adicionados ao cluster, será selecionada a opção **Usar personalizada (Avançado)** e a estratégia precisará ser definida manualmente. + Se o cluster não tiver uma estratégia de provedor de capacidade padrão definida e nenhum provedor de capacidade for adicionado ao cluster, será selecionado o tipo de inicialização do Fargate. + As opções padrão de detecção de falhas de implantação são usar a opção **Disjuntor de implantação do Amazon ECS** com a opção **Reverter em caso de falhas**. Para obter mais informações, consulte [Como o disjuntor de implantação do Amazon ECS realiza a detecção de falhas](deployment-circuit-breaker.md). + Decida se você deseja que o Amazon ECS aumente ou diminua automaticamente o número de tarefas desejadas no serviço. Para mais informações, consulte ., [Como escalar automaticamente o serviço do Amazon ECS](service-auto-scaling.md). + Se você precisar que uma aplicação se conecte a outras aplicações executadas no Amazon ECS, determine a opção mais adequada à sua arquitetura. Para obter mais informações, consulte [Interconexão de serviços do Amazon ECS](interconnecting-services.md). + Quando você cria um serviço que usa o disjuntor do Amazon ECS, o Amazon ECS cria uma implantação e uma revisão do serviço. Esses recursos permitem que você visualize informações detalhadas sobre o histórico de serviços. Para obter mais informações, consulte [Visualize o histórico de serviços usando implantações de serviços do Amazon ECS](service-deployment.md). Para obter informações sobre como criar um serviço usando a AWS CLI, consulte [https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) na *Referência da AWS Command Line Interface*. Para obter informações sobre como criar um serviço usando o AWS CloudFormation, consulte [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html) no *Guia do usuário do AWS CloudFormation*. ## Criar um serviço com as opções padrão É possível usar o console para criar e implantar um serviço rapidamente. O serviço conta com a seguinte configuração: + É implantado na VPC e nas sub-redes associadas ao cluster + Implanta uma tarefa + Usa a implantação contínua + Usa a estratégia de provedor de capacidade com o provedor de capacidade padrão + Usa o disjuntor de implantação para detectar falhas e define a opção de reverter automaticamente a implantação em caso de falha Para implantar um serviço usando os parâmetros padrão, siga estas etapas. **Para criar um serviço (console do Amazon ECS)** 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página de navegação, escolha **Clusters**. 1. Na página **Clusters**, selecione o cluster no qual o serviço será criado. 1. Na guia **Services** (Serviços), escolha **Create** (Criar). A página **Criar pilha** é exibida. 1. Em **Detalhes do serviço**, faça o seguinte: 1. Em **Definição de tarefa**, insira a família e a revisão das definições de tarefa a serem usadas. 1. Em **Service name** (Nome do serviço), insira um nome para o serviço. 1. Para usar o ECS Exec para depurar o serviço, em **Solucionar problemas de configuração**, selecione **Ativar o ECS Exec**. 1. Em **Configuração de implantação**, faça o seguinte: 1. Em **Desired tasks** (Tarefas desejadas), insira o número de tarefas que serão iniciadas e mantidas no serviço. 1. (Opcional) Para ajudar a identificar seu serviço e tarefas, expanda a seção **Tags** (Etiquetas) e configure suas etiquetas. Para que o Amazon ECS marque automaticamente todas as tarefas recém-iniciadas com o nome do cluster e as tags de definição de tarefa, selecione **Turn on Amazon ECS managed tags** (Ativar tags gerenciadas pelo Amazon ECS) e depois **Definições de tarefas**. Para que o Amazon ECS marque automaticamente todas as tarefas recém-iniciadas com o nome do cluster e as tags de serviços, selecione **Turn on Amazon ECS managed tags** (Ativar tags gerenciadas pelo Amazon ECS) e depois **Definições de tarefas**. Adicione ou remova uma tag. + [Adicionar uma etiqueta] Escolha **Add tag** (Adicionar etiqueta) e faça o seguinte: + Em **Chave**, insira o nome da chave. + Em **Valor** insira o valor da chave. + [Remover uma tag] Ao lado da tag, escolha **Remove tag (Remover tag)**. ## Criar um serviço usando parâmetros definidos Para criar um serviço usando os parâmetros definidos, siga estas etapas. **Para criar um serviço (console do Amazon ECS)** 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Determine o recurso no qual você inicia o serviço. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/create-service-console-v2.html) A página **Criar pilha** é exibida. 1. Em Detalhes do serviço, faça o seguinte: 1. Em **Definição de tarefa**, insira a definição de tarefa a ser usada. Em seguida, em **Revisão**, escolha a revisão a ser usada. 1. Em **Service name** (Nome do serviço), insira um nome para o serviço. 1. Em **Cluster existente**, escolha o cluster. Escolha **Criar cluster** para executar a tarefa em um novo cluster 1. Escolha como suas tarefas serão distribuídas em toda a infraestrutura do cluster. Expanda **Configuração de computação** e escolha sua opção. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. Para usar o ECS Exec para depurar o serviço, em **Solucionar problemas de configuração**, selecione **Ativar o ECS Exec**. 1. Em **Configuração de implantação**, faça o seguinte: 1. Em **Service type** (Tipo de serviço), escolha a estratégia de programação de serviços. + Para o programador implantar exatamente uma tarefa em cada instância de contêiner ativa que atende a todas as restrições de posicionamento de tarefas, escolha **Daemon**. + Para que o programador posicione e mantenha o número desejado de tarefas no cluster, escolha **Replica** (Réplica). 1. Caso escolha **Replica** (Réplica), em **Desired tasks** (Tarefas desejadas), especifique o número de tarefas que serão iniciadas e mantidas no serviço. 1. Se você escolheu **Replica**, para que o Amazon ECS monitore a distribuição de tarefas entre as zonas de disponibilidade e as redistribua quando houver um desequilíbrio, em **Rebalanceamento do serviço em zonas de disponibilidade**, selecione **Rebalanceamento do serviço em zonas de disponibilidade**. 1. Em **Período de carência de verificação de integridade**, insira quanto tempo (em segundos) após o início de uma tarefa o agendador do serviço ignorará as verificações de integridade que forem não íntegras para o Elastic Load Balancing, a VPC Lattice e o contêiner. Se você não especificar um valor de período de tolerância de verificação de integridade, o valor padrão 0 será usado. 1. Determine o tipo de implantação do seu serviço. Expanda **Opções de implantação** e especifique os parâmetros a seguir. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. Para configurar como o Amazon ECS detectará e lidará com falhas de implantação, expanda **Deployment failure detection**(Detecção de falhas de implantação) e escolha suas opções. 1. Para interromper uma implantação quando as tarefas não podem ser iniciadas, selecione **Use the Amazon ECS deployment circuit breaker)** (Usar o disjuntor de implantação do Amazon ECS. Para que o software reverta automaticamente a implantação para o último estado de implantação concluído quando o disjuntor de implantação definir a implantação para um estado de falha, selecione **Reverter em caso de falha**. 1. Para interromper uma implantação com base nas métricas da aplicação, selecione **Usar alarmes do CloudWatch**. Em seguida, em **Nomes de alarmes do CloudWatch**, escolha os alarmes. Para criar um alarme, acesse o console do CloudWatch. Para que o software reverta automaticamente a implantação para o último estado de implantação concluído quando um alarme do CloudWatch definir a implantação para um estado de falha, selecione **Reverter em caso de falha**. 1. Se a definição de tarefa usar o modo de rede `awsvpc`, você poderá especificar uma configuração de rede personalizada, expandir **Rede** e fazer o seguinte: 1. Em **VPC**, selecione a VPC a ser usada. 1. Em **Subnets** (Sub-redes), selecione uma ou mais sub-redes na VPC que o programador de tarefas levará em consideração ao posicionar as tarefas. 1. Em **Security group** (Grupo de segurança), você pode selecionar um grupo de segurança existente ou criar outro. Para usar um grupo de segurança existente, selecione o grupo de segurança e vá para a próxima etapa. Para criar um novo grupo de segurança, escolha **Create a new security group** (Criar um novo grupo de segurança). Você deve especificar o nome de um grupo de segurança, uma descrição e, em seguida, adicionar uma ou mais regras de entrada para o grupo de segurança. 1. Em **Public IP** (IP público), escolha se um endereço IP público deve ou não ser atribuído automaticamente à interface de rede elástica (ENI) da tarefa. Tarefas do AWS Fargate podem receber um endereço IP público quando são executadas em uma sub-rede pública para terem uma rota para a Internet. As tarefas do EC2 não podem ser atribuídas a um IP público usando esse campo. Para obter mais informações, consulte [Opções de rede de tarefas do Amazon ECS para o Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html) e [Alocar uma interface de rede para uma tarefa do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html). 1. (Opcional) Para interconectar o serviço usando o Service Connect, expanda **Service Connect** e especifique o seguinte: 1. Selecione **Ativar o Service Connect**. 1. Em **Service Connect configuration** (Configuração do Service Connect), especifique o modo cliente. + Se seu serviço executa uma aplicação cliente de rede que só precisa se conectar a outros serviços no namespace, escolha **Somente no lado do cliente**. + Se seu serviço executa uma aplicação de rede ou de serviço Web e precisa fornecer endpoints para esse serviço e se conectar a outros serviços no namespace, escolha **Client and server** (Cliente e servidor). 1. Para usar um namespace que não seja o namespace padrão do cluster, em **Namespace**, escolha o namespace do serviço. Isso pode ser um namespace criado separadamente na mesma Região da AWS em sua Conta da AWS ou um namespace na mesma região compartilhada com sua conta usando o AWS Resource Access Manager (AWS RAM). Para obter mais informações sobre namespaces compartilhados do AWS Cloud Map, consulte [Compartilhamento de namespaces do AWS Cloud Map entre contas](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) no *Guia do desenvolvedor do AWS Cloud Map*. 1. (Opcional) Especifique uma configuração de log. Selecione **Usar conjunto de logs**. A opção padrão envia os logs do contêiner ao CloudWatch Logs. As outras opções de driver de log são configuradas usando o AWS FireLens. Para obter mais informações, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md). Veja a seguir a descrição de cada destino de log de contêiner mais detalhadamente. + **Amazon CloudWatch**: configura a tarefa para enviar logs de contêiner ao CloudWatch Logs. São fornecidas as opções de driver de log padrão, que criam um grupo de logs do CloudWatch em seu nome. Para especificar um nome de grupo de logs diferente, altere os valores da opção de driver. + **Amazon Data Firehose**: configura a tarefa para enviar logs de contêiner ao Firehose. São fornecidas as opções de driver de log padrão, que enviam logs para um fluxo de entrega do Firehose. Para especificar um nome de fluxo de entrega diferente, altere os valores da opção de driver. + **Amazon Kinesis Data Streams**: configura a tarefa para enviar logs de contêiner ao Kinesis Data Streams. São fornecidas as opções de driver de log padrão, que enviam logs a um fluxo do Kinesis Data Streams. Para especificar um nome de transmissão diferente, altere os valores da opção de driver. + **Amazon OpenSearch Service**: configura a tarefa para enviar logs de contêiner a um domínio do OpenSearch Service. As opções de driver de log devem ser fornecidas. + **Amazon S3**: configura a tarefa para enviar logs de contêiner a um bucket do Amazon S3. As opções de driver de log padrão são fornecidas, mas você deve especificar um nome de bucket válido do Amazon S3. 1. (Opcional) Para habilitar logs de acesso, siga estas etapas: 1. Expanda **Configuração do log de acesso**. Em **Formato**, escolha **JSON** ou `TEXT`. 1. Para incluir parâmetros de consulta nos logs de acesso, selecione **Incluir parâmetros de consulta**. 1. (Opcional) Para interconectar o serviço usando a descoberta de serviços, expanda **Descoberta de serviços** e faça o seguinte: 1. Selecione **Usar descoberta de serviços**. 1. Para usar um novo namespace, escolha **Criar um namespace** em **Configurar namespace** e forneça um nome e uma descrição para o namespace. Para usar um namespace existente, escolha **Selecionar um namespace existente** e escolha o namespace desejado. 1. Forneça as informações de serviço da descoberta de serviços, como nome e descrição do serviço. 1. Para que o Amazon ECS realize verificações de integridade periódicas em nível de contêiner, selecione **Habilitar propagação de integridade de tarefas do Amazon ECS**. 1. Em **DNS record type** (Tipo de registro DNS), selecione o tipo de registro DNS a ser criado para o serviço. A descoberta de serviços do Amazon ECS só é compatível com registros **A** e **SRV**, dependendo do modo de rede que a definição de tarefa especifica. Para obter informações sobre esses tipos de registro, consulte [Tipos de registro DNS compatíveis](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html) no *Guia do desenvolvedor do Amazon Route 53*. + Se a definição de tarefa que a sua tarefa de serviço especifica usar o modo de rede `bridge` ou `host`, somente haverá suporte para os registros do tipo **SRV**. Escolha o nome do contêiner e a combinação de portas a serem associadas ao registro. + Se a definição de tarefa que a sua tarefa de serviço especifica usar o modo de rede `awsvpc`, selecione o tipo de registro **A** ou **SRV**. Caso escolha **A**, vá para a próxima etapa. Se você escolher **SRV**, especifique a porta na qual o serviço pode ser encontrado ou o nome do contêiner e a combinação de portas a serem associadas ao registro. Em **TTL**, insira a duração, em segundos, do tempo em que um conjunto de registros é armazenado em cache pelos resolvedores de DNS e pelos navegadores da Web. 1. (Opcional) Para interconectar o serviço usando o VPC Lattice, expanda **VPC Lattice** e faça o seguinte: 1. Selecione **Ativar o VPC Lattice** 1. Em **Função de infraestrutura**, escolha o perfil de infraestrutura. Se você não criou um perfil, escolha **Criar perfil de infraestrutura**. 1. Em **Grupos de destino**, escolha um ou mais grupos de destino. Escolha pelo menos um grupo de destino e, no máximo, cinco. Escolha **Adicionar grupo de destino** para adicionar mais grupos de destino. Escolha o **Nome da porta**, o **Protocolo** e a **Porta** para cada grupo de destino escolhido. Para excluir um grupo de destino, escolha **Remover**. **nota** Se desejar adicionar grupos de destino existentes, será necessário usar a AWS CLI. Para obter instruções sobre como adicionar grupos de destino usando o AWS CLI, consulte [register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html) na *Referência do AWS Command Line Interface*. Embora um serviço do VPC Lattice possa ter vários grupos de destino, cada grupo de destino só pode ser adicionado a um serviço. 1. Para concluir a configuração do VPC Lattice, inclua seus novos grupos de destino na ação padrão do receptor ou nas regras de um serviço existente do VPC Lattice no console do VPC Lattice. Para obter mais informações, consulte [Regras de receptor para o serviço do VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html). 1. (Opcional) Para configurar um balanceador de carga para o serviço, expanda **Load balancing** (Balanceamento de carga). Selecione o balanceador de carga. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. (Opcional) Para configurar o ajuste de escala automático do serviço, expanda **Ajuste de escala automático do serviço** e especifique os parâmetros a seguir. Para usar o ajuste de escala automático preditivo, que utiliza os dados de carga anteriores dos fluxos de tráfego, configure-o depois de criar o serviço. Para obter mais informações, consulte [Usar padrões históricos para escalar os serviços do Amazon ECS com escalabilidade preditiva](predictive-auto-scaling.md). 1. Para usar a escalabilidade automática do serviço, selecione **Service auto scaling** (Escalabilidade automática do serviço). 1. Em **Número mínimo de tarefas**, insira o limite inferior do número de tarefas a serem usadas pelo ajuste de escala automático. A contagem desejada não será inferior a essa contagem. 1. Em **Número máximo de tarefas**, insira o limite superior do número de tarefas a serem usadas pelo ajuste de escala automático. A contagem desejada não ultrapassará essa contagem. 1. Escolha o tipo de política. Em **Tipo de política de ajuste de escala**, escolha uma das opções a seguir. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. (Opcional) Para usar uma estratégia de posicionamento de tarefas diferente da padrão, expanda **Task Placement** (Posicionamento de tarefas) e escolha uma das opções a seguir. Para obter mais informações, consulte [Como o Amazon ECS posiciona tarefas em instâncias de contêineres](task-placement.md). + **Distribuição balanceada de AZ**: distribua tarefas por zonas de disponibilidade e entre instâncias de contêiner na zona de disponibilidade. + **BinPack balanceado de AZ**: distribua tarefas por zonas de disponibilidade e entre instâncias de contêiner com a menor memória disponível. + **BinPack**: distribua tarefas com base na menor quantidade disponível de CPU ou memória. + **Uma tarefa por host**: posicione, no máximo, uma tarefa do serviço em cada instância de contêiner. + **Personalizado**: defina sua própria estratégia de posicionamento de tarefas. Se você escolheu **Custom** (Personalizado), defina o algoritmo de modo a posicionar as tarefas e as regras que serão consideradas durante o posicionamento de tarefas. + Em **Strategy** (Estratégia), em **Type** (Tipo) e **Field** (Campo), escolha o algoritmo e a entidade a serem usados com o algoritmo. É possível adicionar no máximo cinco estratégias. + Em **Restrição**, para **Tipo** e **Expressão**, escolha a regra e o atributo para a restrição. Por exemplo, para definir a restrição de modo a posicionar tarefas em instâncias T2, em **Expression** (Expressão), insira **attribute:ecs.instance-type =\$1 t2.\$1**. É possível adicionar no máximo dez restrições. 1. Caso a tarefa use um volume de dados compatível com a configuração na implantação, você pode configurar o volume expandindo **Volume**. O nome e o tipo do volume são configurados ao criar uma revisão de definição de tarefa e não podem ser alterados ao criar um serviço. Para atualizar o nome e o tipo do volume, você deve criar uma revisão de definição de tarefa e criar um serviço usando a nova revisão. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. Para usar o ECS Exec para depurar o serviço, em **Solucionar problemas de configuração**, selecione **Ativar o ECS Exec**. 1. (Opcional) Para ajudar a identificar seu serviço e tarefas, expanda a seção **Tags** (Etiquetas) e configure suas etiquetas. Para que o Amazon ECS atribua tags automaticamente a todas as tarefas recém-iniciadas com o nome do cluster e as tags de definição de tarefa, selecione **Ativar tags gerenciadas pelo Amazon ECS** e, para **Propagar tags de**, escolha **Definições de tarefas**. Para que o Amazon ECS atribua tags automaticamente a todas as tarefas recém-iniciadas com o nome do cluster e as tags de serviços, selecione **Ativar tags gerenciadas pelo Amazon ECS** e, para **Propagar tags de**, escolha **Serviço**. Adicione ou remova uma tag. + [Adicionar uma etiqueta] Escolha **Add tag** (Adicionar etiqueta) e faça o seguinte: + Em **Chave**, insira o nome da chave. + Em **Valor** insira o valor da chave. + [Remover uma tag] Ao lado da tag, escolha **Remove tag (Remover tag)**. 1. Selecione **Create** (Criar). ## Próximas etapas A seguir, estão as ações adicionais após criar um serviço. + Configure o ajuste de escala automático preditivo, que utiliza os dados de carga anteriores dos fluxos de tráfego. Para obter mais informações, consulte [Usar padrões históricos para escalar os serviços do Amazon ECS com escalabilidade preditiva](predictive-auto-scaling.md). + Acompanhe sua implantação e visualize seu histórico de serviços para os disjuntores do Amazon ECS. Para obter mais informações, consulte [Visualize o histórico de serviços usando implantações de serviços do Amazon ECS](service-deployment.md). # Implantações azuis/verdes do Amazon ECS Uma implantação azul/verde é uma metodologia de liberação que reduz o tempo de inatividade e o risco ao executar dois ambientes de produção idênticos chamados azul e verde. Com as implantações azul/verde do Amazon ECS, você pode validar novas revisões de serviços antes de direcionar o tráfego de produção para elas. Essa abordagem fornece uma maneira mais segura de implantar alterações com a capacidade de revertê-las rapidamente, se necessário. ## Benefícios O uso de implantações azul/verde oferece os seguintes benefícios: + Reduz o risco por meio de testes com o tráfego de produção antes de mudar para a produção. Você pode validar a nova implantação com tráfego de teste antes de direcionar o tráfego de produção para ela. + Implementações sem tempo de inatividade. O ambiente de produção permanece disponível durante todo o processo de implantação, garantindo a disponibilidade contínua do serviço. + Fácil reversão se forem detectados problemas. Se surgirem problemas com a implantação verde, você poderá reverter rapidamente para a implantação azul sem interrupção prolongada do serviço. + Ambiente de teste controlado. O ambiente verde fornece um espaço isolado para testar novos recursos com padrões reais de tráfego antes da implantação completa. + Processo de implantação previsível. A abordagem estruturada com estágios de ciclo de vida definidos torna as implantações mais consistentes e confiáveis. + Validação automatizada por meio de ganchos do ciclo de vida. Você pode implementar testes automatizados em vários estágios da implantação para verificar a funcionalidade. ## Terminologia Confira abaixo os termos de implantação azul/verde do Amazon ECS: + Tempo de incorporação: a duração em que as revisões de serviço azul e verde são executadas simultaneamente após a mudança do tráfego de produção. + Implantação azul: a revisão atual do serviço de produção que você deseja substituir. + Implantação verde: a nova revisão do serviço que você deseja implantar. + Estágios do ciclo de vida: uma série de eventos na operação de implantação, como “após a mudança no tráfego de produção”. + Gancho do ciclo de vida: uma função do Lambda que verifica a implantação em um estágio específico do ciclo de vida. + Receptor: um recurso do Elastic Load Balancing que verifica solicitações de conexão usando o protocolo e a porta que você configurou. As regras que você define para um receptor determinam como o Amazon ECS roteia solicitações para seus destinos registrados. + Regra: um recurso do Elastic Load Balancing associado a um receptor. Uma regra define como as solicitações são roteadas e consiste em uma ação, condição e prioridade. + Grupo de destino: um recurso do Elastic Load Balancing usado para rotear solicitações para um ou mais destinos registrados (por exemplo, instâncias do EC2). Ao criar um listener, especifique um grupo de destino para a ação padrão dele. O tráfego é encaminhado para o grupo de destino especificado na regra do listener. + Mudança de tráfego: o processo que o Amazon ECS usa para transferir o tráfego da implantação azul para a implantação verde. Para implantações azul/verde do Amazon ECS, todo o tráfego é transferido do serviço azul para o serviço verde de uma só vez. ## Considerações Considere o seguinte ao escolher um tipo de implantação: + Uso de recursos: as implantações azul/verde executam temporariamente as revisões do serviço azul e verde simultaneamente, o que pode dobrar o uso de recursos durante as implantações. + Monitoramento da implantação: as implantações azul/verde fornecem informações mais detalhadas sobre o status da implantação, permitindo que você monitore cada estágio do processo de implantação. + Reversão: as implantações azul/verde facilitam a reversão para a versão anterior se forem detectados problemas, pois a revisão azul é mantida em execução até que o tempo de incorporação expire. + Hooks do ciclo de vida do Network Load Balancer: se você usar um Network Load Balancer para implantações azul/verde, há um ganho de tempo adicional de 10 minutos para os estágios do ciclo de vida TEST\$1TRAFFIC\$1SHIFT e PRODUCTION\$1TRAFFIC\$1SHIFT. Isso ocorre porque o Amazon ECS garante que seja seguro mudar o tráfego. # Fluxo de trabalho de implantações de serviços azul/verde do Amazon ECS O processo de implantação azul/verde do Amazon ECS segue uma abordagem estruturada com seis fases distintas que garantem atualizações de aplicações seguras e confiáveis. Cada fase tem um propósito específico na validação e transição da aplicação da versão atual (azul) para a nova versão (verde). 1. **Fase de preparação**: crie o ambiente verde junto com o ambiente azul existente. Isso inclui o provisionamento de novas revisões de serviços e a preparação de grupos de destino. 1. **Fase de implantação**: implante a nova revisão do serviço no ambiente verde. O Amazon ECS lança novas tarefas usando a revisão atualizada do serviço, enquanto o ambiente azul continua atendendo ao tráfego de produção. 1. **Fase de teste**: valide o ambiente verde usando o roteamento de tráfego de teste. O Application Load Balancer direciona as solicitações de teste para o ambiente verde, enquanto o tráfego de produção permanece no azul. 1. **Fase de mudança de tráfego**: mude o tráfego de produção do azul para o verde com base na sua estratégia de implantação configurada. Essa fase inclui pontos de verificação de monitoramento e validação. 1. **Fase de monitoramento**: monitore a integridade da aplicação, as métricas de performance e os estados dos alarmes durante o tempo de incorporação. Uma operação de reversão é iniciada quando problemas são detectados. 1. **Fase de conclusão**: finalize a implantação encerrando o ambiente azul ou mantendo-o para possíveis cenários de reversão, dependendo da sua configuração. ## Fluxo de trabalho O diagrama a seguir ilustra o fluxo de trabalho abrangente de implantação azul/verde, mostrando a interação entre o Amazon ECS e o Application Load Balancer: ![\[Diagrama abrangente mostrando o processo de implantação azul/verde no Amazon ECS com interações detalhadas de componentes, fases de mudança de tráfego e pontos de verificação de monitoramento\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/images/blue-green.png) Esse fluxo de trabalho de implantação aprimorado inclui as seguintes etapas detalhadas: 1. **Estado inicial**: o serviço azul (produção atual) gerencia 100% do tráfego de produção. O Application Load Balancer tem um único receptor com regras que direcionam todas as solicitações para o grupo de destino azul contendo tarefas azuis íntegras. 1. **Provisionamento de ambiente verde**: o Amazon ECS cria novas tarefas usando a definição atualizada de tarefas. Essas tarefas são registradas em um novo grupo de destino verde, mas inicialmente não recebem tráfego. 1. **Validação da verificação de integridade**: o Application Load Balancer realiza verificações de integridade em tarefas verdes. Somente quando as tarefas verdes passam pelas verificações de integridade, a implantação vai para a próxima fase. 1. **Roteamento de tráfego de teste**: se configurado, as regras de receptor do Application Load Balancer direcionam padrões de tráfego específicos (como solicitações com cabeçalhos de teste) para o ambiente verde para validação, enquanto o tráfego de produção permanece no azul. Isso é controlado pelo mesmo receptor que manipula o tráfego de produção, usando regras diferentes com base nos atributos da solicitação. 1. **Mudança de tráfego de produção**: com base na configuração de implantação, o tráfego muda de azul para verde. Nas implantações azul/verde do ECS, esta é uma mudança imediata (tudo de uma vez), em que 100% do tráfego é movido do ambiente azul para o verde. O Application Load Balancer usa um único receptor com regras de receptor que controlam a distribuição do tráfego entre os grupos de destino azul e verde com base nos pesos. 1. **Monitoramento e validação**: durante toda a mudança de tráfego, o Amazon ECS monitora as métricas, os estados dos alarmes e a integridade da implantação do CloudWatch. Os gatilhos de reversão automática serão ativados se forem detectados problemas. 1. **Período de tempo de incorporação**: a duração em que as revisões de serviço azul e verde são executadas simultaneamente após a mudança do tráfego de produção. 1. **Encerramento do ambiente azul**: após a mudança e a validação bem-sucedidas do tráfego, o ambiente azul é encerrado para liberar recursos do cluster, ou é mantido para capacidade de reversão rápida. 1. **Estado final**: o ambiente verde torna-se o novo ambiente de produção, lidando com 100% do tráfego. A implantação está marcada como bem-sucedida. ## Estágios do ciclo de vida de implantação O processo de implantação azul/verde avança em estágios distintos do ciclo de vida (uma série de eventos na operação de implantação, como “após a mudança do tráfego de produção”), cada um com responsabilidades específicas e pontos de verificação de validação. A compreensão desses estágios ajuda você a monitorar o andamento da implantação e solucionar problemas de forma eficaz. Cada estágio do ciclo de vida pode durar até 24 horas. Recomendamos que o valor permaneça abaixo da marca de 24 horas. Isso ocorre porque os processos assíncronos precisam de tempo para acionar os ganchos. O sistema atinge o tempo limite, falha na implantação e, em seguida, inicia uma reversão após um estágio atingir 24 horas. As implantações do CloudFormation têm restrições adicionais de tempo limite. Embora o limite de estágio de 24 horas permaneça em vigor, o CloudFormation impõe um limite de 36 horas em toda a implantação. A implantação do CloudFormation falha e, em seguida, iniciará uma reversão se o processo não for concluído em até 36 horas. | Estágios do ciclo de vida | Descrição | Use este estágio para o gancho do ciclo de vida? | | --- | --- | --- | | RECONCILE\$1SERVICE | Este estágio só acontece quando você inicia uma nova implantação de serviço com mais de uma revisão de serviço em um estado ACTIVE. | Sim | | PRE\$1SCALE\$1UP | A revisão do serviço verde ainda não foi iniciada. A revisão do serviço azul está processando 100% do tráfego de produção. Não há tráfego de teste. | Sim | | SCALE\$1UP | O momento em que a revisão do serviço verde aumenta a escala verticalmente até 100% e inicia novas tarefas. A revisão do serviço verde não está recebendo nenhum tráfego neste momento. | Não | | POST\$1SCALE\$1UP | A revisão do serviço verde foi iniciada. A revisão do serviço azul está processando 100% do tráfego de produção. Não há tráfego de teste. | Sim | | TEST\$1TRAFFIC\$1SHIFT | As revisões do serviço azul e verde estão em execução. A revisão do serviço azul processa 100% do tráfego de produção. A revisão do serviço verde está migrando de 0% para 100% do tráfego de teste. | Sim | | POST\$1TEST\$1TRAFFIC\$1SHIFT | A mudança de tráfego de teste foi concluída. A revisão do serviço verde processa 100% do tráfego de teste. | Sim | | PRODUCTION\$1TRAFFIC\$1SHIFT | O tráfego de produção está mudando para a revisão do serviço verde. A revisão do serviço verde está migrando de 0% para 100% do tráfego de produção. | Sim | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | A mudança do tráfego de produção está concluída. | Sim | | BAKE\$1TIME | A duração em que as revisões de serviço azul e verde são executadas simultaneamente. | Não | | CLEAN\$1UP | A revisão do serviço azul teve a escala reduzida verticalmente por completo para 0 tarefa em execução. A revisão do serviço verde agora é a revisão do serviço de produção após esse estágio. | Não | Cada estágio do ciclo de vida inclui pontos de verificação de validação integrados que devem ser aprovados antes de prosseguir para a próxima etapa. Se alguma validação falhar, a implantação poderá ser revertida automaticamente para manter a disponibilidade e a confiabilidade do serviço. Quando você usa uma função do Lambda, a função deve concluir o trabalho ou retornar IN\$1PROGRESS em 15 minutos. Você pode usar o `callBackDelaySeconds` para atrasar a chamada para o Lambda. Para obter mais informações, consulte a [Função app.py](https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns/blob/main/ecs-bluegreen-lifecycle-hooks/src/approvalFunction/app.py#L20-L25) em sample-amazon-ecs-blue-green-deployment-patterns no GitHub. # Recursos necessários para implantações azul/verde do Amazon ECS Para usar uma implantação azul/verde com mudança de tráfego gerenciada, seu serviço deve usar um dos seguintes recursos: + Elastic Load Balancing + Service Connect Os serviços que não usam a Descoberta de serviços, o Service Connect, o VPC Lattice ou o Elastic Load Balancing também podem usar implantações azul/verde, mas não obtêm nenhum dos benefícios de transferência de tráfego gerenciado. A lista abaixo fornece uma visão geral de alto nível do que você precisa configurar para implantações azul/verde do Amazon ECS: + Seu serviço usa o Application Load Balancer, o Network Load Balancer ou o Service Connect. Configure os recursos apropriados. + Application Load Balancer: para obter mais informações, consulte [Recursos do Application Load Balancer para implantações azul/verde, linear e canário](alb-resources-for-blue-green.md). + Network Load Balancer: para obter mais informações, consulte [Recursos do Network Load Balancer para implantações azul/verde, lineares e canário do Amazon ECS](nlb-resources-for-blue-green.md). + Service Connect: para obter mais informações, consulte [Recursos do Service Connect para implantações azul/verde, linear e canário do Amazon ECS](service-connect-blue-green.md). + Defina o controlador de implantação do serviço para `ECS`. + Configure a estratégia de implantação como `blue/green` na sua definição de serviço. + Opcionalmente, configure parâmetros adicionais, como: + Tempo de incorporação para a nova implantação + Alarmes do CloudWatch para reversão automática + Ganchos do ciclo de vida de implantação para testes (são funções do Lambda que são executadas em estágios de implantação especificados) ## Práticas recomendadas Siga estas práticas recomendadas para implantações azul/verde do Amazon ECS: + Configure as verificações de integridade apropriadas que reflitam com precisão a integridade da sua aplicação. + Defina um tempo de incorporação que permita testes suficientes da implantação verde. + Implemente alarmes do CloudWatch para detectar problemas automaticamente e acionar reversões. + Use ganchos do ciclo de vida para realizar testes automatizados em cada estágio da implantação. + Garanta que sua aplicação possa processar revisões de serviços azul e verde em execução simultânea. + Planeje uma capacidade de cluster suficiente para processar ambas as revisões de serviços durante a implantação. + Teste seus procedimentos de reversão antes de implementá-los na produção. # Recursos do Application Load Balancer para implantações azul/verde, linear e canário Para usar Application Load Balancers com implantações azul/verde do Amazon ECS, você precisa configurar recursos específicos que permitam o roteamento de tráfego entre as revisões de serviço azul e verde. ## Grupos de destino Para implantações azul/verde com o Elastic Load Balancing, você precisa criar dois grupos de destino: + Um grupo de destino principal para a revisão do serviço azul (tráfego de produção atual) + Um grupo de destino alternativo para a revisão do serviço verde (nova versão) Ambos os grupos de destino devem ser configurados com as seguintes configurações: + Tipo de destino: `IP` (para Fargate ou EC2 com modo de rede `awsvpc`) + Protocolo: `HTTP` (ou o protocolo que sua aplicação usa) + Porta: a porta que sua aplicação escuta (normalmente `80` para HTTP) + VPC: a mesma VPC das suas tarefas do Amazon ECS + Configurações de verificação de integridade: configuradas para verificar adequadamente a integridade da sua aplicação Durante uma implantação azul/verde, o Amazon ECS registra automaticamente as tarefas com o grupo de destino apropriado com base no estágio de implantação. **Example Criar grupos de destino para um Application Load Balancer** Os seguintes comandos da CLI criam dois grupos de destino para uso com um Application Load Balancer em uma implantação azul/verde: ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 aws elbv2 create-target-group \ --name green-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 ``` ## Application Load Balancer É necessário criar um Application Load Balancer com a seguinte configuração: + Esquema: voltado para a internet ou interno, dependendo de suas necessidades + Tipo de endereço IP: IPv4 + VPC: a mesma VPC das suas tarefas do Amazon ECS + Sub-redes: pelo menos duas sub-redes em diferentes zonas de disponibilidade + Grupos de segurança: um grupo de segurança que permite tráfego nas portas do receptor O grupo de segurança anexado ao Application Load Balancer deve ter uma regra de saída que permita o tráfego para o grupo de segurança anexado às suas tarefas do Amazon ECS. **Example Criar um Application Load Balancer** O seguinte comando da CLI cria um Application Load Balancer para ser usado em uma implantação azul/verde: ``` aws elbv2 create-load-balancer \ --name my-application-load-balancer \ --type application \ --security-groups sg-abcd1234 \ --subnets subnet-12345678 subnet-87654321 ``` ## Receptores e regras Para implantações azul/verde, você precisa configurar receptores em seu Application Load Balancer: + Receptor de produção: processa o tráfego de produção (normalmente na porta 80 ou 443) + Inicialmente encaminha o tráfego para o grupo de destino principal (revisão de serviço azul) + Após a implantação, encaminha o tráfego para o grupo de destino alternativo (revisão de serviço verde) + Receptor de teste (opcional): processa o tráfego de teste para validar a revisão do serviço verde antes de mudar o tráfego de produção + Pode ser configurado em outra porta (por exemplo, 8080 ou 8443) + Encaminha o tráfego para o grupo de destino alternativo (revisão de serviço verde) durante o teste Durante uma implantação azul/verde, o Amazon ECS atualiza automaticamente as regras do receptor para direcionar o tráfego para o grupo de destino apropriado com base no estágio da implantação. **Example Criação de um receptor de produção** O seguinte comando da CLI cria um receptor de produção na porta 80 que encaminha o tráfego para o grupo de destino primário (azul): ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 80 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/abcdef123456 ``` **Example Criação de um receptor de teste** O seguinte comando da CLI cria um receptor de teste na porta 8080 que encaminha o tráfego para o grupo de destino alternativo (verde): ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 8080 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example Criação de uma regra de receptor para roteamento baseado em caminho** O seguinte comando da CLI cria uma regra que encaminha o tráfego de um caminho específico para o grupo de destino verde para teste: ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 10 \ --conditions Field=path-pattern,Values='/test/*' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example Criação de uma regra de receptor para roteamento baseado em cabeçalho** O seguinte comando da CLI cria uma regra que encaminha o tráfego com um cabeçalho específico para o grupo de destino verde para teste: ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 20 \ --conditions Field=http-header,HttpHeaderConfig='{Name=X-Environment,Values=[test]}' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` ## Configuração de serviço Você deve ter permissões para permitir que o Amazon ECS gerencie recursos do balanceador de carga nos clusters em seu nome. Para obter mais informações, consulte [Perfil do IAM da infraestrutura do Amazon ECS para balanceadores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Ao criar ou atualizar um serviço do Amazon ECS para implantações azul/verde com o Elastic Load Balancing, você precisa especificar a configuração a seguir. Substitua os valores das *user-input* pelos seus. Os principais componentes dessa configuração são: + `targetGroupArn`: o ARN do grupo de destino principal (revisão de serviço azul). + `alternateTargetGroupArn`: o ARN do grupo de destino alternativo (revisão de serviço verde). + `productionListenerRule`: o ARN da regra do receptor para tráfego de produção. + `roleArn`: o ARN do perfil que permite ao Amazon ECS gerenciar recursos do Elastic Load Balancing. + `strategy`: defina como `BLUE_GREEN` para habilitar implantações azul/verde. + `bakeTimeInMinutes`: a duração em que as revisões de serviço azul e verde são executadas simultaneamente após a mudança do tráfego de produção. + `TestListenerRule`: o ARN da regra do receptor para tráfego de teste. Esse parâmetro é opcional. ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/primary-target-group/abcdef123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/alternate-target-group/ghijkl789012", "productionListenerRule": "arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/load-balancer-name/abcdef123456/listener/ghijkl789012/rule/mnopqr345678", "roleArn": "arn:aws:iam::123456789012:role/ecs-elb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## Fluxo de tráfego durante a implantação Durante uma implantação azul/verde com o Elastic Load Balancing, o tráfego flui pelo sistema da seguinte forma: 1. *Estado inicial*: todo o tráfego de produção é roteado para o grupo de destino principal (revisão de serviço azul). 1. *Implantação de revisão de serviço verde*: o Amazon ECS implanta as novas tarefas e as registra no grupo de destino alternativo. 1. *Tráfego de teste*: se um receptor de teste estiver configurado, o tráfego de teste será roteado para o grupo de destino alternativo para validar a revisão do serviço verde. 1. *Mudança de tráfego de produção*: o Amazon ECS atualiza a regra de receptor de produção para rotear o tráfego para o grupo de destino alternativo (revisão de serviço verde). 1. *Tempo de incorporação*: a duração em que as revisões de serviço azul e verde são executadas simultaneamente após a mudança do tráfego de produção. 1. *Conclusão*: após uma implantação bem-sucedida, a revisão do serviço azul é encerrada. Se forem detectados problemas durante a implantação, o Amazon ECS pode reverter automaticamente roteando o tráfego de volta para o grupo de destino principal (revisão de serviço azul). # Recursos do Network Load Balancer para implantações azul/verde, lineares e canário do Amazon ECS Para usar um Network Load Balancer com implantações azul/verde do Amazon ECS, você precisa configurar recursos específicos que permitam o roteamento de tráfego entre as revisões de serviço azul e verde. Esta seção explica os componentes necessários e suas configurações. Quando sua configuração inclui um Network Load Balancer, o Amazon ECS adiciona um atraso de dez minutos aos seguintes estágios do ciclo de vida: + TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT Esse atraso é responsável por problemas de tempo do Network Load Balancer que podem causar uma incompatibilidade entre os pesos de tráfego configurados e o roteamento real do tráfego no plano de dados. ## Grupos de destino Para implantações azul/verde com um Network Load Balancer, você precisa criar dois grupos de destino: + Um grupo de destino principal para a revisão do serviço azul (tráfego de produção atual) + Um grupo de destino alternativo para a revisão do serviço verde (nova revisão do serviço) Ambos os grupos de destino devem ser configurados com as seguintes configurações: + Tipo de destino: `ip` (para Fargate ou EC2 com modo de rede `awsvpc`) + Protocolo: `TCP` (ou o protocolo que sua aplicação usa) + Porta: a porta que sua aplicação escuta (normalmente `80` para HTTP) + VPC: a mesma VPC das suas tarefas do Amazon ECS + Configurações de verificação de integridade: configuradas para verificar adequadamente a integridade da sua aplicação Para verificações de integridade do TCP, o Network Load Balancer estabelece uma conexão TCP com o destino. Se a conexão for bem-sucedida, o destino será considerado íntegro. Para verificações de integridade de HTTP/HTTPS, o Network Load Balancer envia uma solicitação HTTP/HTTPS ao destino e verifica a resposta. Durante uma implantação azul/verde, o Amazon ECS registra automaticamente as tarefas com o grupo de destino apropriado com base no estágio de implantação. **Example Criação de grupos de destino para o Network Load Balancer** Os seguintes comandos da AWS CLI criam dois grupos de destino para uso com um Network Load Balancer em uma implantação azul/verde: ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP aws elbv2 create-target-group \ --name green-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP ``` ## Network Load Balancer É necessário criar um Network Load Balancer com a seguinte configuração: + Esquema: voltado para a internet ou interno, dependendo de suas necessidades + Tipo de endereço IP: IPv4 + VPC: a mesma VPC das suas tarefas do Amazon ECS + Sub-redes: pelo menos duas sub-redes em diferentes zonas de disponibilidade Diferentemente dos Application Load Balancers, os Network Load Balancers operam na camada de transporte (camada 4) e não usam grupos de segurança. Em vez disso, você precisa garantir que os grupos de segurança associados às tarefas do Amazon ECS permitam o tráfego do Network Load Balancer nas portas do receptor. **Example Criar um Network Load Balancer** O seguinte comando da AWS CLI cria um Network Load Balancer para ser usado em uma implantação azul/verde: ``` aws elbv2 create-load-balancer \ --name my-network-load-balancer \ --type network \ --subnets subnet-12345678 subnet-87654321 ``` ## Considerações sobre o uso do NLB com implantações azul/verde Ao usar um Network Load Balancer para implantações azul/verde, considere o seguinte: + **Operação da camada 4**: os Network Load Balancers operam na camada de transporte (camada 4) e não inspecionam o conteúdo da camada da aplicação (camada 7). Isso significa que você não pode usar cabeçalhos ou caminhos HTTP para decisões de roteamento. + **Verificações de integridade**: as verificações de integridade do Network Load Balancer estão limitadas aos protocolos TCP, HTTP ou HTTPS. Para verificações de integridade do TCP, o Network Load Balancer apenas verifica se a conexão pode ser estabelecida. + **Preservação da conexão**: os Network Load Balancers preservam o endereço IP de origem do cliente, o que pode ser útil para fins de segurança e registro em log. + **Endereços IP estáticos**: os Network Load Balancers fornecem endereços IP estáticos para cada sub-rede, o que pode ser útil para listas de permissões ou quando os clientes precisam se conectar a um endereço IP fixo. + **Tráfego de teste**: como os Network Load Balancers não são compatíveis com o roteamento baseado em conteúdo, o tráfego de teste deve ser enviado para outra porta do tráfego de produção. ## Receptores e regras Para implantações azul/verde com um Network Load Balancer, você precisa configurar receptores: + Receptor de produção: processa o tráfego de produção (normalmente na porta 80 ou 443) + Inicialmente encaminha o tráfego para o grupo de destino principal (revisão de serviço azul) + Após a implantação, encaminha o tráfego para o grupo de destino alternativo (revisão de serviço verde) + Receptor de teste (opcional): processa o tráfego de teste para validar a revisão do serviço verde antes de mudar o tráfego de produção + Pode ser configurado em outra porta (por exemplo, 8080 ou 8443) + Encaminha o tráfego para o grupo de destino alternativo (revisão de serviço verde) durante o teste Diferentemente dos Application Load Balancers, os Network Load Balancers não são compatíveis com regras de roteamento baseadas em conteúdo. Em vez disso, o tráfego é roteado com base na porta e no protocolo do receptor. Os seguintes comandos da AWS CLI criam receptores de produção e teste para um Network Load Balancer: Substitua os valores das *user-input* pelos seus. ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 80 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456 aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 8080 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456 ``` ## Configuração de serviço Você deve ter permissões para permitir que o Amazon ECS gerencie recursos do balanceador de carga nos clusters em seu nome. Para obter mais informações, consulte [Perfil do IAM da infraestrutura do Amazon ECS para balanceadores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Ao criar ou atualizar um serviço do Amazon ECS para implantações azul/verde com um Network Load Balancer, você precisa especificar a seguinte configuração: Substitua os valores das *user-input* pelos seus. Os principais componentes dessa configuração são: + `targetGroupArn`: o ARN do grupo de destino principal (revisão de serviço azul) + `alternateTargetGroupArn`: o ARN do grupo de destino alternativo (revisão de serviço verde) + `productionListenerRule`: o ARN do receptor para tráfego de produção + `testListenerRule`: (opcional) o ARN do receptor para tráfego de teste + `roleArn`: o ARN do perfil que permite ao Amazon ECS gerenciar recursos do Network Load Balancer + `strategy`: defina como `BLUE_GREEN` para habilitar implantações em azul/verde + `bakeTimeInMinutes`: a duração em que as revisões de serviço azul e verde são executadas simultaneamente após a mudança do tráfego de produção ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456", "productionListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/1234567890123456", "testListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/2345678901234567", "roleArn": "arn:aws:iam::123456789012:role/ecs-nlb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## Fluxo de tráfego durante a implantação Durante uma implantação azul/verde com um Network Load Balancer, o tráfego flui pelo sistema da seguinte forma: 1. *Estado inicial*: todo o tráfego de produção é roteado para o grupo de destino principal (revisão de serviço azul). 1. *Implantação de revisão de serviço verde*: o Amazon ECS implanta as novas tarefas e as registra no grupo de destino alternativo. 1. *Tráfego de teste*: se um receptor de teste estiver configurado, o tráfego de teste será roteado para o grupo de destino alternativo para validar a revisão do serviço verde. 1. *Mudança de tráfego de produção*: o Amazon ECS atualiza o receptor de produção para rotear o tráfego para o grupo de destino alternativo (revisão de serviço verde). 1. *Tempo de incorporação*: a duração em que as revisões de serviço azul e verde são executadas simultaneamente após a mudança do tráfego de produção. 1. *Conclusão*: após uma implantação bem-sucedida, a revisão do serviço azul é encerrada. Se forem detectados problemas durante a implantação, o Amazon ECS pode reverter automaticamente roteando o tráfego de volta para o grupo de destino principal (revisão de serviço azul). # Recursos do Service Connect para implantações azul/verde, linear e canário do Amazon ECS Ao usar o Service Connect com implantações azul/verde, você precisa configurar componentes específicos para permitir o roteamento de tráfego adequado entre as revisões de serviço azul e verde. Esta seção explica os componentes necessários e suas configurações. ## Visão geral da arquitetura O Service Connect cria recursos de descoberta de serviços e de malha de serviços por meio de um proxy sidecar gerenciado que é injetado automaticamente em suas tarefas do Amazon ECS. Esses proxies processam decisões de roteamento, novas tentativas e coleta de métricas, enquanto o AWS Cloud Map fornece o backend do registro de serviços. Quando você implanta um serviço com o Service Connect habilitado, o serviço se registra no AWS Cloud Map, e os serviços do cliente o descobrem por meio do namespace. Em uma implementação padrão do Service Connect, os serviços do cliente se conectam aos nomes lógicos dos serviços, e o proxy sidecar gerencia o roteamento para as instâncias reais do serviço. Com implantações azul/verde, esse modelo é estendido para incluir roteamento de tráfego de teste por meio da configuração `testTrafficRules`. Durante uma implantação azul/verde, os seguintes componentes-chave funcionam juntos: + **Proxy do Service Connect**: todo o tráfego entre os serviços passa pelo proxy do Service Connect, que toma decisões de roteamento com base na configuração. + **Registro do AWS Cloud Map**: as implantações azul e verde são registradas com o AWS Cloud Map, mas a implantação verde é inicialmente registrada como um endpoint de “teste”. + **Roteamento de tráfego de teste**: `testTrafficRules` na configuração do Service Connect determina como identificar e rotear o tráfego de teste para a implantação verde. Isso é feito por meio do **roteamento baseado em cabeçalho**, em que cabeçalhos HTTP específicos nas solicitações direcionam o tráfego para a revisão de teste. Por padrão, o Service Connect reconhece o cabeçalho `x-amzn-ecs-blue-green-test` dos protocolos baseados em HTTP quando nenhuma regra personalizada é especificada. + **Configuração do cliente**: todos os clientes no namespace recebem automaticamente as rotas de produção e teste, mas somente as solicitações que correspondam às regras de teste serão enviadas para a implantação verde. O que torna essa abordagem eficaz é que ela lida com a complexidade da descoberta de serviços durante as transições. À medida que o tráfego muda da implantação azul para a verde, todos os mecanismos de conectividade e descoberta são atualizados automaticamente. Não há necessidade de atualizar registros DNS, reconfigurar balanceadores de carga ou implantar alterações de descoberta de serviços separadamente, pois a malha de serviços cuida de tudo isso. ## Roteamento e teste de tráfego O Service Connect fornece recursos avançados de roteamento de tráfego para implantações azul/verde, incluindo roteamento baseado em cabeçalho e configuração de alias de cliente para cenários de teste. ### Teste as regras do cabeçalho de tráfego Durante implantações em azul/verde, você pode configurar regras de cabeçalho de tráfego de teste para rotear solicitações específicas para a revisão de serviço verde (nova) para fins de teste. Isso permite que você valide a nova versão com tráfego controlado antes de concluir a implantação. O Service Connect usa **roteamento baseado em cabeçalho** para identificar o tráfego de teste. Por padrão, o Service Connect reconhece o cabeçalho `x-amzn-ecs-blue-green-test` dos protocolos baseados em HTTP quando nenhuma regra personalizada é especificada. Quando esse cabeçalho estiver presente em uma solicitação, o proxy do Service Connect roteará automaticamente a solicitação para a implantação verde para teste. As regras de cabeçalho de tráfego de teste permitem que você: + Encaminhe solicitações com cabeçalhos específicos para a revisão do serviço verde + Teste novas funcionalidades com um subconjunto do tráfego + Valide o comportamento do serviço antes da substituição total do tráfego + Implemente estratégias de teste de canário + Realize testes de integração em um ambiente semelhante ao de produção O mecanismo de roteamento baseado em cabeçalho funciona perfeitamente com sua arquitetura de aplicação existente. Os serviços do cliente não precisam estar cientes do processo de implantação azul/verde. Eles simplesmente incluem os cabeçalhos apropriados ao enviar solicitações de teste, e o proxy do Service Connect processa a lógica de roteamento automaticamente. Para obter mais informações sobre como configurar as regras de cabeçalho de tráfego de teste, consulte [ServiceConnectTestTrafficHeaderRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderRules.html)na *Referência de APIs do Amazon Elastic Container Service*. ### Regras de correspondência de cabeçalho As regras de correspondência de cabeçalho definem os critérios para rotear o tráfego de teste durante implantações azul/verde. Você pode configurar várias condições de correspondência para controlar com precisão quais solicitações são encaminhadas para a revisão do serviço verde. A correspondência de cabeçalhos é compatível com: + Correspondência exata do valor do cabeçalho + Verificação de presença de cabeçalho + Correspondência baseada em padrões + Várias combinações de cabeçalhos Exemplos de casos de uso incluem o encaminhamento de solicitações com strings específicas do agente do usuário, versões de API ou sinalizadores de recursos para o serviço verde para testes. Para obter mais informações sobre como configurar a correspondência de cabeçalhos, consulte [ServiceConnectTestTrafficHeaderMatchRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderMatchRules.html)na *Referência de APIs do Amazon Elastic Container Service*. ### Aliases de cliente para implantações azul/verde Os aliases de cliente fornecem endpoints de DNS estáveis para serviços durante implantações azul/verde. Eles permitem o roteamento contínuo do tráfego entre as revisões de serviço azul e verde sem exigir que as aplicações do cliente alterem seus endpoints de conexão. Durante uma implantação azul/verde, os aliases de cliente: + Mantêm os nomes de DNS consistentes para conexões de clientes + Habilitam a mudança automática de tráfego entre as revisões de serviço + Suportam estratégias graduais de migração de tráfego + Fornecem recursos de reversão redirecionando o tráfego para a revisão azul Você pode configurar vários aliases de cliente para portas ou protocolos diferentes, permitindo que arquiteturas de serviços complexas mantenham a conectividade durante as implantações. Para obter mais informações sobre a configuração de aliases de cliente, consulte [ServiceConnectClientAlias](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectClientAlias.html) na *Referência de APIs do Amazon Elastic Container Service*. ### Práticas recomendadas para roteamento de tráfego Ao implementar o roteamento de tráfego para implantações azul/verde com o Service Connect, considere as seguintes práticas recomendadas: + **Comece com testes baseados em cabeçalhos**: use regras de cabeçalho de tráfego de teste para validar o serviço verde com tráfego controlado antes de mudar todo o tráfego. + **Configure verificações de integridade**: garanta que os serviços azul e verde tenham verificações de integridade apropriadas configuradas para evitar o roteamento de tráfego para instâncias não íntegras. + **Monitore as métricas de serviço**: acompanhe os principais indicadores de performance de ambas as revisões de serviço durante a implantação para identificar problemas antecipadamente. + **Planeje a estratégia de reversão**: configure aliases de cliente e regras de roteamento para permitir a rápida reversão para o serviço azul se forem detectados problemas. + **Teste a lógica de correspondência de cabeçalhos**: valide suas regras de correspondência de cabeçalhos em um ambiente não de produção antes de aplicá-las às implantações de produção. ## Fluxo de trabalho de implantação azul/verde do Service Connect Entender como o Service Connect gerencia o processo de implantação azul/verde ajuda você a implementar e solucionar problemas de suas implantações de forma eficaz. O fluxo de trabalho a seguir mostra como os diferentes componentes interagem durante cada fase da implantação. ### Fases da implantação A implantação azul/verde do Service Connect avança em várias fases distintas: 1. **Estado inicial**: o serviço azul processa 100% do tráfego de produção. Todos os serviços de cliente no namespace se conectam ao serviço azul por meio do nome lógico do serviço configurado no Service Connect. 1. **Registro de serviço verde**: quando a implantação verde é iniciada, ela é registrada com o AWS Cloud Map como um endpoint de “teste”. O proxy do Service Connect nos serviços do cliente recebe automaticamente as configurações de rota de produção e teste. 1. **Roteamento de tráfego de teste**: as solicitações contendo os cabeçalhos de tráfego de teste (como `x-amzn-ecs-blue-green-test`) são automaticamente roteadas para o serviço verde pelo proxy do Service Connect. O tráfego de produção continua fluindo para o serviço azul. 1. **Preparação da mudança de tráfego**: após o teste bem-sucedido, o processo de implantação se prepara para a mudança do tráfego de produção. Tanto o serviço azul quanto o verde permanecem registrados e íntegros. 1. **Mudança de tráfego de produção**: a configuração do Service Connect é atualizada para direcionar o tráfego de produção para o serviço verde. Isso acontece automaticamente sem exigir atualizações do serviço do cliente ou alterações no DNS. 1. **Período de tempo de incorporação**: a duração em que as revisões de serviço azul e verde são executadas simultaneamente após a mudança do tráfego de produção. 1. **Cancelamento do registro do serviço azul**: após a validação e a mudança de tráfego bem-sucedidas, o registro do serviço azul é cancelado do AWS Cloud Map e encerrado, concluindo a implantação. ### Comportamento do proxy do Service Connect O proxy do Service Connect desempenha um papel crucial no gerenciamento do tráfego durante implantações azul/verde. Compreender seu comportamento ajuda você a projetar estratégias eficazes de teste e implantação. Principais comportamentos do proxy durante implantações azul/verde: + **Descoberta automática de rotas**: o proxy descobre automaticamente as rotas de produção e teste do AWS Cloud Map sem exigir a reinicialização da aplicação ou alterações na configuração. + **Roteamento baseado em cabeçalho**: o proxy examina os cabeçalhos das solicitações recebidas e encaminha o tráfego para a revisão de serviço apropriada com base nas regras de tráfego de teste configuradas. + **Integração da verificação de integridade**: o proxy direciona o tráfego somente para instâncias de serviço íntegras, excluindo automaticamente tarefas não íntegras do grupo de roteamento. + **Repetição e interrupção de circuito**: o proxy fornece lógica de repetição integrada e recursos de interrupção de circuito, melhorando a resiliência durante as implantações. + **Coleta de métricas**: o proxy coleta métricas detalhadas para o serviço azul e o verde, permitindo um monitoramento abrangente durante as implantações. ### Atualizações da descoberta de serviços Uma das principais vantagens de usar o Service Connect para implantações azul/verde é o processamento automático das atualizações de descoberta de serviços. As implantações tradicionais azul/verde geralmente exigem atualizações complexas de DNS ou a reconfiguração do balanceador de carga, mas o Service Connect gerencia essas alterações de forma transparente. Durante uma implantação, o Service Connect processa: + **Atualizações de namespace**: o namespace do Service Connect inclui automaticamente endpoints do serviço azul e do verde, com as regras de roteamento apropriadas. + **Configuração do cliente**: todos os serviços do cliente no namespace recebem automaticamente informações de roteamento atualizadas sem exigir reinicializações ou reimplantação. + **Transição gradual**: as atualizações da descoberta de serviços acontecem de forma gradual e segura, garantindo que não haja interrupções nas solicitações em andamento. + **Suporte à reversão**: se uma reversão for necessária, o Service Connect poderá reverter rapidamente as configurações da descoberta de serviços para direcionar o tráfego de volta para o serviço azul. # Criação de implantações azul/verde do Amazon ECS Ao usar implantações azul/verde do Amazon ECS, você pode fazer e testar alterações no serviço antes de implementá-las em um ambiente de produção. ## Pré-requisitos Execute as operações a seguir antes de iniciar uma implantação azul/verde. 1. Configurar as permissões apropriadas. + Para obter informações sobre as permissões do Elastic Load Balancing, consulte [Perfil do IAM da infraestrutura do Amazon ECS para balanceadores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Para obter informações sobre as permissões do Lambda, consulte [Permissões necessárias para funções do Lambda em implantações azul/verde do Amazon ECS](blue-green-permissions.md) 1. As implantações azul/verde do Amazon ECS exigem que seu serviço use um dos recursos a seguir. Configure os recursos apropriados. + Application Load Balancer: para obter mais informações, consulte [Recursos do Application Load Balancer para implantações azul/verde, linear e canário](alb-resources-for-blue-green.md). + Network Load Balancer: para obter mais informações, consulte [Recursos do Network Load Balancer para implantações azul/verde, lineares e canário do Amazon ECS](nlb-resources-for-blue-green.md). + Service Connect: para obter mais informações, consulte [Recursos do Service Connect para implantações azul/verde, linear e canário do Amazon ECS](service-connect-blue-green.md). 1. Decida se deseja executar as funções do Lambda para os estágios do ciclo de vida. + PRE\$1SCALE\$1UP + POST\$1SCALE\$1UP + TEST\$1TRAFFIC\$1SHIFT + POST\$1TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT Para obter mais informações, consulte [Criar uma função do Lambda com o console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) no *Guia do desenvolvedor do AWS Lambda*. ## Procedimento Você pode usar o console ou a AWS CLI para criar um serviço azul/verde do Amazon ECS. ------ #### [ Console ] 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Determine o recurso no qual você inicia o serviço. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/deploy-blue-green-service.html) A página **Criar serviço** é exibida. 1. Em **Detalhes do serviço**, faça o seguinte: 1. Em **Família de definições de tarefas**, escolha a definição de tarefa a ser usada. Em seguida, em **Revisão da definição de tarefa**, insira a revisão a ser usada. 1. Em **Service name** (Nome do serviço), insira um nome para o serviço. 1. Para executar o serviço em um cluster existente, em **Cluster existente**, escolha o cluster. Para executar o serviço em um novo cluster, escolha **Criar cluster** 1. Escolha como suas tarefas serão distribuídas em toda a infraestrutura do cluster. Expanda **Configuração de computação** e escolha sua opção. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/deploy-blue-green-service.html) 1. Em **Configuração de implantação**, faça o seguinte: 1. Em **Tipo de serviço**, escolha **Réplica**. 1. Em **Desired tasks** (Tarefas desejadas), insira o número de tarefas que serão iniciadas e mantidas no serviço. 1. Para que o Amazon ECS monitore a distribuição de tarefas entre as zonas de disponibilidade e as redistribua quando houver um desequilíbrio, em **Rebalanceamento do serviço em zonas de disponibilidade**, selecione **Rebalanceamento do serviço em zonas de disponibilidade**. 1. Em **Período de carência da verificação de integridade**, insira quanto tempo (em segundos) após o início de uma tarefa o agendador do serviço ignorará as verificações de integridade que forem não íntegras para o Elastic Load Balancing, o VPC Lattice e o contêiner. Se você não especificar um valor de período de tolerância de verificação de integridade, o valor padrão 0 será usado. 1. 1. Em **Tempo de incorporação**, insira o número de minutos em que as revisões do serviço azul e do verde serão executadas simultaneamente antes que a revisão azul seja encerrada. Isso possibilita um tempo para a verificação e testes. 1. (Opcional) Execute as funções do Lambda para serem executadas em estágios específicos da implantação. Em **Ganchos do ciclo de vida de implantação**, selecione os estágios para executar os ganchos do ciclo de vida. Para adicionar um gancho do ciclo de vida: 1. Escolha **Adicionar**. 1. Em **Função do Lambda**, insira o nome da função ou o ARN. 1. Em **Perfil** selecione o perfil do IAM que tem permissão para invocar a função do Lambda. 1. Em **Estágios do ciclo de vida**, selecione os estágios em que a função do Lambda deve ser executada. 1. Para configurar como o Amazon ECS detectará e lidará com falhas de implantação, expanda **Deployment failure detection**(Detecção de falhas de implantação) e escolha suas opções. 1. Para interromper uma implantação quando as tarefas não podem ser iniciadas, selecione **Use the Amazon ECS deployment circuit breaker)** (Usar o disjuntor de implantação do Amazon ECS. Para que o software reverta automaticamente a implantação para o último estado de implantação concluído quando o disjuntor de implantação definir a implantação para um estado de falha, selecione **Reverter em caso de falha**. 1. Para interromper uma implantação com base nas métricas da aplicação, selecione **Usar alarmes do CloudWatch**. Em seguida, em **Nomes de alarmes do CloudWatch**, escolha os alarmes. Para criar um alarme, acesse o console do CloudWatch. Para que o software reverta automaticamente a implantação para o último estado de implantação concluído quando um alarme do CloudWatch definir a implantação para um estado de falha, selecione **Reverter em caso de falha**. 1. (Opcional) Para interconectar o serviço usando o Service Connect, expanda **Service Connect** e especifique o seguinte: 1. Selecione **Ativar o Service Connect**. 1. Em **Service Connect configuration** (Configuração do Service Connect), especifique o modo cliente. + Se seu serviço executa uma aplicação cliente de rede que só precisa se conectar a outros serviços no namespace, escolha **Somente no lado do cliente**. + Se seu serviço executa uma aplicação de rede ou de serviço Web e precisa fornecer endpoints para esse serviço e se conectar a outros serviços no namespace, escolha **Client and server** (Cliente e servidor). 1. Para usar um namespace que não seja o namespace padrão do cluster, em **Namespace**, escolha o namespace do serviço. Isso pode ser um namespace criado separadamente na mesma Região da AWS em sua Conta da AWS ou um namespace na mesma região compartilhada com sua conta usando o AWS Resource Access Manager (AWS RAM). Para obter mais informações sobre namespaces compartilhados do AWS Cloud Map, consulte [Compartilhamento de namespaces do AWS Cloud Map entre contas](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) no *Guia do desenvolvedor do AWS Cloud Map*. 1. (Opcional) Configure regras de cabeçalho de tráfego de teste para implantações em azul/verde. Em **Testar roteamento de tráfego**, especifique o seguinte: 1. Selecione **Habilitar regras de cabeçalho de tráfego de teste** para rotear solicitações específicas para a revisão do serviço verde durante o teste. 1. Em **Regras de correspondência de cabeçalhos**, configure os critérios para rotear o tráfego de teste: + **Nome do cabeçalho**: insira o nome do cabeçalho HTTP correspondente (por exemplo, `X-Test-Version` ou `User-Agent`). + **Tipo de correspondência**: escolha os critérios de correspondência: + **Correspondência exata**: roteie solicitações em que o valor do cabeçalho corresponda exatamente ao valor especificado + **Cabeçalho presente**: roteie solicitações que contenham o cabeçalho especificado, independentemente do valor + **Correspondência de padrões**: roteie solicitações em que o valor do cabeçalho corresponda a um padrão especificado + **Valor do cabeçalho** (se estiver usando correspondência exata ou correspondência de padrão): insira o valor ou padrão com o qual corresponder. Você pode adicionar várias regras de correspondência de cabeçalhos para criar uma lógica de roteamento complexa. As solicitações que correspondam a qualquer uma das regras configuradas serão encaminhadas para a revisão do serviço verde para testes. 1. Escolha **Adicionar regra de cabeçalho** para configurar condições adicionais de correspondência de cabeçalho. **nota** As regras de cabeçalho de tráfego de teste permitem que você valide a nova funcionalidade com tráfego controlado antes de concluir a implantação completa. Isso permite que você teste a revisão do serviço verde com solicitações específicas (como as de ferramentas de teste internas ou usuários beta) enquanto mantém o fluxo de tráfego normal para a revisão do serviço azul. 1. (Opcional) Especifique uma configuração de log. Selecione **Usar conjunto de logs**. A opção padrão envia os logs do contêiner ao CloudWatch Logs. As outras opções de driver de log são configuradas usando o AWS FireLens. Para obter mais informações, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md). Veja a seguir a descrição de cada destino de log de contêiner mais detalhadamente. + **Amazon CloudWatch**: configura a tarefa para enviar logs de contêiner ao CloudWatch Logs. São fornecidas as opções de driver de log padrão, que criam um grupo de logs do CloudWatch em seu nome. Para especificar um nome de grupo de logs diferente, altere os valores da opção de driver. + **Amazon Data Firehose**: configura a tarefa para enviar logs de contêiner ao Firehose. São fornecidas as opções de driver de log padrão, que enviam logs para um fluxo de entrega do Firehose. Para especificar um nome de fluxo de entrega diferente, altere os valores da opção de driver. + **Amazon Kinesis Data Streams**: configura a tarefa para enviar logs de contêiner ao Kinesis Data Streams. São fornecidas as opções de driver de log padrão, que enviam logs a um fluxo do Kinesis Data Streams. Para especificar um nome de transmissão diferente, altere os valores da opção de driver. + **Amazon OpenSearch Service**: configura a tarefa para enviar logs de contêiner a um domínio do OpenSearch Service. As opções de driver de log devem ser fornecidas. + **Amazon S3**: configura a tarefa para enviar logs de contêiner a um bucket do Amazon S3. As opções de driver de log padrão são fornecidas, mas você deve especificar um nome de bucket válido do Amazon S3. 1. (Opcional) Configure o **balanceamento de carga** para implantação azul/verde. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/deploy-blue-green-service.html) 1. (Opcional) Para ajudar a identificar seu serviço e tarefas, expanda a seção **Tags** (Etiquetas) e configure suas etiquetas. Para que o Amazon ECS atribua tags automaticamente a todas as tarefas recém-iniciadas com o nome do cluster e as tags de definição de tarefa, selecione **Ativar tags gerenciadas pelo Amazon ECS** e, para **Propagar tags de**, escolha **Definições de tarefas**. Para que o Amazon ECS atribua tags automaticamente a todas as tarefas recém-iniciadas com o nome do cluster e as tags de serviços, selecione **Ativar tags gerenciadas pelo Amazon ECS** e, para **Propagar tags de**, escolha **Serviço**. Adicione ou remova uma tag. + [Adicionar uma etiqueta] Escolha **Add tag** (Adicionar etiqueta) e faça o seguinte: + Em **Chave**, insira o nome da chave. + Em **Valor** insira o valor da chave. + [Remover uma tag] Ao lado da tag, escolha **Remove tag (Remover tag)**. 1. Escolha **Criar**. ------ #### [ AWS CLI ] 1. Crie um arquivo chamado `service-definition.json` com o conteúdo a seguir. Substitua os valores das *user-input* pelos seus. ``` { "serviceName": "myBlueGreenService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 2, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true }, "lifecycleHooks": [ { "hookTargetArn": "arn:aws:lambda:us-west-2:7123456789012:function:checkExample", "roleArn": "arn:aws:iam::123456789012:role/ECSLifecycleHookInvoke", "lifecycleStages": [ "PRE_SCALE_UP" ] } ] }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-blue-green-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. Executar `create-service`. Substitua os valores das *user-input* pelos seus. ``` aws ecs create-service --cli-input-json file://service-definition.json ``` Como alternativa, você pode usar o exemplo a seguir, que cria um serviço de implantação azul/verde com uma configuração de balanceador de carga: ``` aws ecs create-service \ --cluster "arn:aws:ecs:us-west-2:123456789012:cluster/MyCluster" \ --service-name "blue-green-example-service" \ --task-definition "nginxServer:1" \ --launch-type "FARGATE" \ --network-configuration "awsvpcConfiguration={subnets=[subnet-12345,subnet-67890,subnet-abcdef,subnet-fedcba],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \ --desired-count 3 \ --deployment-controller "type=ECS" \ --deployment-configuration "strategy=BLUE_GREEN,maximumPercent=200,minimumHealthyPercent=100,bakeTimeInMinutes=0" \ --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg1/abcdef1234567890,containerName=nginx,containerPort=80,advancedConfiguration={alternateTargetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg2/0987654321fedcba,productionListenerRule=arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/MyLB/1234567890abcdef/1234567890abcdef,roleArn=arn:aws:iam::123456789012:role/ELBManagementRole}" ``` ------ ## Próximas etapas + Atualize o serviço para iniciar a implantação. Para obter mais informações, consulte [Atualizar um serviço do Amazon ECS](update-service-console-v2.md). + Monitore o processo de implantação para garantir que ele siga o padrão azul/verde: + A revisão do serviço verde é criada e tem a escala aumentada verticalmente + O tráfego de teste é roteado para a revisão verde (se configurado) + O tráfego de produção é mudado para a revisão verde + Após o tempo de incorporação, a revisão azul é encerrada # Solucionar problemas de implantações azuis/verdes do Amazon ECS Veja as soluções para problemas comuns que podem surgir ao usar implantações azul/verde com o Amazon ECS. Erros de implantação azul/verde podem ocorrer durante as seguintes fases: + *Caminho síncrono*: erros que surgem imediatamente em resposta às chamadas de API `CreateService` ou `UpdateService`. + *Caminho assíncrono*: erros que surgem no campo `statusReason` de `DescribeServiceDeployments` e causam uma reversão da implantação **dica** Você pode usar o [Servidor MCP do Amazon ECS](ecs-mcp-introduction.md) com assistentes de IA para monitorar implantações e solucionar problemas de implantação usando linguagem natural. ## Problemas de configuração do balanceador de carga A configuração do balanceador de carga é um componente crítico das implantações azul/verde no Amazon ECS. A configuração adequada das regras do receptor, dos grupos-alvo e dos tipos de balanceador de carga é essencial para implantações bem-sucedidas. Esta seção aborda problemas comuns de configuração do balanceador de carga que podem causar falhas nas implantações azul/verde. Ao solucionar problemas de balanceador de carga, é importante entender a relação entre regras de receptores e grupos de destino. Em uma implantação azul/verde: + A regra do receptor de produção direciona o tráfego para a revisão de serviço ativa no momento (azul) + A regra do receptor de teste pode ser usada para validar a nova revisão de serviço (verde) antes de mudar o tráfego de produção + Os grupos de destino são usados para registrar as instâncias do contêiner de cada revisão de serviço + Durante a implantação, o tráfego é gradualmente transferido da revisão de serviço azul para a revisão de serviço verde mediante o ajuste dos pesos dos grupos de destino nas regras do receptor ### Erros de configuração da regra do receptor Os problemas a seguir estão relacionados à configuração incorreta de regras de receptor para implantações azul/verde. Usar um ARN de receptor do Application Load Balancer em vez de um ARN de regra de receptor *Mensagem de erro*: `productionListenerRule has an invalid ARN format. Must be RuleArn for ALB or ListenerArn for NLB. Got: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456` *Solução*: ao usar um Application Load Balancer, é necessário especificar um ARN de regra de receptor para `productionListenerRule` e `testListenerRule`, e não um ARN de receptor. Para Network Load Balancers, é necessário usar o ARN do receptor. Para obter mais informações sobre como encontrar o ARN do receptor, consulte [Receptores para seus Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) no *Guia do usuário do Application Load Balancer*. O ARN de uma regra tem o formato `arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/...`. Usar a mesma regra para receptores de produção e teste *Mensagem de erro*: `The following rules cannot be used as both production and test listener rules: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789` *Solução*: é necessário usar regras de receptor diferentes para tráfego de produção e teste. Crie uma regra de receptor separada para o tráfego de teste que é roteado para seu grupo de destino de teste. Grupo de destino não associado às regras do receptor *Mensagem de erro*: `Service deployment rolled back because of invalid networking configuration: Target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myAlternateTG/abc123 is not associated with either productionListenerRule or testListenerRule.` *Solução*: tanto o grupo de destino principal quanto o grupo de destino alternativo devem estar associados à regra do receptor de produção ou à regra do receptor de teste. Atualize a configuração do balanceador de carga para garantir que os dois grupos de destino estejam associados adequadamente às suas regras de receptor. Regra do receptor de teste ausente para um Application Load Balancer *Mensagem de erro*: `For Application LoadBalancer, testListenerRule is required when productionListenerRule is not associated with both targetGroup and alternateTargetGroup` *Solução*: ao usar um Application Load Balancer, se ambos os grupos de destino não estiverem associados à regra de receptor de produção, você deverá especificar uma regra de receptor de teste. Adicione `testListenerRule` à sua configuração e garanta que os dois grupos de destino estejam associados à regra de receptor de produção ou de teste. Para obter mais informações, consulte [Cotas para seus Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) no *Guia do usuário do Application Load Balancer*. ### Erros de configuração do grupo de destino Os problemas a seguir estão relacionados à configuração incorreta de grupos de destino para implantações azul/verde. Vários grupos de destino com tráfego na regra do receptor *Mensagem de erro*: `Service deployment rolled back because of invalid networking configuration. productionListenerRule arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789 should have exactly one target group serving traffic but found 2 target groups which are serving traffic` *Solução*: antes de iniciar uma implantação azul/verde, certifique-se de que somente um grupo de destino esteja recebendo tráfego (com um peso diferente de zero) na sua regra de receptor. Atualize a configuração da regra do receptor para definir o peso como zero para qualquer grupo de destino que não deveria receber tráfego. Grupos de destino duplicados nas entradas do balanceador de carga *Mensagem de erro*: `Duplicate targetGroupArn found: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myecs-targetgroup/abc123` *Solução*: cada ARN de grupo de destino deve ser exclusivo em todas as entradas do balanceador de carga em sua definição de serviço. Revise sua configuração e certifique-se de usar grupos de destino diferentes para cada entrada do balanceador de carga. Grupo de destino inesperado na regra do receptor de produção *Mensagem de erro*: `Service deployment rolled back because of invalid networking configuration. Production listener rule is forwarding traffic to unexpected target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/random-nlb-tg/abc123. Expected traffic to be forwarded to either targetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-targetgroup/def456 or alternateTargetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-tg-alternate/ghi789` *Solução*: a regra do receptor de produção está encaminhando o tráfego para um grupo de destino que não está especificado em sua definição de serviço. Certifique-se de que a regra do receptor esteja configurada para encaminhar o tráfego somente para os grupos de destino especificados em sua definição de serviço. Para obter mais informações, consulte [ações de encaminhamento](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#forward-actions) no *Guia do usuário do Application Load Balancer*. ### Erros de configuração do tipo de balanceador de carga Os problemas a seguir estão relacionados à configuração incorreta do tipo de balanceador de carga para implantações azul/verde. Misturando configurações de Classic Load Balancer e Application Load Balancer ou Network Load Balancer *Mensagem de erro*: `All loadBalancers must be strictly either ELBv1 (defining loadBalancerName) or ELBv2 (defining targetGroupArn)` Os Classic Load Balancers são balanceadores de carga da geração anterior ao Elastic Load Balancing. Recomendamos migrar para um balanceador de carga da geração atual. Para obter mais informações, consulte [Migrar seus Classic Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-classic-load-balancer.html). *Solução*: . Use somente Classic Load Balancers ou então Application Load Balancers e Network Load Balancers. Para Application Load Balancers e Network Load Balancers, especifique apenas o campo `targetGroupArn`. Usar configuração avançada com um Classic Load Balancer *Mensagem de erro*: `advancedConfiguration field is not allowed with ELBv1 loadBalancers` *Solução*: a configuração avançada para implantações azul/verde só é compatível com Application Load Balancers e Network Load Balancers. Se você usa um Classic Load Balancer (especificado com `loadBalancerName`), não poderá usar o campo `advancedConfiguration`. Migre para um Application Load Balancer ou remova o campo `advancedConfiguration`. Configuração avançada inconsistente entre balanceadores de carga *Mensagem de erro*: `Either all or none of the provided loadBalancers must have advancedConfiguration defined` *Solução*: se você estiver usando vários balanceadores de carga, deverá definir `advancedConfiguration` para todos eles ou para nenhum deles. Atualize sua configuração para garantir a consistência em todas as entradas do balanceador de carga. Ausência de configuração avançada com implantação azul/verde *Mensagem de erro*: `advancedConfiguration field is required for all loadBalancers when using a non-ROLLING deployment strategy` *Solução*: ao usar uma estratégia de implantação azul/verde com Application Load Balancers, é necessário especificar o campo `advancedConfiguration` para todas as entradas do balanceador de carga. Adicione o `advancedConfiguration` necessário à configuração do balanceador de carga. ## Problemas com permissões Os problemas a seguir estão relacionados a permissões insuficientes para implantações azul/verde. Política de confiança ausente em perfil de infraestrutura *Mensagem de erro*: `Service deployment rolled back because of invalid networking configuration. ECS was unable to manage the ELB resources due to missing permissions on ECS Infrastructure Role 'arn:aws:iam::123456789012:role/Admin'.` *Solução*: o perfil do IAM especificado para gerenciar recursos do balanceador de carga não tem a política de confiança correta. Atualize a política de confiança do perfil para permitir que o serviço assuma o perfil. A política de confiança deve incluir: **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` Permissões de leitura ausentes no perfil do balanceador de carga *Mensagem de erro*: `service myService failed to describe target health on target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:DescribeTargetHealth because no identity-based policy allows the elasticloadbalancing:DescribeTargetHealth action)` *Solução*: o perfil do IAM usado para gerenciar recursos do balanceador de carga não tem permissão para ler as informações de integridade do destino. Adicione a permissão `elasticloadbalancing:DescribeTargetHealth` à política do perfil. Para obter informações sobre as permissões do Elastic Load Balancing, consulte [Perfil do IAM da infraestrutura do Amazon ECS para balanceadores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Permissões de gravação ausentes no perfil do balanceador de carga *Mensagem de erro*: `service myService failed to register targets in target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:RegisterTargets on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myTargetGroup/abc123 because no identity-based policy allows the elasticloadbalancing:RegisterTargets action)` *Solução*: o perfil do IAM usado para gerenciar recursos do balanceador de carga não tem permissão para registrar destinos. Adicione a permissão `elasticloadbalancing:RegisterTargets` à política do perfil. Para obter informações sobre as permissões do Elastic Load Balancing, consulte [Perfil do IAM da infraestrutura do Amazon ECS para balanceadores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Ausência de permissão para modificar as regras do receptor *Mensagem de erro*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. User: arn:aws:sts::123456789012:assumed-role/myELBRole/ECSNetworkingWithELB is not authorized to perform: elasticloadbalancing:ModifyListener on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456 because no identity-based policy allows the elasticloadbalancing:ModifyListener action` *Solução*: o perfil do IAM usado para gerenciar recursos do balanceador de carga não tem permissão para modificar receptores. Adicione a permissão `elasticloadbalancing:ModifyListener` à política do perfil. Para obter informações sobre as permissões do Elastic Load Balancing, consulte [Perfil do IAM da infraestrutura do Amazon ECS para balanceadores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Para implantações azul/verde, recomendamos anexar a política gerenciada `AmazonECS-ServiceLinkedRolePolicy` ao seu perfil de infraestrutura, o qual inclui todas as permissões necessárias para gerenciar os recursos do balanceador de carga. ## Problemas de gancho do ciclo de vida Os problemas a seguir estão relacionados a ganchos do ciclo de vida em implantações azul/verde. Política de confiança incorreta no perfil do hook do Lambda *Mensagem de erro*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to assume role arn:aws:iam::123456789012:role/Admin` *Solução*: o perfil do IAM especificado para o gancho do ciclo de vida do Lambda não tem a política de confiança correta. Atualize a política de confiança do perfil para permitir que o serviço assuma o perfil. A política de confiança deve incluir: **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` O hook do Lambda retorna o status de FALHA *Mensagem de erro*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. Lifecycle hook target arn:aws:lambda:us-west-2:123456789012:function:myHook returned FAILED status.` *Solução*: a função do Lambda especificada como um gancho do ciclo de vida retornou um status de FALHA. Verifique os logs da função Lambda nos logs do Amazon CloudWatch para determinar o motivo da falha e atualize a função para lidar com o evento de implantação corretamente. Ausência de permissão para invocar função do Lambda *Mensagem de erro*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to invoke hook target arn:aws:lambda:us-west-2:123456789012:function:myHook due to User: arn:aws:sts::123456789012:assumed-role/myLambdaRole/ECS-Lambda-Execution is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-west-2:123456789012:function:myHook because no identity-based policy allows the lambda:InvokeFunction action` *Solução*: o perfil do IAM usado para o gancho do ciclo de vida do Lambda não tem permissão para invocar a função do Lambda. Adicione a permissão `lambda:InvokeFunction` à política do perfil para o ARN da função do Lambda específica. Para obter informações sobre as permissões do Lambda, consulte [Permissões necessárias para funções do Lambda em implantações azul/verde do Amazon ECS](blue-green-permissions.md). Tempo limite excedido ou resposta inválida da função do Lambda *Mensagem de erro*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to parse the response from arn:aws:lambda:us-west-2:123456789012:function:myHook due to HookStatus must not be null` *Solução*: a função Lambda atingiu o tempo limite ou retornou uma resposta inválida. Certifique-se de que sua função do Lambda retorne uma resposta válida com um campo `hookStatus` definido como `SUCCEEDED` ou `FAILED`. Além disso, verifique se o tempo limite da função do Lambda está definido adequadamente para sua lógica de validação. Para obter mais informações, consulte [Ganchos do ciclo de vida para implantações de serviços do Amazon ECS](deployment-lifecycle-hooks.md). Exemplo de uma resposta do Lambda válida: ``` { "hookStatus": "SUCCEEDED", "reason": "Validation passed" } ``` # Implantações lineares do Amazon ECS As implantações lineares transferem gradualmente o tráfego da revisão de serviço antiga para a nova em incrementos iguais ao longo do tempo, permitindo que você monitore cada etapa antes de prosseguir para a próxima. Com as implantações lineares do Amazon ECS, controle o ritmo da mudança de tráfego e valide novas revisões de serviços com quantidades crescentes de tráfego de produção. Essa abordagem fornece uma maneira controlada de implantar alterações com a capacidade de monitorar a performance a cada incremento. ## Recursos envolvidos em uma implantação linear Veja a seguir os recursos envolvidos nas implantações lineares do Amazon ECS: + Mudança de tráfego: o processo que o Amazon ECS usa para transferir o tráfego de produção. Para implantações lineares do Amazon ECS, o tráfego é deslocado em incrementos percentuais iguais com tempos de espera configuráveis entre cada incremento. + Porcentagem da etapa: a porcentagem do tráfego a ser deslocado em cada incremento durante uma implantação linear. Esse campo usa Dobro como valor, e os valores válidos vão de 3,0 a 100,0. + Tempo de incorporação da etapa: a duração da espera entre cada incremento de mudança de tráfego durante uma implantação linear. Os valores válidos vão de 0 a 1.440 minutos. + Tempo de incorporação da implantação: o tempo, em minutos, que o Amazon ECS espera após transferir todo o tráfego de produção para a nova revisão de serviço, antes de encerrar a revisão antiga. Essa é a duração em que as revisões de serviço azul e verde são executadas simultaneamente após a mudança do tráfego de produção. + Estágios do ciclo de vida: uma série de eventos na operação de implantação, como “após a mudança no tráfego de produção”. + Gancho do ciclo de vida: uma função do Lambda que executa um estágio específico do ciclo de vida. Você pode criar uma função que verifica a implantação. As funções do Lambda ou os ganchos do ciclo de vida configurados para PRODUCTION\$1TRAFFIC\$1SHIFT serão invocados em cada etapa de mudança de tráfego de produção. + Grupo de destino: um recurso do Elastic Load Balancing usado para rotear solicitações para um ou mais destinos registrados (por exemplo, instâncias do EC2). Ao criar um listener, especifique um grupo de destino para a ação padrão dele. O tráfego é encaminhado para o grupo de destino especificado na regra do listener. + Receptor: um recurso do Elastic Load Balancing que verifica solicitações de conexão usando o protocolo e a porta que você configurou. As regras que você define para um receptor determinam como o Amazon ECS roteia solicitações para seus destinos registrados. + Regra: um recurso do Elastic Load Balancing associado a um receptor. Uma regra define como as solicitações são roteadas e consiste em uma ação, condição e prioridade. ## Considerações Considere o seguinte ao escolher um tipo de implantação: + Uso de recursos: as implantações lineares executam temporariamente as revisões de serviços azul e verde simultaneamente, o que pode dobrar o uso de recursos durante as implantações. + Monitoramento da implantação: as implantações lineares fornecem informações mais detalhadas sobre o status da implantação, permitindo que você monitore cada estágio do processo de implantação e cada incremento de mudança de tráfego. + Reversão: as implantações lineares facilitam a reversão para a versão anterior se forem detectados problemas, pois a revisão azul é mantida em execução até que o tempo de incorporação expire. + Validação gradual: as implantações lineares permitem que você valide a nova revisão com quantidades crescentes de tráfego de produção, proporcionando mais confiança na implantação. + Duração da implantação: as implantações lineares demoram mais para serem concluídas do que as implantações completas por causa da mudança incremental do tráfego e aos tempos de espera entre as etapas. ## Como funciona a implantação linear O processo de implantação linear do Amazon ECS segue uma abordagem estruturada com seis fases distintas que garantem atualizações seguras e confiáveis das aplicações. Cada fase tem um propósito específico na validação e transição da aplicação da versão atual (azul) para a nova versão (verde). 1. Fase de preparação: crie o ambiente verde junto com o ambiente azul existente. 1. Fase de implantação: implante a nova revisão do serviço no ambiente verde. O Amazon ECS lança novas tarefas usando a revisão atualizada do serviço, enquanto o ambiente azul continua atendendo ao tráfego de produção. 1. Fase de teste: valide o ambiente verde usando o roteamento de tráfego de teste. O Application Load Balancer direciona as solicitações de teste para o ambiente verde, enquanto o tráfego de produção permanece no azul. 1. Fase de mudança de tráfego linear: mude gradualmente o tráfego de produção de azul para verde em incrementos percentuais iguais com base na sua estratégia de implantação configurada. 1. Fase de monitoramento: monitore a integridade da aplicação, as métricas de performance e os estados dos alarmes durante o tempo de incorporação. Uma operação de reversão é iniciada quando problemas são detectados. 1. Fase de conclusão: finalize a implantação encerrando o ambiente azul. A fase de mudança de tráfego linear segue estas etapas: + Inicial: a implantação começa com 100% do tráfego roteado para a revisão de serviço azul (atual). A revisão de serviço verde (nova) recebe tráfego de teste, mas nenhum tráfego de produção inicialmente. + Mudança incremental de tráfego: o tráfego é gradualmente deslocado de azul para verde em incrementos percentuais iguais. Por exemplo, com uma configuração de etapa de 10,0%, as mudanças de tráfego ocorrem da seguinte forma: + Etapa 1: 10,0% para verde, 90,0% para azul + Etapa 2: 20,0% para verde, 80,0% para azul + Etapa 3: 30,0% para verde, 70,0% para azul + E assim por diante até que chegue a 100% verde + Tempo de incorporação da etapa: entre cada incremento de mudança de tráfego, a implantação espera por uma duração configurável (tempo de incorporação da etapa) para permitir o monitoramento e a validação da performance da nova revisão com o aumento da carga de tráfego. Observe que o tempo de incorporação da última etapa é ignorado quando o tráfego é deslocado em 100,0%. + Ganchos do ciclo de vida: as funções do Lambda opcionais podem ser executadas em vários estágios do ciclo de vida durante a implantação para executar validação automatizada, monitoramento ou lógica personalizada. As funções do Lambda ou os ganchos do ciclo de vida configurados para PRODUCTION\$1TRAFFIC\$1SHIFT serão invocados em cada etapa de mudança de tráfego de produção. ## Estágios do ciclo de vida de implantação O processo de implantação linear percorre os diferentes estágios do ciclo de vida, cada um com responsabilidades específicas e pontos de verificação de validação. A compreensão desses estágios ajuda você a monitorar o andamento da implantação e solucionar problemas de forma eficaz. Cada estágio do ciclo de vida pode durar até 24 horas e, além disso, cada etapa de mudança de tráfego em PRODUCTION\$1TRAFFIC\$1SHIFT pode durar até 24 horas. Recomendamos que o valor permaneça abaixo da marca de 24 horas. Isso ocorre porque os processos assíncronos precisam de tempo para acionar os ganchos. O sistema atinge o tempo limite, falha na implantação e, em seguida, inicia uma reversão após um estágio atingir 24 horas. As implantações CloudFormation têm restrições adicionais de tempo limite. Embora o limite de estágio de 24 horas permaneça em vigor, o CloudFormation impõe um limite de 36 horas em toda a implantação. A implantação do CloudFormation falha e, em seguida, iniciará uma reversão se o processo não for concluído em até 36 horas. | Estágios do ciclo de vida | Descrição | Suporte de gancho do ciclo de vida | | --- | --- | --- | | RECONCILE\$1SERVICE | Este estágio só acontece quando você inicia uma nova implantação de serviço com mais de uma revisão de serviço em um estado ACTIVE. | Sim | | PRE\$1SCALE\$1UP | A revisão do serviço verde ainda não foi iniciada. A revisão do serviço azul está processando 100% do tráfego de produção. Não há tráfego de teste. | Sim | | SCALE\$1UP | O momento em que a revisão do serviço verde aumenta a escala verticalmente até 100% e inicia novas tarefas. A revisão do serviço verde não está recebendo nenhum tráfego neste momento. | Não | | POST\$1SCALE\$1UP | A revisão do serviço verde foi iniciada. A revisão do serviço azul está processando 100% do tráfego de produção. Não há tráfego de teste. | Sim | | TEST\$1TRAFFIC\$1SHIFT | As revisões do serviço azul e verde estão em execução. A revisão do serviço azul processa 100% do tráfego de produção. A revisão do serviço verde está migrando de 0% para 100% do tráfego de teste. | Sim | | POST\$1TEST\$1TRAFFIC\$1SHIFT | A mudança de tráfego de teste foi concluída. A revisão do serviço verde processa 100% do tráfego de teste. | Sim | | PRODUCTION\$1TRAFFIC\$1SHIFT | O tráfego é gradualmente deslocado de azul para verde em incrementos percentuais iguais até que o verde receba 100% do tráfego. Cada mudança de tráfego invoca um gancho do ciclo de vida com tempo limite de 24 horas. | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | A mudança do tráfego de produção está concluída. | Sim | | BAKE\$1TIME | A duração em que as revisões de serviço azul e verde são executadas simultaneamente. | Não | | CLEAN\$1UP | A revisão do serviço azul teve a escala reduzida verticalmente por completo para 0 tarefa em execução. A revisão do serviço verde agora é a revisão do serviço de produção após esse estágio. | Não | # Recursos necessários para implantações lineares do Amazon ECS Para usar uma implantação linear com mudança de tráfego gerenciada, seu serviço deve usar um dos seguintes recursos: + Elastic Load Balancing + Service Connect A lista abaixo fornece uma visão geral de alto nível do que você precisa configurar para implantações lineares do Amazon ECS: + Seu serviço usa o Application Load Balancer, o Network Load Balancer ou o Service Connect. Configure os recursos apropriados. + Application Load Balancer: para obter mais informações, consulte [Recursos do Application Load Balancer para implantações azul/verde, linear e canário](alb-resources-for-blue-green.md). + Network Load Balancer: para obter mais informações, consulte [Recursos do Network Load Balancer para implantações azul/verde, lineares e canário do Amazon ECS](nlb-resources-for-blue-green.md). + Service Connect: para obter mais informações, consulte [Recursos do Service Connect para implantações azul/verde, linear e canário do Amazon ECS](service-connect-blue-green.md). + Defina o controlador de implantação do serviço para `ECS`. + Configure a estratégia de implantação como `linear` na sua definição de serviço. + Opcionalmente, configure parâmetros adicionais, como: + Tempo de incorporação para a nova implantação + A porcentagem de mudança de tráfego em cada incremento. + A duração em minutos de espera entre cada incremento de mudança de tráfego. + Alarmes do CloudWatch para reversão automática + Ganchos do ciclo de vida da implantação (essas são funções do Lambda que são executadas em estágios de implantação específicos, como BEFORE\$1INSTALL, PRODUCTION\$1TRAFFIC\$1SHIFT ou POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT) ## Práticas recomendadas Siga estas práticas recomendadas para implantações lineares do Amazon ECS bem-sucedidas: + **Garanta que sua aplicação possa processar ambas as revisões de serviços em execução simultânea.** + **Planeje uma capacidade de cluster suficiente para processar ambas as revisões de serviços durante a implantação.** + **Teste seus procedimentos de reversão antes de implementá-los na produção.** + Configure as verificações de integridade apropriadas que reflitam com precisão a integridade da sua aplicação. + Defina um tempo de incorporação que permita testes suficientes da nova revisão de serviço. + Implemente alarmes do CloudWatch para detectar problemas automaticamente e acionar reversões. + Escolha porcentagens de etapas e tempos de incorporação que equilibrem a velocidade de implantação com as necessidades de validação. + Use porcentagens de etapas menores (5 a 10%) em aplicações críticas para minimizar a exposição ao risco. + Defina tempos de incorporação de etapas mais longos para aplicações que precisam de tempo para aquecer ou estabilizar. + Implemente alarmes do CloudWatch para detectar problemas automaticamente e acionar reversões em qualquer incremento de tráfego. + Monitore de perto as métricas da aplicação durante cada mudança de tráfego para detectar precocemente a degradação da performance. + Garanta que sua aplicação possa processar ambas as revisões de serviços em execução simultânea. + Teste seus procedimentos de reversão em diferentes porcentagens de tráfego antes de implementá-los na produção. # Criar uma implantação linear do Amazon ECS Ao usar implantações lineares do Amazon ECS, você pode mudar gradualmente o tráfego em incrementos iguais com intervalos de tempo especificados. Isso fornece validação controlada em cada etapa do processo de implantação. ## Pré-requisitos Execute as operações a seguir antes de iniciar uma implantação linear. 1. Configurar as permissões apropriadas. + Para obter informações sobre as permissões do Elastic Load Balancing, consulte [Perfil do IAM da infraestrutura do Amazon ECS para balanceadores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Para obter informações sobre as permissões do Lambda, consulte [Permissões necessárias para funções do Lambda em implantações azul/verde do Amazon ECS](blue-green-permissions.md). 1. As implantações lineares do Amazon ECS exigem que seu serviço use um dos recursos a seguir. Configure os recursos apropriados. + Application Load Balancer: para obter mais informações, consulte [Recursos do Application Load Balancer para implantações azul/verde, linear e canário](alb-resources-for-blue-green.md). + Network Load Balancer: para obter mais informações, consulte [Recursos do Network Load Balancer para implantações azul/verde, lineares e canário do Amazon ECS](nlb-resources-for-blue-green.md). + Service Connect: para obter mais informações, consulte [Recursos do Service Connect para implantações azul/verde, linear e canário do Amazon ECS](service-connect-blue-green.md). ## Procedimento Você pode usar o console ou a AWS CLI para criar um serviço de implantação linear do Amazon ECS. ------ #### [ Console ] 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Determine o recurso no qual você inicia o serviço. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/deploy-linear-service.html) A página **Criar serviço** é exibida. 1. Em **Detalhes do serviço**, faça o seguinte: 1. Em **Família de definições de tarefas**, escolha a definição de tarefa a ser usada. Em seguida, em **Revisão da definição de tarefa**, insira a revisão a ser usada. 1. Em **Service name** (Nome do serviço), insira um nome para o serviço. 1. Para executar o serviço em um cluster existente, em **Cluster existente**, escolha o cluster. Para executar o serviço em um novo cluster, escolha **Criar cluster** 1. Escolha como suas tarefas serão distribuídas em toda a infraestrutura do cluster. Expanda **Configuração de computação** e escolha sua opção. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/deploy-linear-service.html) 1. Em **Configuração de implantação**, faça o seguinte: 1. Em **Tipo de serviço**, escolha **Réplica**. 1. Em **Desired tasks** (Tarefas desejadas), insira o número de tarefas que serão iniciadas e mantidas no serviço. 1. Para que o Amazon ECS monitore a distribuição de tarefas entre as zonas de disponibilidade e as redistribua quando houver um desequilíbrio, em **Rebalanceamento do serviço em zonas de disponibilidade**, selecione **Rebalanceamento do serviço em zonas de disponibilidade**. 1. Em **Período de carência da verificação de integridade**, insira quanto tempo (em segundos) após o início de uma tarefa o agendador do serviço ignorará as verificações de integridade que forem não íntegras para o Elastic Load Balancing, o VPC Lattice e o contêiner. Se você não especificar um valor de período de tolerância de verificação de integridade, o valor padrão 0 será usado. 1. Em **Configuração da implantação**, defina as configurações de implantação linear: 1. Em **Estratégia de implantação**, escolha **Linear**. 1. Em **Porcentagem de incremento de tráfego**, informe a porcentagem de mudança de tráfego em cada incremento (por exemplo, 10% para mudar o tráfego em incrementos de 10%). 1. Em **Intervalo entre incrementos**, informe o tempo de espera em minutos entre cada incremento de mudança de tráfego. 1. Em **Tempo de incorporação**, informe o tempo em minutos em que as revisões de serviço azul e verde serão executadas simultaneamente após a mudança de tráfego final antes do encerramento da revisão azul. 1. (Opcional) Execute as funções do Lambda para serem executadas em estágios específicos da implantação. Em **Ganchos do ciclo de vida de implantação**, selecione os estágios para executar os ganchos do ciclo de vida. Para adicionar um gancho do ciclo de vida: 1. Escolha **Adicionar**. 1. Em **Função do Lambda**, insira o nome da função ou o ARN. 1. Em **Perfil** selecione o perfil do IAM que tem permissão para invocar a função do Lambda. 1. Em **Estágios do ciclo de vida**, selecione os estágios em que a função do Lambda deve ser executada. 1. Para configurar como o Amazon ECS detectará e lidará com falhas de implantação, expanda **Deployment failure detection**(Detecção de falhas de implantação) e escolha suas opções. 1. Para interromper uma implantação quando as tarefas não podem ser iniciadas, selecione **Use the Amazon ECS deployment circuit breaker)** (Usar o disjuntor de implantação do Amazon ECS. Para que o software reverta automaticamente a implantação para o último estado de implantação concluído quando o disjuntor de implantação definir a implantação para um estado de falha, selecione **Reverter em caso de falha**. 1. Para interromper uma implantação com base nas métricas da aplicação, selecione **Usar alarmes do CloudWatch**. Em seguida, em **Nomes de alarmes do CloudWatch**, escolha os alarmes. Para criar um alarme, acesse o console do CloudWatch. Para que o software reverta automaticamente a implantação para o último estado de implantação concluído quando um alarme do CloudWatch definir a implantação para um estado de falha, selecione **Reverter em caso de falha**. 1. (Opcional) Para interconectar o serviço usando o Service Connect, expanda **Service Connect** e especifique o seguinte: 1. Selecione **Ativar o Service Connect**. 1. Em **Service Connect configuration** (Configuração do Service Connect), especifique o modo cliente. + Se seu serviço executa uma aplicação cliente de rede que só precisa se conectar a outros serviços no namespace, escolha **Somente no lado do cliente**. + Se seu serviço executa uma aplicação de rede ou de serviço Web e precisa fornecer endpoints para esse serviço e se conectar a outros serviços no namespace, escolha **Client and server** (Cliente e servidor). 1. Para usar um namespace que não seja o namespace padrão do cluster, em **Namespace**, escolha o namespace do serviço. Isso pode ser um namespace criado separadamente na mesma Região da AWS em sua Conta da AWS ou um namespace na mesma região compartilhada com sua conta usando o AWS Resource Access Manager (AWS RAM). Para obter mais informações sobre namespaces compartilhados do AWS Cloud Map, consulte [Compartilhamento de namespaces do AWS Cloud Map entre contas](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) no *Guia do desenvolvedor do AWS Cloud Map*. 1. (Opcional) Configure regras de cabeçalho de tráfego de teste para implantações lineares. Em **Testar roteamento de tráfego**, especifique o seguinte: 1. Selecione **Habilitar regras de cabeçalho de tráfego de teste** para rotear solicitações específicas para a revisão do serviço verde durante o teste. 1. Em **Regras de correspondência de cabeçalhos**, configure os critérios para rotear o tráfego de teste: + **Nome do cabeçalho**: insira o nome do cabeçalho HTTP correspondente (por exemplo, `X-Test-Version` ou `User-Agent`). + **Tipo de correspondência**: escolha os critérios de correspondência: + **Correspondência exata**: roteie solicitações em que o valor do cabeçalho corresponda exatamente ao valor especificado + **Cabeçalho presente**: roteie solicitações que contenham o cabeçalho especificado, independentemente do valor + **Correspondência de padrões**: roteie solicitações em que o valor do cabeçalho corresponda a um padrão especificado + **Valor do cabeçalho** (se estiver usando correspondência exata ou correspondência de padrão): insira o valor ou padrão com o qual corresponder. Você pode adicionar várias regras de correspondência de cabeçalhos para criar uma lógica de roteamento complexa. As solicitações que correspondam a qualquer uma das regras configuradas serão encaminhadas para a revisão do serviço verde para testes. 1. Escolha **Adicionar regra de cabeçalho** para configurar condições adicionais de correspondência de cabeçalho. **nota** As regras de cabeçalho de tráfego de teste permitem que você valide a nova funcionalidade com tráfego controlado antes de concluir a implantação completa. Isso permite que você teste a revisão do serviço verde com solicitações específicas (como as de ferramentas de teste internas ou usuários beta) enquanto mantém o fluxo de tráfego normal para a revisão do serviço azul. 1. (Opcional) Especifique uma configuração de log. Selecione **Usar conjunto de logs**. A opção padrão envia os logs do contêiner ao CloudWatch Logs. As outras opções de driver de log são configuradas usando o AWS FireLens. Para obter mais informações, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md). Veja a seguir a descrição de cada destino de log de contêiner mais detalhadamente. + **Amazon CloudWatch**: configura a tarefa para enviar logs de contêiner ao CloudWatch Logs. São fornecidas as opções de driver de log padrão, que criam um grupo de logs do CloudWatch em seu nome. Para especificar um nome de grupo de logs diferente, altere os valores da opção de driver. + **Amazon Data Firehose**: configura a tarefa para enviar logs de contêiner ao Firehose. São fornecidas as opções de driver de log padrão, que enviam logs para um fluxo de entrega do Firehose. Para especificar um nome de fluxo de entrega diferente, altere os valores da opção de driver. + **Amazon Kinesis Data Streams**: configura a tarefa para enviar logs de contêiner ao Kinesis Data Streams. São fornecidas as opções de driver de log padrão, que enviam logs a um fluxo do Kinesis Data Streams. Para especificar um nome de transmissão diferente, altere os valores da opção de driver. + **Amazon OpenSearch Service**: configura a tarefa para enviar logs de contêiner a um domínio do OpenSearch Service. As opções de driver de log devem ser fornecidas. + **Amazon S3**: configura a tarefa para enviar logs de contêiner a um bucket do Amazon S3. As opções de driver de log padrão são fornecidas, mas você deve especificar um nome de bucket válido do Amazon S3. 1. (Opcional) Configure o **balanceamento de carga** para implantação linear. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/deploy-linear-service.html) 1. (Opcional) Para ajudar a identificar seu serviço e tarefas, expanda a seção **Tags** (Etiquetas) e configure suas etiquetas. Para que o Amazon ECS atribua tags automaticamente a todas as tarefas recém-iniciadas com o nome do cluster e as tags de definição de tarefa, selecione **Ativar tags gerenciadas pelo Amazon ECS** e, para **Propagar tags de**, escolha **Definições de tarefas**. Para que o Amazon ECS atribua tags automaticamente a todas as tarefas recém-iniciadas com o nome do cluster e as tags de serviços, selecione **Ativar tags gerenciadas pelo Amazon ECS** e, para **Propagar tags de**, escolha **Serviço**. Adicione ou remova uma tag. + [Adicionar uma etiqueta] Escolha **Add tag** (Adicionar etiqueta) e faça o seguinte: + Em **Chave**, insira o nome da chave. + Em **Valor** insira o valor da chave. + [Remover uma tag] Ao lado da tag, escolha **Remove tag (Remover tag)**. 1. Escolha **Criar**. ------ #### [ AWS CLI ] 1. Crie um arquivo chamado `linear-service-definition.json` com o conteúdo a seguir. Substitua os valores das *user-input* pelos seus. ``` { "serviceName": "myLinearService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "LINEAR", "maximumPercent": 200, "minimumHealthyPercent": 100, "linearConfiguration": { "stepPercentage": 10.0, "stepBakeTimeInMinutes":6 }, "bakeTimeInMinutes": 10, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true } }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-linear-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. Executar `create-service`. ``` aws ecs create-service --cli-input-json file://linear-service-definition.json ``` ------ ## Próximas etapas + Atualize o serviço para iniciar a implantação. Para obter mais informações, consulte [Atualizar um serviço do Amazon ECS](update-service-console-v2.md). + Monitore o processo de implantação para garantir que ele siga o padrão linear: + A revisão do serviço verde é criada e tem a escala aumentada verticalmente + O tráfego é deslocado de forma incremental em intervalos especificados + Cada incremento aguarda o intervalo especificado antes do próximo deslocamento + Depois que todo o tráfego é deslocado, o tempo de incorporação começa + Após o tempo de incorporação, a revisão azul é encerrada # Implantações canário do Amazon ECS As implantações canário primeiro direcionam uma pequena porcentagem do tráfego para a nova revisão para o teste inicial e, em seguida, transferem todo o tráfego restante de uma vez após a conclusão bem-sucedida da fase canário. Com as implantações canário do Amazon ECS, valide as novas revisões de serviços com tráfego de usuário real, minimizando a exposição ao risco. Essa abordagem fornece uma maneira controlada de implantar alterações com a capacidade de monitorar a performance e revertê-las rapidamente se forem detectados problemas. ## Recursos envolvidos em uma implantação canário Veja a seguir os recursos envolvidos nas implantações canário do Amazon ECS: + Mudança de tráfego: o processo que o Amazon ECS usa para transferir o tráfego de produção. Para implantações canárias do Amazon ECS, o tráfego é transferido em duas fases: primeiro para a porcentagem canário e, em seguida, para concluir a implantação. + Porcentagem canário: a porcentagem de tráfego roteado para a nova versão durante o período de avaliação. + Tempo de incorporação canário: a duração para monitorar a versão canário antes de prosseguir com a implantação completa. + Tempo de incorporação da implantação: o tempo, em minutos, que o Amazon ECS espera após transferir todo o tráfego de produção para a nova revisão de serviço, antes de encerrar a revisão antiga. Essa é a duração em que as revisões de serviço azul e verde são executadas simultaneamente após a mudança do tráfego de produção. + Estágios do ciclo de vida: uma série de eventos na operação de implantação, como “após a mudança no tráfego de produção”. + Gancho do ciclo de vida: uma função do Lambda que executa um estágio específico do ciclo de vida. Você pode criar uma função que verifica a implantação. + Grupo de destino: um recurso do Elastic Load Balancing usado para rotear solicitações para um ou mais destinos registrados (por exemplo, instâncias do EC2). Ao criar um listener, especifique um grupo de destino para a ação padrão dele. O tráfego é encaminhado para o grupo de destino especificado na regra do listener. + Receptor: um recurso do Elastic Load Balancing que verifica solicitações de conexão usando o protocolo e a porta que você configurou. As regras que você define para um receptor determinam como o Amazon ECS roteia solicitações para seus destinos registrados. + Regra: um recurso do Elastic Load Balancing associado a um receptor. Uma regra define como as solicitações são roteadas e consiste em uma ação, condição e prioridade. ## Considerações Considere o seguinte ao escolher um tipo de implantação: + Uso de recursos: as implantações canário executam conjuntos de tarefas originais e canário simultaneamente durante o período de avaliação, aumentando o uso de recursos. + Volume de tráfego: garanta que a porcentagem canário gere tráfego suficiente para uma validação significativa da nova versão. + Complexidade do monitoramento: as implantações canário exigem monitoramento e comparação de métricas entre duas versões diferentes simultaneamente. + Velocidade de reversão: as implantações canário permitem uma reversão rápida, transferindo o tráfego de volta para o conjunto de tarefas original. + Mitigação de riscos: as implantações canário oferecem excelente mitigação de riscos, limitando a exposição a uma pequena porcentagem de usuários. + Duração da implantação: as implantações canário incluem períodos de avaliação que estendem o tempo geral de implantação, mas oferecem oportunidades de validação. ## Como funcionam as implantações canário O processo de implantação canário do Amazon ECS segue uma abordagem estruturada com seis fases distintas que garantem atualizações seguras e confiáveis das aplicações. Cada fase tem um propósito específico na validação e transição da aplicação da versão atual (azul) para a nova versão (verde). 1. Fase de preparação: crie o ambiente verde junto com o ambiente azul existente. 1. Fase de implantação: implante a nova revisão do serviço no ambiente verde. O Amazon ECS lança novas tarefas usando a revisão atualizada do serviço, enquanto o ambiente azul continua atendendo ao tráfego de produção. 1. Fase de teste: valide o ambiente verde usando o roteamento de tráfego de teste. O Application Load Balancer direciona as solicitações de teste para o ambiente verde, enquanto o tráfego de produção permanece no azul. 1. Fase de mudança de tráfego canário: mude a porcentagem configurada de tráfego para a nova revisão de serviço verde durante a fase canário, seguida pela transferência de 100,0% do tráfego para a revisão de serviço verde 1. Fase de monitoramento: monitore a integridade da aplicação, as métricas de performance e os estados dos alarmes durante o tempo de incorporação. Uma operação de reversão é iniciada quando problemas são detectados. 1. Fase de conclusão: finalize a implantação encerrando o ambiente azul. A fase de mudança de tráfego canário segue estas etapas: + Inicial: a implantação começa com 100% do tráfego roteado para a revisão de serviço azul (atual). A revisão de serviço verde (nova) recebe tráfego de teste, mas nenhum tráfego de produção inicialmente. + Mudança de tráfego canário: essa é uma estratégia de mudança de tráfego em duas etapas. + Etapa 1: 10,0% para verde, 90,0% para azul + Etapa 2 :100,0% para verde, 0,0% para azul + Tempo de incorporação canário: aguarda uma duração configurável (tempo de incorporação canário) após a mudança de tráfego canário para permitir o monitoramento e a validação da performance da nova revisão com o aumento da carga de tráfego. + Ganchos do ciclo de vida: as funções do Lambda opcionais podem ser executadas em vários estágios do ciclo de vida durante a implantação para executar validação automatizada, monitoramento ou lógica personalizada. As funções do Lambda ou os ganchos do ciclo de vida configurados para PRODUCTION\$1TRAFFIC\$1SHIFT serão invocados em cada etapa de mudança de tráfego de produção. ### Estágios do ciclo de vida de implantação O processo de implantação canário percorre diferentes estágios do ciclo de vida, cada um com responsabilidades específicas e pontos de verificação de validação. A compreensão desses estágios ajuda você a monitorar o andamento da implantação e solucionar problemas de forma eficaz. Cada estágio do ciclo de vida pode durar até 24 horas e, além disso, cada etapa de mudança de tráfego em PRODUCTION\$1TRAFFIC\$1SHIFT pode durar até 24 horas. Recomendamos que o valor permaneça abaixo da marca de 24 horas. Isso ocorre porque os processos assíncronos precisam de tempo para acionar os ganchos. O sistema atinge o tempo limite, falha na implantação e, em seguida, inicia uma reversão após um estágio atingir 24 horas. As implantações CloudFormation têm restrições adicionais de tempo limite. Embora o limite de estágio de 24 horas permaneça em vigor, o CloudFormation impõe um limite de 36 horas em toda a implantação. A implantação do CloudFormation falha e, em seguida, iniciará uma reversão se o processo não for concluído em até 36 horas. **Estágios do ciclo de vida** | Estágios do ciclo de vida | Descrição | Suporte de gancho do ciclo de vida | | --- | --- | --- | | RECONCILE\$1SERVICE | Este estágio só acontece quando você inicia uma nova implantação de serviço com mais de uma revisão de serviço em um estado ACTIVE. | Sim | | PRE\$1SCALE\$1UP | A revisão do serviço verde ainda não foi iniciada. A revisão do serviço azul está processando 100% do tráfego de produção. Não há tráfego de teste. | Sim | | SCALE\$1UP | O momento em que a revisão do serviço verde aumenta a escala verticalmente até 100% e inicia novas tarefas. A revisão do serviço verde não está recebendo nenhum tráfego neste momento. | Não | | POST\$1SCALE\$1UP | A revisão do serviço verde foi iniciada. A revisão do serviço azul está processando 100% do tráfego de produção. Não há tráfego de teste. | Sim | | TEST\$1TRAFFIC\$1SHIFT | As revisões do serviço azul e verde estão em execução. A revisão do serviço azul processa 100% do tráfego de produção. A revisão do serviço verde está migrando de 0% para 100% do tráfego de teste. | Sim | | POST\$1TEST\$1TRAFFIC\$1SHIFT | A mudança de tráfego de teste foi concluída. A revisão do serviço verde processa 100% do tráfego de teste. | Sim | | PRODUCTION\$1TRAFFIC\$1SHIFT | O tráfego de produção canário é encaminhado para a revisão verde e o gancho do ciclo de vida é invocado com um tempo limite de 24 horas. A segunda etapa transfere o tráfego de produção restante para a revisão verde. | Sim | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | A mudança do tráfego de produção está concluída. | Sim | | BAKE\$1TIME | A duração em que as revisões de serviço azul e verde são executadas simultaneamente. | Não | | CLEAN\$1UP | A revisão do serviço azul teve a escala reduzida verticalmente por completo para 0 tarefa em execução. A revisão do serviço verde agora é a revisão do serviço de produção após esse estágio. | Não | ### Parâmetros de configuração As implantações canário exigem os seguintes parâmetros de configuração: + Porcentagem canário: a porcentagem de tráfego a ser roteada para a nova revisão de serviço durante a fase canário. Isso permite fazer testes com um subconjunto controlado do tráfego de produção. + Tempo de incorporação canário: o tempo de espera durante a fase canário antes de transferir o tráfego restante para a nova revisão de serviço. Isso possibilita um tempo para monitorar e validar a nova versão. ### Gerenciamento de tráfego As implantações canário usam grupos de destino do balanceador de carga para gerenciar a distribuição do tráfego: + Grupo de destino original: contém tarefas da versão estável atual e recebe a maior parte do tráfego. + Grupo de destino canário: contém tarefas da nova versão e recebe uma pequena porcentagem do tráfego para testes. + Roteamento ponderado: o balanceador de carga usa regras de roteamento ponderado para distribuir o tráfego entre os grupos de destino com base na porcentagem canário configurada. ### Monitoramento e validação As implantações canário eficazes dependem de um monitoramento abrangente: + Verificações de integridade: ambos os conjuntos de tarefas devem passar por verificações de integridade antes de receber tráfego. + Comparação de métricas: compare os principais indicadores de performance entre as versões original e canário, como tempo de resposta, taxa de erro e throughput. + Reversão automatizada: configure os alarmes do CloudWatch para acionar automaticamente a reversão se a versão canário mostrar performance degradada. + Validação manual: use o período de avaliação para revisar manualmente os logs, as métricas e o feedback do usuário antes de continuar. ### Práticas recomendadas para implantações canário Siga essas práticas recomendadas para garantir implantações canário bem-sucedidas com serviços. #### Escolher porcentagens de tráfego apropriadas Considere estes fatores ao selecionar as porcentagens de tráfego canário: + Comece aos poucos: comece com 5% a 10% do tráfego para minimizar o impacto caso ocorram problemas. + Considere a criticidade da aplicação: use porcentagens menores para aplicações de missão crítica e porcentagens maiores para serviços menos críticos. + Considere o volume de tráfego: garanta que a porcentagem canário gere tráfego suficiente para uma validação significativa. #### Definir períodos de avaliação apropriados Configure períodos de avaliação com base nestas considerações: + Reserve tempo suficiente: defina períodos de avaliação longos o suficiente para capturar dados de performance significativos, normalmente de 10 a 30 minutos. + Considere os padrões de tráfego: leve em conta os padrões de tráfego e os horários de pico de uso da aplicação. + Equilibre velocidade e segurança: períodos de avaliação mais longos fornecem mais dados, mas diminuem a velocidade da implantação. #### Implementar um monitoramento abrangente Configure o monitoramento para rastrear a performance da implantação canário: + Principais métricas: monitore o tempo de resposta, a taxa de erro, o throughput e a utilização de recursos para ambos os conjuntos de tarefas. + Reversão baseada em alarme: configure os alarmes do CloudWatch para acionar automaticamente a reversão quando as métricas excederem os limites. + Análise comparativa: configure painéis para comparar métricas entre as versões original e canário lado a lado. + Métricas de negócios: inclua métricas específicas de negócios, como taxas de conversão ou engajamento do usuário, em conjunto com métricas técnicas. #### Planejar estratégias de reversão Prepare-se para possíveis cenários de reversão com estas estratégias: + Reversão automática: configure acionadores automáticos de reversão com base em verificações de integridade e métricas de performance. + Procedimentos de reversão manual: documente procedimentos claros para reversão manual quando os acionadores automatizados não capturam todos os problemas. + Teste de reversão: teste regularmente os procedimentos de reversão para garantir que funcionem corretamente quando necessários. #### Validar completamente antes da implantação Garanta uma validação completa antes de prosseguir com as implantações canário: + Teste de pré-implantação: teste minuciosamente as mudanças nos ambientes de preparação antes da implantação canário. + Configuração da verificação de integridade: garanta que as verificações de integridade reflitam exatamente a prontidão e a funcionalidade da aplicação. + Validação de dependência: verifique se as novas versões são compatíveis com os serviços downstream e upstream. + Consistência de dados: garanta que as alterações de esquema do banco de dados e as migrações de dados sejam compatíveis com versões anteriores. #### Coordenar o envolvimento da equipe Garanta uma coordenação eficaz da equipe durante as implantações canário: + Janelas de implantação: programe implantações canário durante o horário comercial, quando as equipes estiverem disponíveis para monitorar e responder. + Canais de comunicação: estabeleça canais de comunicação claros para o status da implantação e o escalonamento de problemas. + Atribuições de perfis: defina perfis e responsabilidades para monitoramento, tomada de decisões e execução de reversão. # Recursos necessários para implantações canário do Amazon ECS Para usar uma implantação canário com mudança de tráfego gerenciada, seu serviço deve usar um dos seguintes recursos: + Elastic Load Balancing + Service Connect A lista abaixo fornece uma visão geral de alto nível do que você precisa configurar para implantações canário do Amazon ECS: + Seu serviço usa o Application Load Balancer, o Network Load Balancer ou o Service Connect. Configure os recursos apropriados. + Application Load Balancer: para obter mais informações, consulte [Recursos do Application Load Balancer para implantações azul/verde, linear e canário](alb-resources-for-blue-green.md). + Network Load Balancer: para obter mais informações, consulte [Recursos do Network Load Balancer para implantações azul/verde, lineares e canário do Amazon ECS](nlb-resources-for-blue-green.md). + Service Connect: para obter mais informações, consulte [Recursos do Service Connect para implantações azul/verde, linear e canário do Amazon ECS](service-connect-blue-green.md). + Defina o controlador de implantação do serviço para `ECS`. + Configure a estratégia de implantação como `canary` na sua definição de serviço. + Opcionalmente, configure parâmetros adicionais, como: + Tempo de incorporação para a nova implantação + A porcentagem de tráfego a ser roteada para a nova revisão de serviço durante a fase canário. + O tempo de espera durante a fase canário antes de transferir o tráfego restante para a nova revisão de serviço. + Alarmes do CloudWatch para reversão automática + Ganchos do ciclo de vida (são funções do Lambda que são executadas em estágios de implantação especificados) ## Práticas recomendadas Siga estas práticas recomendadas para implantações canário do Amazon ECS bem-sucedidas: + **Garanta que sua aplicação possa processar ambas as revisões de serviços em execução simultânea.** + **Planeje uma capacidade de cluster suficiente para processar ambas as revisões de serviços durante a implantação.** + **Teste seus procedimentos de reversão antes de implementá-los na produção.** + Configure as verificações de integridade apropriadas que reflitam com precisão a integridade da sua aplicação. + Defina um tempo de incorporação que permita testes suficientes da implantação verde. + Implemente alarmes do CloudWatch para detectar problemas automaticamente e acionar reversões. + Use ganchos do ciclo de vida para realizar testes automatizados em cada estágio da implantação. + Comece com pequenas porcentagens canário (5% a 10%) para minimizar o impacto se ocorrerem problemas. + Defina períodos de avaliação apropriados que permitam tempo suficiente para uma coleta de dados de performance significativa. + Implemente um monitoramento abrangente com os alarmes do CloudWatch para acionadores de reversão automatizados. + Configure verificações de integridade que reflitam exatamente a prontidão e a funcionalidade da sua aplicação. + Monitore métricas técnicas (tempo de resposta, taxa de erro) e métricas de negócios durante a avaliação. + Garanta que sua aplicação possa processar a divisão de tráfego sem problemas de sessão ou estado. + Planeje procedimentos de reversão e teste-os regularmente para garantir que funcionem quando necessários. + Programe implantações canário durante o horário comercial, quando as equipes puderem monitorar e responder. + Valide completamente as mudanças nos ambientes de preparação antes da implantação canário. + Documente procedimentos claros para intervenção manual e decisões de reversão. # Criar uma implantação canário do Amazon ECS Ao usar as implantações canário do Amazon ECS, você pode transferir uma pequena porcentagem do tráfego para sua nova revisão de serviço (a “canário”). Valide a implantação e, em seguida, transfira o tráfego restante de uma só vez após um intervalo especificado. Essa abordagem permite testar novas funcionalidades com risco mínimo antes da implantação completa. ## Pré-requisitos Execute as operações a seguir antes de iniciar uma implantação canário. 1. Configurar as permissões apropriadas. + Para obter informações sobre as permissões do Elastic Load Balancing, consulte [Perfil do IAM da infraestrutura do Amazon ECS para balanceadores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Para obter informações sobre as permissões do Lambda, consulte [Permissões necessárias para funções do Lambda em implantações azul/verde do Amazon ECS](blue-green-permissions.md). 1. As implantações canário do Amazon ECS exigem que o serviço use um dos recursos a seguir. Configure os recursos apropriados. + Application Load Balancer: para obter mais informações, consulte [Recursos do Application Load Balancer para implantações azul/verde, linear e canário](alb-resources-for-blue-green.md). + Network Load Balancer: para obter mais informações, consulte [Recursos do Network Load Balancer para implantações azul/verde, lineares e canário do Amazon ECS](nlb-resources-for-blue-green.md). + Service Connect: para obter mais informações, consulte [Recursos do Service Connect para implantações azul/verde, linear e canário do Amazon ECS](service-connect-blue-green.md). ## Procedimento Você pode usar o console ou a AWS CLI para criar um serviço de implantação canário do Amazon ECS. ------ #### [ Console ] 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Determine o recurso no qual você inicia o serviço. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/deploy-canary-service.html) A página **Criar serviço** é exibida. 1. Em **Detalhes do serviço**, faça o seguinte: 1. Em **Família de definições de tarefas**, escolha a definição de tarefa a ser usada. Em seguida, em **Revisão da definição de tarefa**, insira a revisão a ser usada. 1. Em **Service name** (Nome do serviço), insira um nome para o serviço. 1. Para executar o serviço em um cluster existente, em **Cluster existente**, escolha o cluster. Para executar o serviço em um novo cluster, escolha **Criar cluster** 1. Escolha como suas tarefas serão distribuídas em toda a infraestrutura do cluster. Expanda **Configuração de computação** e escolha sua opção. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/deploy-canary-service.html) 1. Em **Configuração de implantação**, faça o seguinte: 1. Em **Tipo de serviço**, escolha **Réplica**. 1. Em **Desired tasks** (Tarefas desejadas), insira o número de tarefas que serão iniciadas e mantidas no serviço. 1. Para que o Amazon ECS monitore a distribuição de tarefas entre as zonas de disponibilidade e as redistribua quando houver um desequilíbrio, em **Rebalanceamento do serviço em zonas de disponibilidade**, selecione **Rebalanceamento do serviço em zonas de disponibilidade**. 1. Em **Período de carência da verificação de integridade**, insira quanto tempo (em segundos) após o início de uma tarefa o agendador do serviço ignorará as verificações de integridade que forem não íntegras para o Elastic Load Balancing, o VPC Lattice e o contêiner. Se você não especificar um valor de período de tolerância de verificação de integridade, o valor padrão 0 será usado. 1. Em **Configuração da implantação**, defina as configurações de implantação canário: 1. Em **Estratégia de implantação**, escolha **Canário**. 1. Em **Porcentagem canário**, informe a porcentagem de tráfego a ser transferida para a revisão de serviço verde no primeiro estágio (por exemplo, 10% para o tráfego canário inicial). 1. Em **Tempo de incorporação canário**, informe o tempo de espera em minutos antes de transferir o tráfego restante para a revisão de serviço verde. 1. Em **Tempo de incorporação**, informe o tempo em minutos em que as revisões de serviço azul e verde serão executadas simultaneamente após a mudança de tráfego final antes do encerramento da revisão azul. 1. (Opcional) Execute as funções do Lambda para serem executadas em estágios específicos da implantação. Em **Ganchos do ciclo de vida de implantação**, selecione os estágios para executar os ganchos do ciclo de vida. Para adicionar um gancho do ciclo de vida: 1. Escolha **Adicionar**. 1. Em **Função do Lambda**, insira o nome da função ou o ARN. 1. Em **Perfil** selecione o perfil do IAM que tem permissão para invocar a função do Lambda. 1. Em **Estágios do ciclo de vida**, selecione os estágios em que a função do Lambda deve ser executada. 1. Para configurar como o Amazon ECS detectará e lidará com falhas de implantação, expanda **Deployment failure detection**(Detecção de falhas de implantação) e escolha suas opções. 1. Para interromper uma implantação quando as tarefas não podem ser iniciadas, selecione **Use the Amazon ECS deployment circuit breaker)** (Usar o disjuntor de implantação do Amazon ECS. Para que o software reverta automaticamente a implantação para o último estado de implantação concluído quando o disjuntor de implantação definir a implantação para um estado de falha, selecione **Reverter em caso de falha**. 1. Para interromper uma implantação com base nas métricas da aplicação, selecione **Usar alarmes do CloudWatch**. Em seguida, em **Nomes de alarmes do CloudWatch**, escolha os alarmes. Para criar um alarme, acesse o console do CloudWatch. Para que o software reverta automaticamente a implantação para o último estado de implantação concluído quando um alarme do CloudWatch definir a implantação para um estado de falha, selecione **Reverter em caso de falha**. 1. (Opcional) Para interconectar o serviço usando o Service Connect, expanda **Service Connect** e especifique o seguinte: 1. Selecione **Ativar o Service Connect**. 1. Em **Service Connect configuration** (Configuração do Service Connect), especifique o modo cliente. + Se seu serviço executa uma aplicação cliente de rede que só precisa se conectar a outros serviços no namespace, escolha **Somente no lado do cliente**. + Se seu serviço executa uma aplicação de rede ou de serviço Web e precisa fornecer endpoints para esse serviço e se conectar a outros serviços no namespace, escolha **Client and server** (Cliente e servidor). 1. Para usar um namespace que não seja o namespace padrão do cluster, em **Namespace**, escolha o namespace do serviço. Isso pode ser um namespace criado separadamente na mesma Região da AWS em sua Conta da AWS ou um namespace na mesma região compartilhada com sua conta usando o AWS Resource Access Manager (AWS RAM). Para obter mais informações sobre namespaces compartilhados do AWS Cloud Map, consulte [Compartilhamento de namespaces do AWS Cloud Map entre contas](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) no *Guia do desenvolvedor do AWS Cloud Map*. 1. (Opcional) Configure regras de cabeçalho de tráfego de teste para implantações canário. Em **Testar roteamento de tráfego**, especifique o seguinte: 1. Selecione **Habilitar regras de cabeçalho de tráfego de teste** para rotear solicitações específicas para a revisão do serviço verde durante o teste. 1. Em **Regras de correspondência de cabeçalhos**, configure os critérios para rotear o tráfego de teste: + **Nome do cabeçalho**: insira o nome do cabeçalho HTTP correspondente (por exemplo, `X-Test-Version` ou `User-Agent`). + **Tipo de correspondência**: escolha os critérios de correspondência: + **Correspondência exata**: roteie solicitações em que o valor do cabeçalho corresponda exatamente ao valor especificado + **Cabeçalho presente**: roteie solicitações que contenham o cabeçalho especificado, independentemente do valor + **Correspondência de padrões**: roteie solicitações em que o valor do cabeçalho corresponda a um padrão especificado + **Valor do cabeçalho** (se estiver usando correspondência exata ou correspondência de padrão): insira o valor ou padrão com o qual corresponder. Você pode adicionar várias regras de correspondência de cabeçalhos para criar uma lógica de roteamento complexa. As solicitações que correspondam a qualquer uma das regras configuradas serão encaminhadas para a revisão do serviço verde para testes. 1. Escolha **Adicionar regra de cabeçalho** para configurar condições adicionais de correspondência de cabeçalho. **nota** As regras de cabeçalho de tráfego de teste permitem que você valide a nova funcionalidade com tráfego controlado antes de concluir a implantação completa. Isso permite que você teste a revisão do serviço verde com solicitações específicas (como as de ferramentas de teste internas ou usuários beta) enquanto mantém o fluxo de tráfego normal para a revisão do serviço azul. 1. (Opcional) Especifique uma configuração de log. Selecione **Usar conjunto de logs**. A opção padrão envia os logs do contêiner ao CloudWatch Logs. As outras opções de driver de log são configuradas usando o AWS FireLens. Para obter mais informações, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md). Veja a seguir a descrição de cada destino de log de contêiner mais detalhadamente. + **Amazon CloudWatch**: configura a tarefa para enviar logs de contêiner ao CloudWatch Logs. São fornecidas as opções de driver de log padrão, que criam um grupo de logs do CloudWatch em seu nome. Para especificar um nome de grupo de logs diferente, altere os valores da opção de driver. + **Amazon Data Firehose**: configura a tarefa para enviar logs de contêiner ao Firehose. São fornecidas as opções de driver de log padrão, que enviam logs para um fluxo de entrega do Firehose. Para especificar um nome de fluxo de entrega diferente, altere os valores da opção de driver. + **Amazon Kinesis Data Streams**: configura a tarefa para enviar logs de contêiner ao Kinesis Data Streams. São fornecidas as opções de driver de log padrão, que enviam logs a um fluxo do Kinesis Data Streams. Para especificar um nome de transmissão diferente, altere os valores da opção de driver. + **Amazon OpenSearch Service**: configura a tarefa para enviar logs de contêiner a um domínio do OpenSearch Service. As opções de driver de log devem ser fornecidas. + **Amazon S3**: configura a tarefa para enviar logs de contêiner a um bucket do Amazon S3. As opções de driver de log padrão são fornecidas, mas você deve especificar um nome de bucket válido do Amazon S3. 1. (Opcional) Configure o **balanceamento de carga** para implantação canário. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/deploy-canary-service.html) 1. (Opcional) Para ajudar a identificar seu serviço e tarefas, expanda a seção **Tags** (Etiquetas) e configure suas etiquetas. Para que o Amazon ECS atribua tags automaticamente a todas as tarefas recém-iniciadas com o nome do cluster e as tags de definição de tarefa, selecione **Ativar tags gerenciadas pelo Amazon ECS** e, para **Propagar tags de**, escolha **Definições de tarefas**. Para que o Amazon ECS atribua tags automaticamente a todas as tarefas recém-iniciadas com o nome do cluster e as tags de serviços, selecione **Ativar tags gerenciadas pelo Amazon ECS** e, para **Propagar tags de**, escolha **Serviço**. Adicione ou remova uma tag. + [Adicionar uma etiqueta] Escolha **Add tag** (Adicionar etiqueta) e faça o seguinte: + Em **Chave**, insira o nome da chave. + Em **Valor** insira o valor da chave. + [Remover uma tag] Ao lado da tag, escolha **Remove tag (Remover tag)**. 1. Escolha **Criar**. ------ #### [ AWS CLI ] 1. Crie um arquivo chamado `canary-service-definition.json` com o conteúdo a seguir. Substitua os valores das *user-input* pelos seus. ``` { "serviceName": "myCanaryService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "CANARY", "maximumPercent": 200, "minimumHealthyPercent": 100, "canaryConfiguration" : { "canaryPercent" : 5.0, "canaryBakeTime" : 10 }, "bakeTimeInMinutes": 10, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true } }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-canary-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. Executar `create-service`. ``` aws ecs create-service --cli-input-json file://canary-service-definition.json ``` ------ ## Próximas etapas Depois de configurar sua implantação canário, conclua estas etapas: + Atualize o serviço para iniciar a implantação. Para obter mais informações, consulte [Atualizar um serviço do Amazon ECS](update-service-console-v2.md). + Monitore o processo de implantação para garantir que ele siga o padrão canário: + A revisão do serviço verde é criada e tem a escala aumentada verticalmente + Uma pequena porcentagem do tráfego (canário) é transferida para a revisão verde + O sistema aguarda o intervalo canário especificado + O tráfego restante é transferido de uma vez para a revisão verde + Após o tempo de incorporação, a revisão azul é encerrada ## Terminologia de implantação Os seguintes termos são utilizados em toda a documentação de implantação do Amazon ECS: Implantação azul/verde Uma estratégia de implantação que cria um novo ambiente (verde) junto com o ambiente existente (azul) e, em seguida, muda o tráfego de azul para verde após a validação. Implantação canário Uma estratégia de implantação que direciona uma pequena porcentagem do tráfego para uma nova versão, mantendo a maioria na versão estável para validação. Implantação linear Uma estratégia de implantação que transfere gradualmente o tráfego da versão antiga para a nova versão em incrementos iguais ao longo do tempo. Implantação incremental Uma estratégia de implantação que substitui instâncias da versão antiga por instâncias da nova versão, uma por vez. Conjunto de tarefas Uma coleção de tarefas que executam a mesma definição de tarefa em um serviço durante uma implantação. Grupo de destino Um agrupamento lógico de destinos que recebem tráfego de um balanceador de carga durante as implantações. Controlador de implantação O método usado para implantar novas versões do seu serviço, como Amazon ECS, CodeDeploy ou controladores externos. Reversão O processo de reverter para uma versão anterior da sua aplicação quando problemas são detectados durante a implantação. # Implantação de serviços do Amazon ECS usando um controlador de terceiros O tipo de implantação *externa* permite usar qualquer controlador de implantação de terceiros para ter controle total do processo de implantação em um serviço do Amazon ECS. Os detalhes do seu serviço são gerenciados por ações da API de gerenciamento de serviços (`CreateService`, `UpdateService` e `DeleteService`) ou ações da API de gerenciamento de conjuntos de tarefas (`CreateTaskSet`, `UpdateTaskSet`, `UpdateServicePrimaryTaskSet` e `DeleteTaskSet`). Cada ação de API gerencia um subconjunto dos parâmetros de definição de serviço. A ação de API `UpdateService` atualiza os parâmetros de contagem desejada e período de carência da verificação de integridade para um serviço. Se for necessário atualizar a opção de computação, a versão da plataforma, os detalhes do balanceador de carga, a configuração de rede ou definição de tarefa, você deverá criar um novo conjunto de tarefas. A ação de API `UpdateTaskSet` atualiza apenas o parâmetro de escala para um conjunto de tarefas. A ação de API `UpdateServicePrimaryTaskSet` modifica qual conjunto de tarefas em um serviço é o conjunto de tarefas principal. Quando você chama a ação de API `DescribeServices`, ela retorna todos os campos especificados para um conjunto de tarefas principal. Se o conjunto de tarefas principal de um serviço for atualizado, qualquer valor de parâmetro de conjunto de tarefas existente no novo conjunto de tarefas principal que for diferente do conjunto de tarefas principal antigo em um serviço será atualizado para o novo valor quando um novo conjunto de tarefas principal for definido. Se nenhum conjunto de tarefas principal for definido para um serviço, durante a descrição do serviço, os campos do conjunto de tarefas serão nulos. ## Considerações sobre a implantação externa Considere o seguinte ao usar o tipo de implantação externa: + Os tipos de load balancer compatíveis são um Application Load Balancer ou um Network Load Balancer. + Os tipos de controlador de implantação do Fargate ou `EXTERNAL` não são compatíveis com a estratégia de programação `DAEMON`. + A integração do Application AutoScaling com o Amazon ECS é compatível apenas com o serviço do Amazon ECS como destino. A dimensão escalável compatível com o Amazon ECS é `ecs:service:DesiredCount`: a contagem de tarefas de um serviço do Amazon ECS. Não há integração direta entre o Application AutoScaling e os conjuntos de tarefas do Amazon ECS. Os conjuntos de tarefas do Amazon ECS calculam a `ComputedDesiredCount` com base no serviço `DesiredCount` do Amazon ECS. ## Fluxo de trabalho de implantações externas Veja a seguir o fluxo de trabalho básico para gerenciar uma implantação externa no Amazon ECS. **Para gerenciar um serviço do Amazon ECS usando um controlador de implantação externa** 1. Crie um serviço do Amazon ECS. O único parâmetro obrigatório é o nome do serviço. É possível especificar os parâmetros a seguir ao criar um serviço usando um controlador de implantação externo. Todos os outros parâmetros de serviço são especificados durante a criação de um conjunto de tarefas no serviço. `serviceName` Tipo: String Exigido: sim O nome do serviço. São permitidos até 255 letras (caixa alta e baixa), números, hífens e sublinhados. Os nomes dos serviços devem ser exclusivos em um cluster, mas é possível ter serviços com nomes semelhantes em vários clusters em uma ou várias regiões. `desiredCount` O número de instanciações da definição de tarefa do conjunto de tarefas especificado para posicionar e manter em execução no serviço. `deploymentConfiguration` Parâmetros opcionais de implantação que controlam quantas tarefas são executadas durante uma implantação e a ordem de interrupção e início de tarefas. `tags` Tipo: matriz de objetos Obrigatório: não Os metadados que você aplica ao serviço para ajudá-lo a categorizá-los e organizá-los. Cada tag consiste de uma chave e um valor opcional, que podem ser definidos. Quando um serviço é excluído, as tags também são excluídas. Um máximo de 50 tags podem ser aplicadas ao serviço. Para obter mais informações, consulte [Marcação de recursos do Amazon ECS](ecs-using-tags.md). Quando você atualiza um serviço, esse parâmetro não aciona uma nova implantação de serviço. `key` Tipo: string Restrições de tamanho: tamanho mínimo 1. O comprimento máximo é 128. Obrigatório: não Uma parte de um par de chave/valor que compõe uma tag. Uma chave é um rótulo geral que age como uma categoria para valores de tag mais específicos. `value` Tipo: string Restrições de tamanho: o tamanho mínimo é 0. O comprimento máximo é 256. Obrigatório: não A parte opcional de um par de chave/valor que compõe uma tag. Um valor atua como um descritor dentro de uma categoria de tag (chave). `enableECSManagedTags` Especifica se devem ser usadas as tags gerenciadas do Amazon ECS para as tarefas no serviço. Para obter mais informações, consulte [Usar etiquetas para faturamento](ecs-using-tags.md#tag-resources-for-billing). `propagateTags` Tipo: Sequência Valores válidos: `TASK_DEFINITION` \$1 `SERVICE` Obrigatório: não Especifica se deve copiar as tags da definição de tarefa ou do serviço para as tarefas no serviço. Se nenhum valor for especificado, as tags não serão copiadas. As tags só podem ser copiadas para tarefas no serviço durante a criação do serviço. Para adicionar etiquetas a uma tarefa após a criação do serviço ou da tarefa, use a ação de API `TagResource`. Quando você atualiza um serviço, esse parâmetro não aciona uma nova implantação de serviço. `schedulingStrategy` A estratégia de programação para usar. Os serviços que usam um controlador de implantação externo oferecem suporte apenas à estratégia de programação de `REPLICA`. `placementConstraints` Um array de objetos de restrição de posicionamento para usar em tarefas no serviço. É possível especificar um máximo de 10 restrições por tarefa. Esse limite inclui restrições na definição de tarefa e naquelas especificadas no runtime. Se você estiver usando o Fargate, não haverá suporte para restrições de posicionamento de tarefa. `placementStrategy` A estratégia de posicionamento de objetos para usar em tarefas no serviço. É possível especificar um máximo de quatro regras de estratégia por serviço. Veja a seguir uma definição de serviço de exemplo para a criação de um serviço usando um controlador de implantação externo. ``` { "cluster": "", "serviceName": "", "desiredCount": 0, "role": "", "deploymentConfiguration": { "maximumPercent": 0, "minimumHealthyPercent": 0 }, "placementConstraints": [ { "type": "distinctInstance", "expression": "" } ], "placementStrategy": [ { "type": "binpack", "field": "" } ], "schedulingStrategy": "REPLICA", "deploymentController": { "type": "EXTERNAL" }, "tags": [ { "key": "", "value": "" } ], "enableECSManagedTags": true, "propagateTags": "TASK_DEFINITION" } ``` 1. Crie um conjunto de tarefas inicial. O conjunto de tarefas contém os seguintes detalhes sobre o serviço: `taskDefinition` A definição de tarefa para as tarefas do conjunto de tarefas usarem. `launchType` Tipo: string Valores válidos: `EC2` \$1 `FARGATE` \$1 `EXTERNAL` Obrigatório: não O tipo de inicialização na qual executar seu serviço. Se não for especificado um tipo de inicialização, o padrão `capacityProviderStrategy` será usado. Quando você atualiza um serviço, esse parâmetro aciona uma nova implantação de serviço. Se um `launchType` for especificado, o parâmetro `capacityProviderStrategy` deverá ser omitido. `platformVersion` Tipo: string Obrigatório: não A versão da plataforma na qual suas tarefas no serviço estão em execução. Uma versão da plataforma é especificada apenas para tarefas que usam o tipo de inicialização do Fargate. Se não for especificada, a versão mais recente (`LATEST`) será usada como padrão. Quando você atualiza um serviço, esse parâmetro aciona uma nova implantação de serviço. As versões da plataforma do AWS Fargate são usadas para fazer referência a um ambiente de runtime específico para a infraestrutura de tarefas do Fargate. Ao especificar a versão da plataforma `LATEST` quando estiver executando uma tarefa ou criando um serviço, você obtém a versão de plataforma mais atual disponível para suas tarefas. Ao escalar seu serviço, essas tarefas recebem a versão de plataforma especificada na implantação atual do serviço. Para obter mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md). Versões de plataforma não são especificadas para tarefas que usam o tipo de inicialização do EC2. `loadBalancers` Um objeto do load balancer que representa o load balancer para uso no serviço. Quando for usado um controlador de implantação externa, somente Application Load Balancers e Network Load Balancers são compatíveis. Se você estiver usando um Application Load Balancer, somente um grupo de destino do Application Load Balancer será permitido por conjunto de tarefas. O trecho a seguir mostra o exemplo de um objeto `loadBalancer` a ser usado. ``` "loadBalancers": [ { "targetGroupArn": "", "containerName": "", "containerPort": 0 } ] ``` Ao especificar um objeto `loadBalancer`, é necessário especificar um `targetGroupArn` e omitir os parâmetros `loadBalancerName`. `networkConfiguration` A configuração de rede para o serviço. Esse parâmetro é necessário para definições de tarefa que usam o modo de rede `awsvpc` para receber sua própria interface de rede elástica, e não tem suporte para outros modos de rede. Para obter mais informações sobre redes para o Fargate, consulte [Opções de redes de tarefas do Amazon ECS para o Fargate](fargate-task-networking.md). `serviceRegistries` Os detalhes dos registros de descoberta de serviços a serem atribuídos ao serviço. Para obter mais informações, consulte [Uso da descoberta de serviços para conectar serviços do Amazon ECS com nomes DNS](service-discovery.md). `scale` Uma porcentagem de ponto flutuante do número desejado de tarefas para posicionar e manter em execução no conjunto de tarefas. O valor é especificado como uma porcentagem total de de um serviço `desiredCount`. Os valores aceitos são números entre 0 e 100. Veja a seguir um exemplo de JSON para criar um conjunto de tarefas para um controlador de implantação externo. ``` { "service": "", "cluster": "", "externalId": "", "taskDefinition": "", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "" ], "securityGroups": [ "" ], "assignPublicIp": "DISABLED" } }, "loadBalancers": [ { "targetGroupArn": "", "containerName": "", "containerPort": 0 } ], "serviceRegistries": [ { "registryArn": "", "port": 0, "containerName": "", "containerPort": 0 } ], "launchType": "EC2", "capacityProviderStrategy": [ { "capacityProvider": "", "weight": 0, "base": 0 } ], "platformVersion": "", "scale": { "value": null, "unit": "PERCENT" }, "clientToken": "" } ``` 1. Quando forem necessárias alterações no serviço, use a ação de API `UpdateService`, `UpdateTaskSet` ou `CreateTaskSet`, dependendo de quais parâmetros você estiver atualizando. Se você tiver criado um conjunto de tarefas, use o parâmetro `scale` para cada tarefa em um serviço para determinar quantas tarefas devem ser mantidas em execução no serviço. Por exemplo, se você tiver um serviço que contenha `tasksetA` e criar um `tasksetB`, poderá testar a validade de `tasksetB` antes de querer fazer a transição do tráfego de produção para ele. Seria possível definir `scale` para os dois conjuntos de tarefas como `100`, e quando estivesse pronto para fazer a transição de todo o tráfego de produção para `tasksetB`, poderia atualizar `scale` para `tasksetA` como `0` para reduzi-lo. # Implantações azul/verde do CodeDeploy para o Amazon ECS Recomendamos que você use a implantação azul/verde do Amazon ECS. Para obter mais informações, consulte [Criação de implantações azul/verde do Amazon ECS](deploy-blue-green-service.md). O tipo de implantação *azul/verde* usa o modelo de implantação azul/verde controlado pelo CodeDeploy. Use este tipo de implantação para verificar uma nova implantação de um serviço antes de enviar tráfego de produção para ele. Para obter mais informações, consulte [O que é o CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) no *Guia do usuário do AWS CodeDeploy*. Valide o estado de um serviço do Amazon ECS antes da implantação Existem três maneiras pelas quais o tráfego pode mudar durante uma implantação azul/verde: + **Canário**: o tráfego é deslocado em dois incrementos. É possível escolher entre opções de canary predefinidas que especificam a porcentagem de tráfego deslocada para a definição da tarefa atualizada no primeiro incremento e o intervalo, em minutos, antes que o tráfego restante seja deslocado no segundo incremento. + **Linear**: o tráfego é deslocado em incrementos iguais com um número igual de minutos entre cada incremento. É possível escolher entre opções lineares predefinidas que especificam a porcentagem de tráfego deslocado em cada incremento e o número de minutos entre cada incremento. + **Tudo de uma vez**: todo o tráfego é deslocado do conjunto de tarefas original para o conjunto de tarefas atualizado de uma só vez. Veja a seguir os componentes do CodeDeploy que o Amazon ECS usa quando um serviço utiliza o tipo de implantação azul/verde: **Aplicação CodeDeploy** Uma coleção de recursos do CodeDeploy. Isso consiste em um ou mais grupos de implantação. **Grupo de implantação do CodeDeploy** As configurações de implantação. Isso consiste no seguinte: + Cluster e serviço do Amazon ECS + Informações sobre o grupo de destino e o receptor do balanceador de carga + Estratégia de reversão de implantação + Configurações de reencaminhamento de tráfego + Configurações de encerramento da revisão original + Configuração de implantação + Configuração de alarmes do CloudWatch que pode ser definida para interromper implantações + Configurações do SNS ou do CloudWatch Events para notificações Para obter mais informações, consulte [Trabalhar com grupos de implantação](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) no *Guia do usuário do AWS CodeDeploy*. **Configuração de implantação do CodeDeploy** Especifica como o CodeDeploy roteia o tráfego de produção para o conjunto de tarefas de substituição durante uma implantação. As configurações de implantação linear e de canary predefinidas a seguir estão disponíveis. Também é possível criar implantações personalizadas lineares e de canary. Para obter mais informações, consulte [Trabalhar com configurações de implantação](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) no *Guia do usuário do AWS CodeDeploy*. + **CodeDeployDefault.ECSAllAtOnce**: desloca todo o tráfego para o contêiner atualizado do Amazon ECS de uma só vez + **CodeDeployDefault.ECSLinear10PercentEvery1Minutes**: desloca 10% do tráfego a cada minuto até que todo o tráfego seja deslocado. + **CodeDeployDefault.ECSLinear10PercentEvery3Minutes**: desloca 10% do tráfego a cada 3 minutos até que todo o tráfego seja deslocado. + **CodeDeployDefault.ECSCanary10Percent5Minutes**: desloca 10% do tráfego no primeiro incremento. Os 90 por cento restantes serão implantados cinco minutos depois. + **CodeDeployDefault.ECSCanary10Percent15Minutes**: desloca 10% do tráfego no primeiro incremento. Os 90 por cento restantes são implantados 15 minutos depois. **Revisão** Uma revisão é o arquivo de especificação de aplicação do CodeDeploy (arquivo AppSpec). No arquivo AppSpec, você especifica o ARN completo da definição da tarefa e o contêiner e a porta do conjunto de tarefas de substituição em que o tráfego deve ser roteado quando uma nova implantação é criada. O nome do contêiner deve ser um dos nomes de contêineres referenciados em sua definição de tarefa. Se a configuração de rede ou a versão da plataforma tiver sido atualizada na definição de serviço, você também deverá especificar esses detalhes no arquivo AppSpec. Também é possível especificar as funções do Lambda a serem executadas durante os eventos do ciclo de vida da implantação. As funções do Lambda permitem que você execute testes e retorne métricas durante a implantação. Para obter mais informações, consulte [Referência do arquivo AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html) no *Guia do usuário do AWS CodeDeploy*. ## Considerações Considere o seguinte ao usar o tipo de implantação azul/verde: + Quando um serviço do Amazon ECS que usa o tipo de implantação azul/verde é criado inicialmente, é criado um conjunto de tarefas do Amazon ECS. + Você deve configurar o serviço para usar um Application Load Balancer ou um Network Load Balancer. A seguir estão os requisitos do load balancer. + Você deve adicionar um listener de produção ao load balancer, que é usado para rotear o tráfego de produção. + Um listener de teste opcional pode ser adicionado ao load balancer, que é usado para rotear o tráfego de teste. Se você especificar um listener de teste, o CodeDeploy encaminhará o tráfego de teste para o conjunto de tarefas de substituição durante uma implantação. + Os listeners de produção e teste devem pertencer ao mesmo load balancer. + É necessário definir um grupo de destino para o load balancer. O grupo de destino roteia o tráfego para o conjunto de tarefas original em um serviço por meio do listener de produção. + Quando um Network Load Balancer é usado, somente a configuração de implantação `CodeDeployDefault.ECSAllAtOnce` é permitida. + Para serviços configurados para usar autoescalabilidade de serviço e o tipo de implantação azul/verde, a autoescalabilidade não é bloqueada durante uma implantação, mas a implantação pode apresentar falha em algumas circunstâncias. Veja a seguir a descrição desse comportamento, com mais detalhes. + Se um serviço estiver sendo dimensionado e uma implantação for iniciada, será criado o conjunto de tarefas verde e o CodeDeploy aguardará por até uma hora até que o conjunto de tarefas verde atinja o estado estacionário e não mude qualquer tráfego até que isso aconteça. + Se um serviço estiver no processo de implantação azul/verde e ocorrer um evento de escalabilidade, o tráfego continuará a mudar por 5 minutos. Se o serviço não atingir o estado estacionário em até 5 minutos, o CodeDeploy interromperá a implantação e a marcará como falha. + As tarefas que usam os tipos de controlador de implantação do Fargate ou `CODE_DEPLOY` não são compatíveis com a estratégia de programação `DAEMON`. + Ao criar inicialmente uma aplicação e um grupo de implantação do CodeDeploy, é necessário especificar o seguinte: + É necessário definir dois grupos de destino para o load balancer. Um grupo de destino deverá ser o grupo de destino inicial definido para o balanceador de carga quando o serviço do Amazon ECS for criado. O único requisito do segundo grupo de destino é que ele não pode ser associado a um load balancer diferente do que é usado pelo serviço. + Quando você cria uma implantação do CodeDeploy para um serviço do Amazon ECS, o CodeDeploy cria um *conjunto de tarefas de substituição* (ou *conjunto de tarefas verde*) na implantação. Se você tiver adicionado um listener de teste ao balanceador de carga, o CodeDeploy encaminhará o tráfego de teste para o conjunto de tarefas de substituição. É nesse momento que você pode executar quaisquer testes de validação. O CodeDeploy redireciona o tráfego de produção do conjunto de tarefas original para o conjunto de tarefas de substituição, de acordo com as configurações de redirecionamento de tráfego do grupo de implantação. ## Permissões obrigatórias do IAM As implantações azul/verde podem ser realizadas usando uma combinação das APIs do Amazon ECS e do CodeDeploy. Os usuários devem ter as permissões apropriadas para esses serviços antes de poderem usar as implantações azuis/verdes do Amazon ECS no Console de gerenciamento da AWS ou com a AWS CLI ou os SDKs. Além das permissões padrão do IAM para criar e atualizar serviços, o Amazon ECS exige as permissões a seguir. Essas permissões foram adicionadas à política `AmazonECS_FullAccess` do IAM. Para obter mais informações, consulte [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess). + `codedeploy:CreateApplication` + `codedeploy:CreateDeployment` + `codedeploy:CreateDeploymentGroup` + `codedeploy:GetApplication` + `codedeploy:GetDeployment` + `codedeploy:GetDeploymentGroup` + `codedeploy:ListApplications` + `codedeploy:ListDeploymentGroups` + `codedeploy:ListDeployments` + `codedeploy:StopDeployment` + `codedeploy:GetDeploymentTarget` + `codedeploy:ListDeploymentTargets` + `codedeploy:GetDeploymentConfig` + `codedeploy:GetApplicationRevision` + `codedeploy:RegisterApplicationRevision` + `codedeploy:BatchGetApplicationRevisions` + `codedeploy:BatchGetDeploymentGroups` + `codedeploy:BatchGetDeployments` + `codedeploy:BatchGetApplications` + `codedeploy:ListApplicationRevisions` + `codedeploy:ListDeploymentConfigs` + `codedeploy:ContinueDeployment` + `sns:ListTopics` + `cloudwatch:DescribeAlarms` + `lambda:ListFunctions` **nota** Além das permissões padrão do Amazon ECS necessárias para executar tarefas e serviços, os usuários do IAM também precisam de permissões `iam:PassRole` para usar perfis do IAM para tarefas. O CodeDeploy precisa de permissões para chamar APIs do Amazon ECS, modificar o Elastic Load Balancing, invocar funções do Lambda e descrever alarmes do CloudWatch, além de permissões para modificar a contagem desejada do serviço para você. Antes de criar um serviço do Amazon ECS que use o tipo de implantação azul/verde, você deve criar uma função do IAM (`ecsCodeDeployRole`). Para obter mais informações, consulte [Função do IAM para CodeDeploy do Amazon ECS](codedeploy_IAM_role.md). # Migrar implantações azul/verde do CodeDeploy para implantações azul/verde do Amazon ECS As implantações azul/verde do CodeDeploy e do Amazon ECS oferecem funcionalidades semelhantes, mas diferem na forma como você as configura e gerencia. ## Visão geral da implantação azul/verde do CodeDeploy Ao criar um serviço do Amazon ECS usando o CodeDeploy, você: 1. Crie um balanceador de carga com um receptor de produção e (opcionalmente) um receptor de teste. Cada receptor é configurado com uma única regra (padrão) que roteia todo o tráfego para um único grupo de destino (o grupo de destino principal). 1. Crie um serviço do Amazon ECS, configurado para usar o receptor e o grupo de destino, com o tipo `deploymentController` definido como `CODE_DEPLOY`. A criação do serviço resulta na criação de um conjunto de tarefas (azul) registrado com o grupo de destino especificado. 1. Crie um grupo de implantação do CodeDeploy (como parte de uma aplicação do CodeDeploy) e configure-o com detalhes do cluster do Amazon ECS, nome do serviço, receptores do balanceador de carga, dois grupos de destino (o grupo de destino principal usado na regra de receptor de produção e um grupo de destino secundário a ser usado para tarefas de substituição), um perfil de serviço (para conceder permissões ao CodeDeploy para manipular o Amazon ECS e recursos do Elastic Load Balancing) e vários parâmetros que controlam o comportamento da implantação. Com o CodeDeploy, novas versões de um serviço são implantadas usando `CreateDeployment()`, especificando o nome da aplicação do CodeDeploy, o nome do grupo de implantação e um arquivo AppSpec que fornece detalhes da nova revisão e dos ganchos opcionais do ciclo de vida. A implantação do CodeDeploy cria um conjunto de tarefas de substituição (verde) e registra suas tarefas no grupo de destino secundário. Quando isso se torna íntegro, está disponível para teste (opcional) e para produção. Em ambos os casos, o redirecionamento é obtido alterando a respectiva regra do receptor para apontar para o grupo de destino secundário associado ao conjunto de tarefas verde. A reversão é obtida alterando a regra do receptor de produção de volta para o grupo de destino principal. ## Visão geral da implantação azul/verde do Amazon ECS Com implantações azul/verde do Amazon ECS, a configuração de implantação é parte do próprio serviço do Amazon ECS: 1. Você deve pré-configurar o receptor de produção do balanceador de carga com uma regra que inclua dois grupos de destino com pesos de 1 e 0. 1. Você precisa especificar os seguintes recursos, ou atualizar os recursos do serviço: + O ARN dessa regra de receptor + Os dois grupos de destino + Um perfil do IAM para conceder permissão ao Amazon ECS para chamar as APIs do Elastic Load Balancing + Um perfil opcional do IAM para executar funções do Lambda + Defina o tipo `deploymentController` como `ECS` e `deploymentConfiguration.strategy` para `BLUE_GREEN`. Isso resulta na criação de uma implantação de serviço (azul) cujas tarefas são registradas no grupo de destino principal. Com o Amazon ECS azul/verde, uma nova revisão de serviço é criada chamando `UpdateService()` do Amazon ECS, passando os detalhes da nova revisão. A implantação do serviço cria novas tarefas de revisão do serviço (verde) e as registra no grupo de destino secundário. O Amazon ECS processa as operações de redirecionamento e reversão mudando os pesos na regra do receptor. ## Principais diferenças de implementação Embora ambas as abordagens resultem na criação de um conjunto inicial de tarefas, a implementação subjacente difere: + O CodeDeploy usa um conjunto de tarefas, enquanto o Amazon ECS usa uma revisão de serviço. Os conjuntos de tarefas do Amazon ECS são uma construção mais antiga que foi substituída pelas revisões e implantações de serviços do Amazon ECS. Esse último oferece maior visibilidade do processo de implantação, bem como do histórico de implantação e revisão do serviço. + Com o CodeDeploy, os ganchos do ciclo de vida são especificados como parte do arquivo AppSpec fornecido a `CreateDeployment()`. Isso significa que os ganchos podem ser alterados de uma implantação para outra. Com o Amazon ECS azul/verde, os ganchos são especificados como parte da configuração do serviço, e qualquer atualização exigiria uma chamada `UpdateService()`. + Tanto o CodeDeploy quanto o Amazon ECS azul/verde usam o Lambda para implementação de ganchos, mas as entradas e saídas esperadas são diferentes. Com o CodeDeploy, a função deve chamar `PutLifecycleEventHookExecutionStatus()` para retornar o status do gancho, que pode ser `SUCCEEDED` ou `FAILED`. Com o Amazon ECS, a resposta do Lambda é usada para indicar o status do gancho. + O CodeDeploy invoca cada gancho como uma chamada única, e espera que o status final da execução seja retornado em até uma hora. Os ganchos do Amazon ECS são mais flexíveis, pois podem retornar um indicador `IN_PROGRESS`, o que sinaliza que o gancho deve ser invocado de novo repetidamente até que resulte em `SUCCEEDED` ou `FAILED`. Para obter mais informações, consulte [Ganchos do ciclo de vida para implantações de serviços do Amazon ECS](deployment-lifecycle-hooks.md). ## Abordagens de migração Há três abordagens principais para migrar das implantações azul/verde do CodeDeploy para as implantações azul/verde do Amazon ECS. Cada abordagem tem características diferentes em termos de complexidade, risco, capacidade de reversão e possível tempo de inatividade. ### Reutilizar os mesmos recursos do Elastic Load Balancing usados para o CodeDeploy Você atualiza o serviço existente do Amazon ECS para usar o controlador de implantação do Amazon ECS com a estratégia de implantação azul/verde em vez do controlador de implantação do CodeDeploy. Ao usar essa abordagem, considere o seguinte: + O procedimento de migração é mais simples porque você está atualizando o controlador de implantação de serviços e a estratégia de implantação existentes do Amazon ECS. + Não há tempo de inatividade quando configurado e migrado corretamente. + Uma reversão exige que você reverta a revisão do serviço. + O risco é alto porque não há uma configuração azul/verde paralela. Você usa o mesmo receptor de balanceador de carga e grupos de destino usados para o CodeDeploy. Se você estiver usando CloudFormation, consulte [Migração de um modelo de implantação azul/verde do CodeDeploy para CloudFormation para um modelo azul/verde do Amazon ECS para CloudFormation](migrate-codedeploy-to-ecs-bluegreen-cloudformation-template.md). 1. Modifique a regra padrão dos receptores de produção/teste para incluir o grupo de destino alternativo, e defina o peso do grupo de destino principal como 1 e o do grupo de destino alternativo como 0. Para o CodeDeploy, os receptores do balanceador de carga anexado ao serviço são configurados com uma única regra (padrão) que roteia todo o tráfego para um único grupo de destino. Para o Amazon ECS azul/verde, os receptores do balanceador de carga devem ser pré-configurados com uma regra que inclua os dois grupos de destino com pesos. O grupo de destino primário deve receber peso 1 e o grupo de destino alternativo deve receber peso 0. 1. Atualize o serviço existente do Amazon ECS chamando a API `UpdateService` e definindo o parâmetro `deploymentController` como `ECS` e o parâmetro `deploymentStrategy` como `BLUE_GREEN`. Especifique os ARNs do grupo de destino, do grupo de destino alternativo, do receptor de produção e de um receptor de teste opcional. 1. Verifique se o serviço funciona conforme o esperado. 1. Exclua a configuração do CodeDeploy para esse serviço do Amazon ECS, pois agora você está usando o Amazon ECS azul/verde. ### Novo serviço com um balanceador de carga existente Essa abordagem usa a estratégia azul/verde para a migração. Ao usar essa abordagem, considere o seguinte: + A interrupção é mínima. Ela ocorre somente durante a troca de portas do Elastic Load Balancing. + Uma reversão exige que você reverta a troca de portas do Elastic Load Balancing. + O risco é baixo porque há configurações paralelas. Portanto, você pode testar antes da mudança de tráfego. 1. Deixe os receptores, os grupos de destino e o serviço do Amazon ECS para a configuração do CodeDeploy intactos para que você possa facilmente reverter para essa configuração, se necessário. 1. Crie novos grupos de destino e novos receptores (com portas diferentes dos receptores originais) no balanceador de carga existente. Em seguida, crie um novo serviço do Amazon ECS que corresponda ao serviço existente do Amazon ECS, exceto que você usa o `ECS` como controlador de implantação, `BLUE_GREEN` como estratégia de implantação e passa os ARNs para os novos grupos de destino e as novas regras de receptores. 1. Verifique a nova configuração enviando manualmente o tráfego HTTP para o serviço. Se tudo correr bem, troque as portas dos receptores originais e dos novos receptores para rotear o tráfego para a nova configuração. 1. Verifique a nova configuração e, se tudo continuar funcionando conforme o esperado, exclua a configuração do CodeDeploy. ### Novo serviço com um balanceador de carga Como na abordagem anterior, essa abordagem usa a estratégia azul/verde para a migração. A principal diferença é que a mudança da configuração do CodeDeploy para a configuração azul/verde do Amazon ECS ocorre em uma camada de proxy reverso acima do balanceador de carga. Exemplos de implementações para a camada de proxy reverso são o Route 53 e o CloudFront. Essa abordagem é adequada para clientes que já têm essa camada de proxy reverso e se toda a comunicação com o serviço estiver acontecendo por meio dela (por exemplo, nenhuma comunicação direta no nível do balanceador de carga). Ao usar essa abordagem, considere o seguinte: + Isso requer uma camada de proxy reverso. + O procedimento de migração é mais complexo porque você precisa atualizar o controlador de implantação de serviços e a estratégia de implantação existentes do Amazon ECS. + A interrupção é mínima. Ela ocorre somente durante a troca de portas do Elastic Load Balancing. + Uma reversão exige que você reverta as alterações na configuração do proxy. + O risco é baixo porque há configurações paralelas. Portanto, você pode testar antes da mudança de tráfego. 1. Não modifique a configuração existente do CodeDeploy intacta (balanceador de carga, receptores, grupos de destino, serviço do Amazon ECS e grupo de implantação do CodeDeploy). 1. Crie um novo balanceador de carga, grupos de destino e receptores configurados para implantações azul/verde do Amazon ECS. Configure os recursos apropriados. + Application Load Balancer: para obter mais informações, consulte [Recursos do Application Load Balancer para implantações azul/verde, linear e canário](alb-resources-for-blue-green.md). + Network Load Balancer: para obter mais informações, consulte [Recursos do Network Load Balancer para implantações azul/verde, lineares e canário do Amazon ECS](nlb-resources-for-blue-green.md). 1. Crie um novo serviço com o `ECS` como controlador de implantação e `BLUE_GREEN` como estratégia de implantação, apontando para os novos recursos do balanceador de carga. 1. Verifique a nova configuração testando-a por meio do novo balanceador de carga. 1. Atualize a configuração do proxy reverso para rotear o tráfego para o novo balanceador de carga. 1. Observe a nova revisão do serviço e, se tudo continuar funcionando conforme o esperado, exclua a configuração do CodeDeploy. ## Próximas etapas Depois de migrar para implantações azul/verde do Amazon ECS: + Atualize seus scripts de implantação e pipelines de CI/CD para usar a API `UpdateService` do Amazon ECS em vez da API `CreateDeployment` do CodeDeploy. + Atualize seu monitoramento e alertas para rastrear as implantações do serviço do Amazon ECS em vez das implantações do CodeDeploy. + Considere implementar testes automatizados do seu novo processo de implantação para garantir que ele funcione conforme o esperado. # Migração de uma implantação de serviço azul/verde do CodeDeploy para uma do Amazon ECS Ao usar implantações azul/verde do Amazon ECS, você pode fazer e testar alterações no serviço antes de implementá-las em um ambiente de produção. Você deve criar novos ganchos do ciclo de vida para a implantação azul/verde do Amazon ECS. ## Pré-requisitos Execute as operações a seguir antes de iniciar uma implantação azul/verde. 1. Substitua o perfil do IAM do CodeDeploy para Amazon ECS pelas seguintes permissões. + Para obter informações sobre as permissões do Elastic Load Balancing, consulte [Perfil do IAM da infraestrutura do Amazon ECS para balanceadores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Para obter informações sobre as permissões do Lambda, consulte [Permissões necessárias para funções do Lambda em implantações azul/verde do Amazon ECS](blue-green-permissions.md). 1. Desative a automação do CodeDeploy. Para obter mais informações, consulte [Working with deployment groups in CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) no *Guia do usuário do CodeDeploy*. 1. Certifique-se de ter as informações a seguir da sua implantação azul/verde do CodeDeploy. Você pode reutilizar essas informações para a implantação azul/verde do Amazon ECS: + O grupo de destino de produção + O receptor de produção + A regra de produção + O grupo de destino de teste Este é o grupo de destino para a revisão do serviço verde. 1. Certifique-se de que seus grupos de destino do Application Load Balancer estejam associados adequadamente às regras de receptor: + Se você não estiver usando receptores de teste, os dois grupos de destino (produção e teste) devem ser associados às regras de receptores de produção. + Se você estiver usando receptores de teste, um grupo de destino deve estar vinculado às regras de receptores de produção, e o outro grupo de destino deve estar vinculado às regras de receptores de teste. Se esse requisito não for atendido, a implantação do serviço falhará com o seguinte erro: `Service deployment rolled back because of invalid networking configuration. Both targetGroup and alternateTargetGroup must be associated with the productionListenerRule or testListenerRule.` 1. Verifique se não há implantações de serviço em andamento para o serviço. Para obter mais informações, consulte [Visualize o histórico de serviços usando implantações de serviços do Amazon ECS](service-deployment.md). 1. As implantações azul/verde do Amazon ECS exigem que seu serviço use um dos recursos a seguir. Configure os recursos apropriados. + Application Load Balancer: para obter mais informações, consulte [Recursos do Application Load Balancer para implantações azul/verde, linear e canário](alb-resources-for-blue-green.md). + Network Load Balancer: para obter mais informações, consulte [Recursos do Network Load Balancer para implantações azul/verde, lineares e canário do Amazon ECS](nlb-resources-for-blue-green.md). + Service Connect: para obter mais informações, consulte [Recursos do Service Connect para implantações azul/verde, linear e canário do Amazon ECS](service-connect-blue-green.md). 1. Decida se você deseja executar funções do Lambda para os estágios do ciclo de vida na implantação azul/verde do Amazon ECS. + Antes de aumentar a escala verticalmente + Depois de aumentar a escala verticalmente + Mudança do tráfego de teste + Depois da mudança do tráfego de teste + Mudança do tráfego de produção + Depois da mudança do tráfego de produção Crie funções do Lambda para cada estágio do ciclo de vida. Para obter mais informações, consulte [Criar uma função do Lambda com o console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) no *Guia do desenvolvedor do AWS Lambda*. Para obter mais informações sobre como atualizar o controlador de implantação de um serviço, consulte [Atualizar parâmetros de serviço do Amazon ECS](update-service-parameters.md). ## Procedimento 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. A página de detalhes do cluster é exibida. 1. Na guia **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. No banner, escolha **Atualizar tipo de controlador de implantação**. A página **Migrar tipo de controlador de implantação** é exibida. 1. Expanda **Novo** e especifique os parâmetros a seguir. 1. Em **Tipo de controlador de implantação**, escolha **ECS**. 1. Em **Estratégia de implantação**, escolha **Azul/verde**. 1. Em **Tempo de incorporação**, insira o tempo em que as revisões de serviço azul e verde são executadas. 1. Para executar funções do Lambda em um estágio do ciclo de vida, em **Ganchos do ciclo de vida de implantação**, faça o seguinte para cada função exclusiva do Lambda: 1. Escolha **Adicionar**. Repita o procedimento para cada função exclusiva que você deseja executar. 1. Em **Função do Lambda**, insira o nome da função. 1. Em **Perfil**, escolha o perfil que você criou nos pré-requisitos com as permissões azul/verde. Para obter mais informações, consulte [Permissões necessárias para funções do Lambda em implantações azul/verde do Amazon ECS](blue-green-permissions.md). 1. Em **Estágios do ciclo de vida**, selecione os estágios que a função do Lambda executa. 1. (Opcional) Em **Detalhes do gancho**, insira um par de chave/valor que forneça informações sobre o gancho. 1. Expanda o **Balanceamento de carga** e configure o seguinte: 1. Em **Perfil**, escolha o perfil que você criou nos pré-requisitos com as permissões azul/verde. Para obter mais informações, consulte [Permissões necessárias para funções do Lambda em implantações azul/verde do Amazon ECS](blue-green-permissions.md). 1. Em **Receptor**, escolha o receptor de produção da sua implantação azul/verde do CodeDeploy. 1. Em **Regra de produção**, escolha a regra de produção da sua implantação azul/verde do CodeDeploy. 1. Em **Regra de teste**, escolha a regra de teste da sua implantação azul/verde do CodeDeploy. 1. Em **Grupo de destino**, escolha o grupo de destino de produção em sua implantação azul/verde do CodeDeploy. 1. Em **Grupo de destino alternativo**, escolha o grupo de destino de teste da sua implantação azul/verde do CodeDeploy. 1. Selecione **Atualizar**. ## Próximas etapas + Atualize o serviço para iniciar a implantação. Para obter mais informações, consulte [Atualizar um serviço do Amazon ECS](update-service-console-v2.md). + Monitore o processo de implantação para garantir que ele siga o padrão azul/verde: + A revisão do serviço verde é criada e tem a escala aumentada verticalmente + O tráfego de teste é roteado para a revisão verde (se configurado) + O tráfego de produção é mudado para a revisão verde + Após o tempo de incorporação, a revisão azul é encerrada # Migração de um modelo de implantação azul/verde do CodeDeploy para CloudFormation para um modelo azul/verde do Amazon ECS para CloudFormation Migre um modelo do CloudFormation que usa implantações azul/verde do CodeDeploy para serviços do Amazon ECS para um que use a estratégia de implantação azul/verde nativa do Amazon ECS. A migração segue a abordagem “Reutilize os mesmos recursos do Elastic Load Balancing usados para o CodeDeploy”. Para obter mais informações, consulte [Migrar implantações azul/verde do CodeDeploy para implantações azul/verde do Amazon ECS](migrate-codedeploy-to-ecs-bluegreen.md). ## Modelo de origem Este modelo usa a transformação `AWS::CodeDeployBlueGreen` e o gancho `AWS::CodeDeploy::BlueGreen` para implementar implantações azul/verde para um serviço do Amazon ECS. ### Origem Este é o modelo completo do CloudFormation usando a implantação azul/verde do CodeDeploy. Para obter mais informações, consulte [Exemplo de modelo de implantação azul/verde](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green-template-example.html#blue-green-template-example.json) no *Guia do usuário do AWS CloudFormation*: ``` { "AWSTemplateFormatVersion": "2010-09-09", "Parameters": { "Vpc": { "Type": "AWS::EC2::VPC::Id" }, "Subnet1": { "Type": "AWS::EC2::Subnet::Id" }, "Subnet2": { "Type": "AWS::EC2::Subnet::Id" } }, "Transform": [ "AWS::CodeDeployBlueGreen" ], "Hooks": { "CodeDeployBlueGreenHook": { "Type": "AWS::CodeDeploy::BlueGreen", "Properties": { "TrafficRoutingConfig": { "Type": "TimeBasedCanary", "TimeBasedCanary": { "StepPercentage": 15, "BakeTimeMins": 5 } }, "Applications": [ { "Target": { "Type": "AWS::ECS::Service", "LogicalID": "ECSDemoService" }, "ECSAttributes": { "TaskDefinitions": [ "BlueTaskDefinition", "GreenTaskDefinition" ], "TaskSets": [ "BlueTaskSet", "GreenTaskSet" ], "TrafficRouting": { "ProdTrafficRoute": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "LogicalID": "ALBListenerProdTraffic" }, "TargetGroups": [ "ALBTargetGroupBlue", "ALBTargetGroupGreen" ] } } } ] } } }, "Resources": { "ExampleSecurityGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Security group for ec2 access", "VpcId": {"Ref": "Vpc"}, "SecurityGroupIngress": [ { "IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 8080, "ToPort": 8080, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 22, "ToPort": 22, "CidrIp": "0.0.0.0/0" } ] } }, "ALBTargetGroupBlue": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ALBTargetGroupGreen": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ExampleALB": { "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer", "Properties": { "Scheme": "internet-facing", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ], "Tags": [ { "Key": "Group", "Value": "Example" } ], "Type": "application", "IpAddressType": "ipv4" } }, "ALBListenerProdTraffic": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "Properties": { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 } ] } } ], "LoadBalancerArn": {"Ref": "ExampleALB"}, "Port": 80, "Protocol": "HTTP" } }, "ALBListenerProdRule": { "Type": "AWS::ElasticLoadBalancingV2::ListenerRule", "Properties": { "Actions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 } ] } } ], "Conditions": [ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": [ "Mozilla" ] } } ], "ListenerArn": {"Ref": "ALBListenerProdTraffic"}, "Priority": 1 } }, "ECSTaskExecutionRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy" ] } }, "BlueTaskDefinition": { "Type": "AWS::ECS::TaskDefinition", "Properties": { "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]}, "ContainerDefinitions": [ { "Name": "DemoApp", "Image": "nginxdemos/hello:latest", "Essential": true, "PortMappings": [ { "HostPort": 80, "Protocol": "tcp", "ContainerPort": 80 } ] } ], "RequiresCompatibilities": [ "FARGATE" ], "NetworkMode": "awsvpc", "Cpu": "256", "Memory": "512", "Family": "ecs-demo" } }, "ECSDemoCluster": { "Type": "AWS::ECS::Cluster", "Properties": {} }, "ECSDemoService": { "Type": "AWS::ECS::Service", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "DesiredCount": 1, "DeploymentController": { "Type": "EXTERNAL" } } }, "BlueTaskSet": { "Type": "AWS::ECS::TaskSet", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "LaunchType": "FARGATE", "NetworkConfiguration": { "AwsVpcConfiguration": { "AssignPublicIp": "ENABLED", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ] } }, "PlatformVersion": "1.4.0", "Scale": { "Unit": "PERCENT", "Value": 100 }, "Service": {"Ref": "ECSDemoService"}, "TaskDefinition": {"Ref": "BlueTaskDefinition"}, "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"} } ] } }, "PrimaryTaskSet": { "Type": "AWS::ECS::PrimaryTaskSet", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "Service": {"Ref": "ECSDemoService"}, "TaskSetId": {"Fn::GetAtt": ["BlueTaskSet", "Id"]} } } } } ``` ## Etapas da migração ### Remover recursos específicos do CodeDeploy Você não precisa mais das seguintes propriedades: + A transformação `AWS::CodeDeployBlueGreen` + O gancho `CodeDeployBlueGreenHook` + Os recursos `GreenTaskDefinition` e `GreenTaskSet` (estes serão gerenciados pelo Amazon ECS) + O recurso `PrimaryTaskSet` (o Amazon ECS gerenciará conjuntos de tarefas internamente) ### Reconfigurar o receptor do balanceador de carga Modifique o recurso `ALBListenerProdTraffic` para usar uma ação de encaminhamento com dois grupos de destino: ``` { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ] } ``` ### Atualizar as propriedades da implantação Atualize e adicione o seguinte: + Altere a propriedade `DeploymentController` de `EXTERNAL` para `ECS`. + Adicione a propriedade `Strategy` e defina-a como BLUE\$1GREEN. + Adicione a propriedade `BakeTimeInMinutes`. ``` { "DeploymentConfiguration": { "MaximumPercent": 200, "MinimumHealthyPercent": 100, "DeploymentCircuitBreaker": { "Enable": true, "Rollback": true }, "BakeTimeInMinutes": 5, "Strategy": "BLUE_GREEN" } } ``` + Adicione a configuração do balanceador de carga ao serviço: ``` { "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "AdvancedConfiguration": { "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "ProductionListenerRule": {"Ref": "ALBListenerProdRule"}, "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]} } } ] } ``` + Adicione a referência de definição de tarefa ao serviço: ``` { "TaskDefinition": {"Ref": "BlueTaskDefinition"} } ``` ### Criar o perfil AmazonECSInfrastructureRolePolicyForLoadBalancers Adicione um novo perfil do IAM que permita ao Amazon ECS gerenciar recursos do balanceador de carga. Para obter mais informações, consulte . [Perfil do IAM da infraestrutura do Amazon ECS para balanceadores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) ## Testes de recomendações 1. Implante o modelo migrado em um ambiente de não produção. 1. Verifique se o serviço é implantado corretamente com a configuração inicial. 1. Teste uma implantação atualizando a definição da tarefa e observando o processo de implantação azul/verde. 1. Verifique se o tráfego muda corretamente entre as implantações azul e verde. 1. Teste a funcionalidade de reversão forçando uma falha na implantação. ## Modelo após a migração ### Modelo final Este é o modelo completo do CloudFormation usando uma implantação azul/verde do Amazon ECS: ``` { "AWSTemplateFormatVersion": "2010-09-09", "Parameters": { "Vpc": { "Type": "AWS::EC2::VPC::Id" }, "Subnet1": { "Type": "AWS::EC2::Subnet::Id" }, "Subnet2": { "Type": "AWS::EC2::Subnet::Id" } }, "Resources": { "ExampleSecurityGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Security group for ec2 access", "VpcId": {"Ref": "Vpc"}, "SecurityGroupIngress": [ { "IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 8080, "ToPort": 8080, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 22, "ToPort": 22, "CidrIp": "0.0.0.0/0" } ] } }, "ALBTargetGroupBlue": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ALBTargetGroupGreen": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ExampleALB": { "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer", "Properties": { "Scheme": "internet-facing", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ], "Tags": [ { "Key": "Group", "Value": "Example" } ], "Type": "application", "IpAddressType": "ipv4" } }, "ALBListenerProdTraffic": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "Properties": { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ], "LoadBalancerArn": {"Ref": "ExampleALB"}, "Port": 80, "Protocol": "HTTP" } }, "ALBListenerProdRule": { "Type": "AWS::ElasticLoadBalancingV2::ListenerRule", "Properties": { "Actions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ], "Conditions": [ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": [ "Mozilla" ] } } ], "ListenerArn": {"Ref": "ALBListenerProdTraffic"}, "Priority": 1 } }, "ECSTaskExecutionRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy" ] } }, "ECSInfrastructureRoleForLoadBalancers": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccessToECSForInfrastructureManagement", "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/AmazonECSInfrastructureRolePolicyForLoadBalancers" ] } }, "BlueTaskDefinition": { "Type": "AWS::ECS::TaskDefinition", "Properties": { "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]}, "ContainerDefinitions": [ { "Name": "DemoApp", "Image": "nginxdemos/hello:latest", "Essential": true, "PortMappings": [ { "HostPort": 80, "Protocol": "tcp", "ContainerPort": 80 } ] } ], "RequiresCompatibilities": [ "FARGATE" ], "NetworkMode": "awsvpc", "Cpu": "256", "Memory": "512", "Family": "ecs-demo" } }, "ECSDemoCluster": { "Type": "AWS::ECS::Cluster", "Properties": {} }, "ECSDemoService": { "Type": "AWS::ECS::Service", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "DesiredCount": 1, "DeploymentController": { "Type": "ECS" }, "DeploymentConfiguration": { "MaximumPercent": 200, "MinimumHealthyPercent": 100, "DeploymentCircuitBreaker": { "Enable": true, "Rollback": true }, "BakeTimeInMinutes": 5, "Strategy": "BLUE_GREEN" }, "NetworkConfiguration": { "AwsvpcConfiguration": { "AssignPublicIp": "ENABLED", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ] } }, "LaunchType": "FARGATE", "PlatformVersion": "1.4.0", "TaskDefinition": {"Ref": "BlueTaskDefinition"}, "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "AdvancedConfiguration": { "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "ProductionListenerRule": {"Ref": "ALBListenerProdRule"}, "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]} } } ] } } } } ``` # Migração de uma implantação azul/verde do CodeDeploy para uma implantação de serviço de atualização contínua do Amazon ECS Você pode migrar suas implantações de serviço de uma implantação azul/verde do CodeDeploy para uma implantação de atualização contínua do Amazon ECS. Isso permite que você migre da dependência do CodeDeploy para uma implantação integrada. O agendador de serviços do Amazon ECS substitui as tarefas em execução no momento por novas tarefas. O número de tarefas que o Amazon ECS adiciona ou remove do serviço durante uma atualização contínua é controlado pela configuração de implantação do serviço. ## Pré-requisitos Execute as operações a seguir antes de iniciar uma implantação azul/verde. 1. Você não precisa mais do perfil do IAM do CodeDeploy para o Amazon ECS. 1. Desative a automação do CodeDeploy. Para obter mais informações, consulte [Working with deployment groups in CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) no *Guia do usuário do CodeDeploy*. 1. Verifique se não há implantações de serviço em andamento para o serviço. Para obter mais informações, consulte [Visualize o histórico de serviços usando implantações de serviços do Amazon ECS](service-deployment.md). Para obter mais informações sobre como atualizar o controlador de implantação de um serviço, consulte [Atualizar parâmetros de serviço do Amazon ECS](update-service-parameters.md). ## Procedimento 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. A página de detalhes do cluster é exibida. 1. Na guia **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. No banner, escolha **Migrar**. A página **Atualizar configuração de implantação** é exibida. 1. Expanda **Opções de implantação** e especifique os parâmetros a seguir. 1. Em **Tipo de controlador de implantação**, escolha **ECS**. 1. Em **Estratégia de implantação**, escolha **Atualização contínua**. 1. Em **Min running tasks** (Mínimo de tarefas em execução), insira o limite inferior do número de tarefas do serviço que devem permanecer no estado `RUNNING` durante uma implantação, como uma porcentagem do número desejado de tarefas (arredondado para o número inteiro superior mais próximo). Para obter mais informações, consulte [Configuração da implantação](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration). 1. Em **Max running tasks** (Máximo de tarefas em execução), insira o limite superior do número de tarefas do serviço que devem permanecer no estado `RUNNING` ou `PENDING` durante uma implantação, como uma porcentagem do número desejado de tarefas (arredondado para o número inteiro inferior mais próximo). 1. Expanda o **Balanceamento de carga** e configure o seguinte: 1. Em **Perfil**, escolha o perfil que você criou nos pré-requisitos com as permissões azul/verde. Para obter mais informações, consulte [Permissões necessárias para funções do Lambda em implantações azul/verde do Amazon ECS](blue-green-permissions.md). 1. Em **Receptor**, escolha o receptor de produção da sua implantação azul/verde do CodeDeploy. 1. Em **Grupo de destino**, escolha o grupo de destino de produção em sua implantação azul/verde do CodeDeploy. 1. Selecione **Atualizar**. ## Próximas etapas É necessário atualizar o serviço para que a alteração tenha efeito. Para obter mais informações, consulte [Atualizar um serviço do Amazon ECS](update-service-console-v2.md). # Atualizar a estratégia de implantação do Amazon ECS O Amazon ECS é compatível com várias estratégias de implantação para atualizar seus serviços. Você pode migrar entre essas estratégias com base nos requisitos da aplicação. Este tópico explica como migrar entre implantações contínuas e implantações azul/verde. ## Compreensão das estratégias de implantação do Amazon ECS Antes de migrar entre as estratégias de implantação, é importante entender como cada estratégia funciona e suas principais diferenças: **Implantações contínuas** Em uma implantação contínua, o Amazon ECS substitui a versão atual em execução da sua aplicação por uma nova versão. O agendador de serviços usa os parâmetros de porcentagem mínima e máxima de integridade para determinar a estratégia de implantação. As implantações contínuas são mais simples de configurar, mas oferecem menos controle sobre o processo de implantação e o roteamento do tráfego. **Implantações azuis/verdes** Em uma implantação azul/verde, o Amazon ECS cria uma nova versão do seu serviço (verde) junto com a versão existente (azul). Isso permite que você verifique a nova versão antes de rotear o tráfego de produção para ela. As implantações azul/verde fornecem mais controle sobre o processo de implantação, incluindo recursos de mudança de tráfego, testes e reversão. ## Práticas recomendadas Siga estas práticas recomendadas ao migrar entre estratégias de implantação: + **Teste em um ambiente que não seja de produção**: sempre teste a atualização em um ambiente de não produção antes de aplicar as alterações nos serviços de produção. + **Plano de reversão**: tenha um plano de reversão caso a atualização não funcione conforme o esperado. + **Monitore durante a transição**: monitore de perto seu serviço durante e após a migração para garantir que ele continue operando corretamente. + **Atualize a documentação**: atualize sua documentação de implantação para refletir a nova estratégia de implantação. + **Considere o impacto do tráfego**: entenda como a atualização pode afetar o tráfego do seu serviço e planeje adequadamente. # Atualização da estratégia de implantação da atualização contínua para o Amazon ECS azul/verde Você pode migrar de uma implantação de atualização contínua para uma implantação azul/verde do Amazon ECS quando quiser fazer e testar alterações no serviço antes de implementá-las em um ambiente de produção. ## Pré-requisitos Antes de migrar seu serviço de implantações contínuas para azul/verde, verifique se você tem o seguinte: + Aguarde a conclusão de todas as implantações atuais. + Um serviço existente do Amazon ECS usando a estratégia de implantação contínua. + Se você tiver várias revisões de serviço entregando tráfego, o Amazon ECS tentará consolidar o tráfego em uma única revisão durante a migração. Se isso falhar, poderá ser necessário atualizar manualmente o serviço para usar uma única revisão antes de migrar. + Configurar as permissões apropriadas. + Para obter informações sobre as permissões do Elastic Load Balancing, consulte [Perfil do IAM da infraestrutura do Amazon ECS para balanceadores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). + Para obter informações sobre as permissões do Lambda, consulte [Permissões necessárias para funções do Lambda em implantações azul/verde do Amazon ECS](blue-green-permissions.md). + Dependendo da configuração, você deve executar uma das seguintes opções: + Se seu serviço usa o Elastic Load Balancing, atualize-o com a nova “advancedConfiguration” e inicie uma implantação contínua. + Se seu serviço usa o Service Connect, atualize-o e inicie uma implantação contínua. + Se o seu serviço tanto o Elastic Load Balancing como o Service Connect, execute as duas etapas acima (você pode usar uma única solicitação UpdateService). + Se o seu serviço não usar nenhuma das opções acima, nenhuma operação adicional será necessária. + As implantações azul/verde do Amazon ECS exigem que seu serviço use um dos recursos a seguir. Configure os recursos apropriados. + Application Load Balancer: para obter mais informações, consulte [Recursos do Application Load Balancer para implantações azul/verde, linear e canário](alb-resources-for-blue-green.md). + Network Load Balancer: para obter mais informações, consulte [Recursos do Network Load Balancer para implantações azul/verde, lineares e canário do Amazon ECS](nlb-resources-for-blue-green.md). + Service Connect: para obter mais informações, consulte [Recursos do Service Connect para implantações azul/verde, linear e canário do Amazon ECS](service-connect-blue-green.md). ## Procedimento 1. Abra o console do Amazon ECS em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. No painel de navegação, escolha **Clusters**. 1. Na página **Clusters**, escolha o cluster que contém o serviço que você deseja migrar. A página de detalhes do cluster será exibida. 1. Na página **Detalhes do cluster**, escolha a guia **Serviços**. 1. Escolha o serviço e depois **Atualizar**. A página Atualizar serviço é exibida 1. Expanda **Opções de implantação** e especifique o seguinte: 1. Em **Estratégia de implantação**, escolha **Azul/verde**. 1. Defina as configurações da implantação azul/verde: 1. Em **Tempo de incorporação**, insira o número de minutos em que as revisões do serviço azul e do verde serão executadas simultaneamente antes que a revisão azul seja encerrada. Isso possibilita um tempo para a verificação e testes. 1. (Opcional) Configure as funções do Lambda para serem executadas em estágios específicos da implantação. Em **Ganchos do ciclo de vida de implantação**, configure as funções do Lambda para os seguintes estágios: + **Pré-aumento vertical da escala**: é executado antes do aumento vertical da escala da revisão do serviço verde + **Pós-aumento vertical da escala**: é executado após do aumento vertical da escala da revisão do serviço verde + **Teste de mudança de tráfego**: é executado durante o roteamento de tráfego de teste para a revisão do serviço verde + **Mudança de tráfego pós-teste**: é executado após o tráfego de teste ser roteado para a revisão do serviço verde + **Mudança de tráfego de produção**: é executada durante o roteamento do tráfego de produção para a revisão do serviço verde + **Mudança de tráfego pós-produção**: é executada após o tráfego de produção ser roteado para a revisão do serviço verde Para adicionar um gancho do ciclo de vida: 1. Escolha **Adicionar**. 1. Em **Função do Lambda**, insira o nome da função ou o ARN. 1. Em **Perfil**, escolha o perfil do IAM que tem permissão para invocar a função do Lambda. 1. Em **Estágios do ciclo de vida**, selecione os estágios em que a função do Lambda deve ser executada. 1. Opcional: em **Detalhes do gancho**, insira pares de chave/valor para fornecer informações adicionais ao gancho. 1. Defina as configurações do balanceador de carga: 1. Em **Balanceamento de carga**, verifique se o serviço está configurado para usar um balanceador de carga. 1. Em **Grupo de destino**, escolha o grupo de destino principal para seu ambiente de produção (azul). 1. Em **Grupo de destino alternativo**, escolha o grupo de destino para seu ambiente de teste (verde). 1. Em **Regra de receptor de produção**, escolha a regra de receptor para rotear o tráfego de produção. 1. Opcional: em **Testar regra de receptor**, escolha uma regra de receptor para rotear o tráfego de teste para seu ambiente verde. 1. Em **Perfil**, escolha o perfil do IAM que permite que o Amazon ECS gerencie seu balanceador de carga. 1. Reveja as alterações da configuração e escolha **Atualizar**. ## Próximas etapas + Atualize o serviço para iniciar a implantação. Para obter mais informações, consulte [Atualizar um serviço do Amazon ECS](update-service-console-v2.md). + Monitore o processo de implantação para garantir que ele siga o padrão azul/verde: + A revisão do serviço verde é criada e tem a escala aumentada verticalmente + O tráfego de teste é roteado para a revisão verde (se configurado) + O tráfego de produção é mudado para a revisão verde + Após o tempo de incorporação, a revisão azul é encerrada # Atualização da estratégia de implantação azul/verde do Amazon ECS para a atualização contínua É possível migrar uma implantação azul/verde para uma implantação de atualização contínua. Ao migrar para implantações contínuas, tenha em mente as seguintes considerações: + **Processamento de tráfego**: com implantações contínuas, novas tarefas começam a receber tráfego assim que passam pelas verificações de integridade. Não há uma fase de teste separada, como nas implantações azul/verde. + **Eficiência de recursos**: as implantações contínuas normalmente usam menos recursos do que as implantações azul/verde porque substituem as tarefas de forma incremental em vez de criarem um ambiente totalmente duplicado. + **Complexidade de reversão**: as implantações contínuas tornam as reversões mais complexas em comparação com as implantações azul/verdes. Se você precisar reverter, deverá iniciar uma nova implantação com a definição da tarefa anterior. + **Velocidade de implantação**: as implantações contínuas podem levar mais tempo para serem concluídas do que as implantações azul/verdes, especialmente para serviços com muitas tarefas. + **Configuração do balanceador de carga**: sua configuração atual do balanceador de carga continuará funcionando com implantações contínuas, mas o comportamento de mudança de tráfego será diferente. ## Pré-requisitos Antes de migrar seu serviço de implantações azul/verde para contínuas, verifique se você tem o seguinte: + Um serviço existente do Amazon ECS usando a estratégia de implantação azul/verde + Não há implantações contínuas para o serviço (aguarde a conclusão de todas as implantações atuais) + Uma compreensão clara de como seu serviço se comportará com implantações contínuas **nota** Você não poderá migrar um serviço para uma implantação contínua se ele tiver uma implantação em andamento. Aguarde que todas as implantações atuais sejam concluídas antes de continuar. ## Procedimento de migração Siga estas etapas para migrar seu serviço do Amazon ECS de azul/verde para implantações contínuas: 1. Abra o console do Amazon ECS em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. No painel de navegação, escolha **Clusters**. 1. Na página **Clusters**, escolha o cluster que contém o serviço que você deseja migrar. 1. Na página **Detalhes do cluster**, escolha a guia **Serviços**. 1. Selecione o serviço que você deseja migrar e escolha **Atualizar**. 1. Na página **Atualizar serviço**, navegue até a seção **Opções de implantação** e expanda-a, se necessário. 1. Em **Estratégia de implantação**, escolha **Atualização contínua**. 1. Defina as configurações de implantação contínua: 1. Em **Porcentagem de integridade mínima**, insira a porcentagem mínima de tarefas que seu serviço deve manter no estado `RUNNING` durante uma implantação. Esse valor é especificado como uma porcentagem do número de tarefas desejadas para o serviço. 1. Em **Porcentagem máxima**, insira a porcentagem máxima de tarefas que são permitidas no estado `RUNNING` ou `PENDING` durante uma implantação. Esse valor é especificado como uma porcentagem do número de tarefas desejadas para o serviço. 1. Opcional: em **Detecção de falhas de implantação**, configure como o Amazon ECS detectará e lidará com falhas de implantação: 1. Para habilitar o disjuntor de implantação, escolha **Usar o disjuntor de implantação de implantação**. 1. Para reverter automaticamente implantações com falha, escolha **Reverter em caso de falha**. 1. Revise suas alterações de configuração e escolha **Atualizar** para salvá-las e migrar o serviço para uma implantação contínua. O Amazon ECS atualizará sua configuração de serviço para usar a estratégia de implantação contínua. Na próxima vez que você atualizar o serviço, ele usará o processo de implantação contínua. **nota** Quando você migra da implantação azul/verde para a contínua, o Amazon ECS lida com a transição da seguinte forma: Identificando a revisão atual do serviço ativo que está entregando tráfego. Mantendo a configuração existente do balanceador de carga, mas alterando a forma como as novas implantações são processadas. Preparando o serviço para futuras implantações contínuas. ## Próximas etapas + Atualize o serviço para iniciar a implantação. Para obter mais informações, consulte [Atualizar um serviço do Amazon ECS](update-service-console-v2.md). # Solucionar problemas de atualizações da estratégia de implantação do Amazon ECS Esta seção fornece soluções para problemas comuns que você pode encontrar ao migrar estratégias de implantação. ## Várias revisões de serviços ou conjuntos de tarefas Os problemas a seguir estão relacionados à presença de várias revisões de serviço para uma implantação. Vários conjuntos de tarefas ao atualizar o controlador de implantação do ECS *Mensagem de erro*: `Updating the deployment controller is not supported when there are multiple tasksets in the service. Please ensure your service has only one taskset and try again.` *Solução*: esse erro ocorre ao tentar alterar o tipo de controlador de implantação de um serviço com vários conjuntos de tarefas ativos. Para resolver esse problema do controlador de implantação `CODE_DEPLOY` ou `EXTERNAL`: 1. Verifique os conjuntos de tarefas atuais: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets" ``` 1. Aguarde a conclusão de todas as implantações em andamento. 1. Force uma nova implantação para limpar os conjuntos de tarefas: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --force-new-deployment ``` 1. Se necessário, exclua manualmente os conjuntos de tarefas extras: ``` aws ecs delete-task-set --cluster your-cluster-name --service your-service-name --task-set task-set-id ``` 1. Depois que restar apenas um conjunto de tarefas, tente atualizar novamente o controlador de implantação. Para obter mais informações, consulte [Controladores e estratégias de implantação de serviços do Amazon ECS](ecs_service-options.md). O conjunto de tarefas primárias está ausente ao atualizar o controlador de implantação do `ECS` *Mensagem de erro*: `Updating the deployment controller requires a primary taskset in the service. Please ensure your service has a primary taskset and try again.` *Solução*: esse erro ocorre ao tentar alterar o tipo de controlador de implantação de um serviço que não tem um conjunto de tarefas primárias. Para resolver esse problema: 1. Verifique o status do serviço e os conjuntos de tarefas. ). Caso exista um conjunto de tarefas no serviço, ele deverá ser marcado como `ACTIVE`. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets[*].[status,id] ``` Se não houver conjuntos de tarefas no estado `ACTIVE`, migre a implantação. Para obter mais informações, consulte [Abordagens de migração](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/migrate-codedeploy-to-ecs-bluegreen.html#migration-paths). 1. Se o serviço não tiver tarefas em execução, implante pelo menos uma tarefa atualizando o serviço: ``` aws ecs update-service-primary-task-set --cluster your-cluster-name --service your-service-name --primary-task-set your-taskset-id ``` Isso marcará o conjunto de tarefas (anteriormente `ACTIVE`) no serviço como status `PRIMARY`. 1. Aguarde até que a tarefa alcance um estado de execução estável. Você pode verificar o status com: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deployments" ``` 1. Depois que o serviço tiver uma tarefa principal definida com tarefas em execução, tente atualizar novamente o controlador de implantação. Para obter mais informações, consulte [Controladores e estratégias de implantação de serviços do Amazon ECS](ecs_service-options.md). ## Incompatibilidade entre o tipo de detecção de falhas da implantação e o controlador de implantação Os problemas a seguir estão relacionados a uma incompatibilidade entre o tipo de detecção de falha de implantação e o controlador de implantação. Disjuntor de implantação com um controlador não ECS *Mensagem de erro*: `Deployment circuit breaker feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.` *Solução*: esse erro ocorre ao tentar habilitar o recurso de disjuntor de implantação em um serviço que não está usando o controlador de implantação do `ECS`. O disjuntor de implantação é compatível apenas com o controlador de implantação do `ECS`. 1. Verifique seu controlador de implantação atual do serviço: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. Atualize seu serviço para usar o controlador de implantação do `ECS`: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. Depois que o serviço estiver usando o controlador de implantação do `ECS`, habilite o disjuntor de implantação: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" ``` Para obter mais informações, consulte [Como o disjuntor de implantação do Amazon ECS realiza a detecção de falhas](deployment-circuit-breaker.md). Reversão baseada em alarme com controlador não ECS *Mensagem de erro*: `Alarm based rollback feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.` *Solução*: esse erro ocorre ao tentar configurar a reversão baseada em alarme em um serviço que não está usando o controlador de implantação do `ECS`. O recurso de reversão baseado em alarme é compatível apenas com o controlador de implantação do `ECS`. 1. Verifique seu controlador de implantação atual do serviço: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. Atualize seu serviço para usar o controlador de implantação do `ECS`: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. Depois que o serviço estiver usando o controlador de implantação do `ECS`, configure a reversão baseada em alarme: ``` aws ecs update-service --cluster your-cluster-name --services your-service-name --deployment-configuration "alarms={alarmNames=[your-alarm-name],enable=true,rollback=true}" ``` Para obter mais informações, consulte [Como os alarmes do CloudWatch realizam a detecção de falhas de implantação do Amazon ECS](deployment-alarm-failure.md). ## Incompatibilidade entre o Service Connect e o controlador de implantação Os problemas a seguir estão relacionados a uma incompatibilidade entre o Service Connect e o controlador de implantação. Controlador `EXTERNAL` com o Service Connect *Mensagem de erro*: `The EXTERNAL deployment controller type is not supported for services using Service Connect.` *Solução*: esse erro ocorre ao tentar usar o controlador de implantação `EXTERNAL` com um serviço que tenha o Service Connect habilitado. O controlador `EXTERNAL` não é compatível com o Service Connect. 1. Verifique se o seu serviço tem o Service Connect habilitado: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].serviceConnectConfiguration" ``` 1. Se você precisar usar o controlador de implantação `EXTERNAL`, desabilite o Service Connect atualizando seu serviço: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "{}" ``` 1. Como alternativa, se você precisar usar o Service Connect, use o controlador de implantação do `ECS`: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` Para obter mais informações, consulte [Controladores e estratégias de implantação de serviços do Amazon ECS](ecs_service-options.md). Service Connect com controlador não ECS *Mensagem de erro*: `Service Connect feature is only supported with ECS (rolling update) deployment controller. Update to ECS deployment controller and try again.` *Solução*: esse erro ocorre ao tentar habilitar o Service Connect que não está usando o controlador de implantação do `ECS`. O recurso Service Connect é compatível apenas com o controlador de implantação do `ECS`. 1. Verifique seu controlador de implantação atual do serviço: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. Atualize seu serviço para usar o controlador de implantação do ECS: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. Quando o serviço estiver usando o controlador de implantação do ECS, habilite o Service Connect: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "enabled=true,namespace=your-namespace" ``` Para obter mais informações, consulte [Controladores e estratégias de implantação de serviços do Amazon ECS](ecs_service-options.md). ## Incompatibilidade entre o tipo de controlador e a estratégia de agendamento Os problemas a seguir estão relacionados a uma incompatibilidade entre o tipo de controlador e a estratégia de agendamento. Controlador `CODE_DEPLOY` com estratégia de agendamento `DAEMON` *Mensagem de erro*: `The CODE_DEPLOY deployment controller type is not supported for services using the DAEMON scheduling strategy.` *Solução*: esse erro ocorre ao tentar usar o controlador de implantação CODE\$1DEPLOY com um serviço que usa a estratégia de agendamento `DAEMON`. O controlador `CODE_DEPLOY` é compatível apenas com a estratégia de agendamento `REPLICA`. 1. Verifique a estratégia de agendamento atual do seu serviço: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy" ``` 1. Se você precisar de implantações azul/verde, altere o serviço para usar a estratégia de agendamento `REPLICA`: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA ``` 1. Como alternativa, se você precisar usar a estratégia de agendamento `DAEMON`, use o controlador de implantação do `ECS`: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` Para obter mais informações, consulte [Controladores e estratégias de implantação de serviços do Amazon ECS](ecs_service-options.md). Controlador EXTERNAL com estratégia de agendamento DAEMON *Mensagem de erro*: `The EXTERNAL deployment controller type is not supported for services using the DAEMON scheduling strategy.` *Solução*: esse erro ocorre ao tentar usar o controlador de implantação EXTERNAL com um serviço do ECS que usa a estratégia de agendamento DAEMON. O controlador EXTERNAL é compatível apenas com a estratégia de agendamento REPLICA. 1. Verifique a estratégia de agendamento atual do seu serviço: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy" ``` 1. Se você precisar usar o controlador de implantação `EXTERNAL`, altere o serviço para usar a estratégia de agendamento `REPLICA`: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA ``` 1. Como alternativa, se você precisar usar a estratégia de agendamento `DAEMON`, use o controlador de implantação do `ECS`: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` Para obter mais informações, consulte [Controladores e estratégias de implantação de serviços do Amazon ECS](ecs_service-options.md). Registros de serviços com tipo de inicialização externa *Mensagem de erro*: `Service registries are not supported for external launch type.` *Solução*: esse erro ocorre ao tentar configurar a descoberta de serviços (registros de serviços) para um serviço que usa o tipo de inicialização `EXTERNAL`. A descoberta de serviços não é compatível com o tipo de inicialização `EXTERNAL`. 1. Verifique o tipo de inicialização atual do seu serviço: ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].launchType" ``` 1. Se você precisar da descoberta de serviços, altere o serviço para usar o tipo de inicialização do `EC2` ou do `FARGATE`: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --launch-type FARGATE ``` 1. Como alternativa, se você precisar usar o tipo de inicialização `EXTERNAL`, remova a configuração do registro do serviço: ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-registries "[]" ``` Para obter mais informações, consulte [Controladores e estratégias de implantação de serviços do Amazon ECS](ecs_service-options.md). ## Reverter uma atualização do controlador de implantação Se você decidir que deseja retornar ao controlador de implantação anterior, realize uma das seguintes ações: + Se você usou o CloudFormation, poderá usar o modelo anterior para criar uma nova pilha. Para obter mais informações, consulte [Criar uma pilha no console do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) no *Guia do usuário do CloudFormation*. + Se você usou o console do Amazon ECS ou a AWS CLI, poderá atualizar o serviço. Para obter mais informações, consulte [Atualizar um serviço do Amazon ECS](update-service-console-v2.md). Se você usar o comando update-service, use a opção `--deployment-controller` e defina-a para o controlador de implantação anterior. # Visualize o histórico de serviços usando implantações de serviços do Amazon ECS As implantações de serviços fornecem uma visão abrangente das suas implantações. As implantações de serviços fornecem as seguintes informações sobre o serviço: + A configuração da workload atualmente implantada (a revisão do serviço de origem) + A configuração da workload em implantação (a revisão do serviço de destino) + O status da implantação + O número de tarefas com falha que a interrupção do circuito detectou + Os alarmes do CloudWatch que estão em alarme + Quando a implantação do serviço foi iniciada e concluída + Os detalhes de uma reversão, caso tenha ocorrido Para obter informações sobre as propriedades de implantação do serviço, consulte [Propriedades incluídas na implantação de serviço do Amazon ECS](service-deployment-property.md). As implantações de serviços são somente leitura e cada uma tem um ID exclusivo. Há três estágios de implantação de um serviço: | Estágio | Definição | Estados associados | | --- | --- | --- | | Pendente | Uma implantação de serviço foi criada, mas ainda não foi iniciada | PENDING | | Contínuo | Uma implantação de serviço está em andamento | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-deployment.html) | | Completed | A implantação de um serviço foi concluída (com ou sem êxito) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-deployment.html) | Você usa implantações de serviços para entender o ciclo de vida do seu serviço e determinar se há alguma medida a ser tomada. Por exemplo, se uma reversão ocorreu, talvez seja necessário investigar a implantação do serviço e observar os eventos do serviço. Você pode ver o histórico mais recente de 90 dias das implantações criadas em ou após 25 de outubro de 2024 usando o console, a API e a AWS CLI. É possível interromper uma implantação que não foi concluída. Para obter mais informações, consulte [Parar implantações de serviços do Amazon ECS](stop-service-deployment.md). ## Ciclo de vida de implantação de serviços O Amazon ECS cria uma nova implantação de serviço automaticamente quando qualquer uma das seguintes ações acontece: + Um usuário cria um serviço. + Um usuário atualiza o serviço e usa a opção de forçar nova implantação. + Um usuário atualiza uma ou mais propriedades do serviço que exigem uma implantação. Enquanto a implantação está em andamento, o Amazon ECS atualiza as seguintes propriedades de implantação do serviço para refletir o progresso da implantação: + O estado + O número de tarefas em execução O número de tarefas em execução indicado na revisão do serviço pode não ser igual ao número real de tarefas em execução. Esse número representa o número de tarefas em execução quando a implantação foi concluída. Por exemplo, se você iniciou tarefas independentemente da implantação do serviço, essas tarefas não serão incluídas na contagem de tarefas em execução para a revisão do serviço. + Detecção de falha no disjuntor: + O número de tarefas que falharam ao iniciar + Detecção de falhas de alarme do CloudWatch + Os alarmes que estão ativos + Informações de reversão: + A hora de início + O motivo da reversão + O ARN da revisão de serviço usada para a reversão + O motivo do status O Amazon ECS exclui a implantação do serviço quando você exclui um serviço. ## Estados da implantação de serviços A implantação de um serviço começa no estado `PENDING`. A ilustração a seguir mostra os estados de implantação de um serviço que podem ocorrer após o estado `PENDING`: `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_IN_PROGRESSS`, `ROLLBACK_FAILED`, `ROLLBACK_SUCCESSFUL` e `STOPPED`. ![\[Estados de implantação de serviços STOP_REQUESTED, SUCCESSFUL e ROLLBACK_IN_PROGRESS que podem ocorrer após o estado IN_PROGRESS.\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/images/service-deployment-states.png) As informações a seguir fornecem detalhes sobre os estados de implantação de um serviço: + `PENDING`: a implantação de serviço foi criada, mas ainda não foi iniciada. O estado pode avançar para `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `STOP_REQUESTED` ou `STOPPED`. + `IN_PROGRESS`: a implantação do serviço está em andamento. O estado pode avançar para `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_REQUESTED`, `ROLLBACK_IN_PROGRESS` ou `STOPPED`. + `STOP_REQUESTED`: o estado de implantação do serviço avança para `STOP_REQUESTED` quando qualquer uma das seguintes situações acontece: + Um usuário inicia uma novaa implantação de serviço. + A opção de reversão não está em uso para o mecanismo de detecção de falhas (disjuntor ou baseado em alarme) e o serviço não atinge o estado `SUCCESSFUL`. O estado avança para `STOPPED`. + `ROLLBACK_REQUESTED`: o estado de implantação do serviço muda para `ROLLBACK_REQUESTED` quando um usuário solicita uma reversão via console, API ou CLI. O estado pode avançar para `SUCCESSFUL`, `ROLLBACK_IN_PROGRESS` e `STOPPED`. + `SUCCESSFUL`: o estado de implantação do serviço avança para `SUCCESSFUL` quando a implantação do serviço é concluída com êxito. + `ROLLBACK_IN_PROGRESS`: o estado de implantação do serviço avança para `ROLLBACK_IN_PROGRESS` quando a opção de reversão está em uso para o mecanismo de detecção de falhas (disjuntor ou baseado em alarme) e o serviço falha. O estado avança para `ROLLBACK_SUCCESSFUL` ou `ROLLBACK_FAILED`. # Propriedades incluídas na implantação de serviço do Amazon ECS As propriedades a seguir estão incluídas em uma implantação de serviço. | Propriedade | Descrição | | --- | --- | | ARN da implantação do serviço | O ARN da implantação do serviço. | | Nome de recurso da Amazon (ARN) do serviço | O ARN do serviço para esta implantação de serviço. | | ARN do cluster | O ARN do cluster que hospeda o serviço. | | Hora de criação da implantação do serviço | A hora em que a implantação do serviço foi criada. | | Hora de início da implantação do serviço | A hora em que a implantação do serviço começou. | | Hora de término da implantação do serviço | A hora em que a implantação do serviço terminou. | | Hora de interrupção da implantação do serviço | A hora em que a implantação do serviço foi interrompida. | | Hora de atualização da implantação do serviço | A hora da última atualização da implantação do serviço. | | Revisões de serviços de origem | As revisões de serviços atualmente em execução. Para obter mais informações sobre as propriedades incluídas, consulte [Propriedades incluídas na revisão de serviço do Amazon ECS](service-revision-property.md). | | Configuração de implantação | Os parâmetros de implantação, incluindo a configuração do disjuntor e os alarmes.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-deployment-property.html) | | Revisão do serviço de destino | A revisão do serviço a ser implantado. Depois que a implantação for concluída com êxito, a revisão do serviço de destino será a revisão do serviço em execução. | | Status da implantação de serviços | O estado da implantação de serviços.Os valores válidos são PENDING, SUCCESSFUL, STOPPED, STOP\$1REQUESTED, STOP\$1IN\$1PROGRESS, IN\$1PROGRESS, ROLLBACK\$1IN\$1PROGRESS, ROLLBACK\$1SUCCESSFUL, e ROLLBACK\$1FAILED. | | Informações sobre status de implantação de serviços | Informações sobre por que a implantação do serviço está no status atual. Por exemplo, o disjuntor detectou uma falha. | | Informações de reversão | As opções de reversão usadas pela implantação do serviço quando a implantação falha. | | Opções de disjuntores de implantação de serviços | O disjuntor que determina que a implantação de um serviço falhou. | | Alarmes do CloudWatch para a implantação do serviço | Os alarmes do CloudWatch que determinam quando a implantação de um serviço falha. | # Permissões necessárias para visualizar implantações de serviço do Amazon ECS Ao seguir a prática recomendada de conceder privilégio mínimo, é necessário adicionar permissões adicionais para visualizar implantações de serviço no console. É necessário ter acesso às seguintes ações: + ListServiceDeployments + DescribeServiceDeployments + DescribeServiceRevisions É necessário ter acesso aos seguintes recursos: + Serviço + Implantação de serviços + Revisão de serviços O exemplo de política a seguir contém as permissões necessárias e limita as ações a um serviço especificado. Substitua `account`, `cluster-name` e `service-name` por seus próprios valores. ------ #### [ JSON ] **** ``` { "Statement": [ { "Effect": "Allow", "Action": [ "ecs:ListServiceDeployments", "ecs:DescribeServiceDeployments", "ecs:DescribeServiceRevisions" ], "Resource": [ "arn:aws:ecs:us-east-1:123456789012:service/cluster-name/service-name", "arn:aws:ecs:us-east-1:123456789012:service-deployment/cluster-name/service-name/*", "arn:aws:ecs:us-east-1:123456789012:service-revision/cluster-name/service-name/*" ] } ] } ``` ------ # Visualizar implantações de serviços do Amazon ECS Você pode ver o histórico mais recente de 90 dias das implantações criadas em ou após 25 de outubro de 2024. As implantações de serviços podem estar em qualquer um dos seguintes estados: + Em andamento + Pendente + Completed Você pode usar essas informações para determinar se precisa atualizar a forma como o serviço está sendo implantado ou a revisão do serviço. Para obter mais informações sobre as propriedades incluídas, consulte [Propriedades incluídas na implantação de serviço do Amazon ECS](service-deployment-property.md). Antes de começar, configure as permissões necessárias para visualizar as implantações de serviços. Para obter mais informações, consulte [Permissões necessárias para visualizar implantações de serviço do Amazon ECS](service-deployment-permissions.md). ------ #### [ Amazon ECS Console ] 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. Na página de detalhes da implantação, escolha **Implantações**. 1. Escolha a implantação do serviço a ser visualizada. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/view-service-deployment.html) A página de detalhes da implantação do serviço é exibida. 1. (Opcional) Compare as revisões do serviço para visualizar as diferenças. Em **Revisões do serviço**, escolha **Comparar revisões** e selecione 2 revisões para comparar. As revisões do serviço são exibidas lado a lado com as diferenças destacadas. ------ #### [ AWS CLI ] 1. Execute `list-service-deployments` para recuperar o ARN da implantação do serviço. Substitua as variáveis por seus próprios valores. ``` aws ecs list-service-deployments --cluster cluster-name --service service-name ``` Anote o serviceDeploymentArn para a implantação que deseja visualizar. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095", "status": "SUCCESSFUL" } ] } ``` 1. Executar `describe-service-deployments`. Use o `serviceDeploymentArn` que foi devolvido de `list-service-deployments`. Substitua as variáveis por seus próprios valores. ``` aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 ``` ------ ## Próximas etapas Você pode visualizar os detalhes das revisões de serviço na implantação. Para obter mais informações, consulte . [Visualizar detalhes da revisão de serviço do Amazon ECS](view-service-revision.md) # Revisões de serviços do Amazon ECS Uma revisão do serviço contém um registro da configuração da workload que o Amazon ECS está tentando implantar. Sempre que você cria ou implanta um serviço, o Amazon ECS cria e captura automaticamente a configuração que você está tentando implantar na revisão do serviço. As revisões do serviço são somente leitura e têm identificadores exclusivos. Para obter mais informações sobre as propriedades incluídas, consulte [Propriedades incluídas na revisão de serviço do Amazon ECS](service-revision-property.md). As revisões de serviço oferecem os seguintes benefícios: + Durante a implantação de um serviço, você pode comparar a revisão do serviço atualmente implantada (origem) com a que está sendo implantada (destino). + Quando você usa a opção de reversão para uma implantação de serviço, o Amazon ECS reverte automaticamente a implantação do serviço até a última revisão de serviço implantada com sucesso. + As revisões de serviço contêm o registro da configuração da workload em um recurso. ## Ciclo de vida de uma revisão de serviço O Amazon ECS cria automaticamente uma nova revisão de serviço quando você cria um serviço ou atualiza uma propriedade do serviço que inicia uma implantação. O Amazon ECS não cria uma nova revisão de serviço para uma operação de reversão. O Amazon ECS usa a última revisão de serviço bem-sucedida para a reversão. A revisão de serviço é imutável. O Amazon ECS exclui a revisão do serviço quando você exclui um serviço. Você pode visualizar as revisões de serviço criadas em ou após 25 de outubro de 2024 usando o console, a API e a CLI. # Propriedades incluídas na revisão de serviço do Amazon ECS As propriedades a seguir estão incluídas em uma revisão de serviço. | Recurso | Descrição | | --- | --- | | Nome de recurso da Amazon (ARN) do serviço | O ARN que identifica o serviço. | | ARN do cluster | O ARN do cluster que hospeda o serviço. | | ARN da definição de tarefas | O ARN da definição de tarefa usado pelas tarefas do serviço. | | Registros de serviços | Detalhes dos registros de serviço usados para a descoberta de serviços. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-revision-property.html) | | Provedores de capacidade | Os detalhes de uma estratégia de provedor de capacidade. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-revision-property.html) | | Imagens de contêiner | Os detalhes sobre as imagens de contêineres. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-revision-property.html) | | Redes | A configuração de rede para o serviço. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-revision-property.html) | | Tipo de inicialização | A opção de computação usada para o serviço. | | Propriedades específicas do Fargate | Ao utilizar o Fargate, trata-se de informações sobre a versão do Fargate. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-revision-property.html) | | Volumes do Amazon EBS configurados na implantação | A configuração de um volume especificado na definição da tarefa como um volume configurado no momento da execução. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-revision-property.html) | | Service Connect | A configuração Service Connect. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-revision-property.html) | | Balanceadores de carga do serviço | Os balanceadores de carga que roteiam o tráfego do serviço. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-revision-property.html) | | Monitoramento de runtime | Indica se o monitoramento de runtime está ativado. | | Data de criação | A data em que a revisão do serviço foi criada. | | VPC Lattice | A configuração do VPC Lattice para a revisão do serviço. | # Visualizar detalhes da revisão de serviço do Amazon ECS É possível visualizar informações sobre os seguintes tipos de revisão de serviço que foram criadas em ou após 25 de outubro de 2024: + Origem: a configuração da workload atualmente implantada + Destino: a configuração da workload em implantação ------ #### [ Amazon ECS Console ] 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. Na página de detalhes da implantação, escolha **Implantações**. 1. Escolha a revisão de serviço a ser visualizada. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/view-service-revision.html) ------ #### [ AWS CLI ] 1. Execute `describe-service-deployments` para recuperar o ARN da revisão de serviço. Substitua as variáveis por seus próprios valores. ``` aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:account-id:service/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 ``` Anote o `arn` para `sourceServiceRevisions` ou `targetServiceRevisions`. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example", "updatedAt": "2024-09-10T16:49:35.572000+00:00", "sourceServiceRevision": { "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373578954", "requestedTaskCount": 0, "runningTaskCount": 0, "pendingTaskCount": 0 }, "targetServiceRevision": { "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095", "requestedTaskCount": 0, "runningTaskCount": 0, "pendingTaskCount": 0 }, "status": "IN_PROGRESS", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": false, "rollback": false }, "maximumPercent": 200, "minimumHealthyPercent": 100 } } ], "failures": [] } ``` 1. Executar `describe-service-revisions`. Use o `arn` que foi devolvido de `describe-service-deployments`. Substitua as variáveis por seus próprios valores. ``` aws ecs describe-service-revisions --service-revision-arns arn:aws:ecs:region:123456789012:service-revision/cluster-name/service-name/4980306466373577095 ``` ------ # Balancear um serviço do Amazon ECS entre zonas de disponibilidade A partir de 5 de setembro de 2025, o Amazon ECS permite o rebalanceamento de zona de disponibilidade para todos os serviços elegíveis para o recurso. Um serviço é considerado elegível quando a zona de disponibilidade é a primeira estratégia de posicionamento de tarefas ou quando não há uma estratégia de posicionamento. Para ajudar suas aplicações a alcançar alta disponibilidade, recomendamos configurar seus serviços multitarefas para serem executados em várias zonas de disponibilidade. Para serviços que especificam que sua primeira estratégia de colocação seja distribuída por zonas de disponibilidade, a AWS faz o possível para distribuir uniformemente as tarefas de serviço nas zonas de disponibilidade disponíveis. No entanto, pode haver momentos em que o número de tarefas em execução em uma zona de disponibilidade não é o mesmo que em outras zonas de disponibilidade, como após uma interrupção na zona de disponibilidade. Para resolver esse desequilíbrio de tarefas, é possível habilitar o recurso de rebalanceamento de zonas de disponibilidade. Com o rebalanceamento de zonas de disponibilidade, o Amazon ECS monitora continuamente a distribuição de tarefas entre as zonas de disponibilidade para cada um dos seus serviços. Quando o Amazon ECS detecta uma distribuição desigual de tarefas, ele atua automaticamente para reequilibrar a workload entre as zonas de disponibilidade. Isso envolve o lançamento de novas tarefas em zonas de disponibilidade com menos tarefas em execução e o encerramento de tarefas em zonas de disponibilidade sobrecarregadas. Essa redistribuição garante que nenhuma zona de disponibilidade se torne um ponto de falha, ajudando a manter a disponibilidade geral de suas aplicações em contêineres. O processo de rebalanceamento automatizado elimina a necessidade de intervenção manual, acelerando o tempo de recuperação após um evento. Uma visão geral do processo de rebalanceamento de zonas de disponibilidade é: 1. O Amazon ECS começa a monitorar um serviço depois que ele atinge o estado estável e analisa o número de tarefas em execução em cada zona de disponibilidade. 1. O Amazon ECS executa as seguintes operações ao detectar um desequilíbrio no número de tarefas em execução em cada zona de disponibilidade: + Envia um evento de serviço indicando que o rebalanceamento de zonas de sisponibilidade está começando. + Inicia tarefas em zonas de disponibilidade com o menor número de tarefas em execução + Interrompe as tarefas em zonas de disponibilidade com o maior número de tarefas em execução. + O agendador espera que as tarefas recém-iniciadas estejam `HEALTHY` e `RUNNING` antes de interromper as tarefas na zona de disponibilidade superdimensionada. + Envia um evento de serviço com o resultado do rebalanceamento de zonas de disponibilidade. ## Como o Amazon ECS detecta a distribuição desigual de tarefas O Amazon ECS determina um desequilíbrio no número de tarefas em execução em cada zona de disponibilidade ao dividir a contagem de tarefas desejada do serviço pelo número de zonas de disponibilidade configuradas. Se a contagem de tarefas desejada não for dividida de forma igual, o Amazon ECS distribuirá o restante das tarefas uniformemente entre as zonas de disponibilidade configuradas. Cada zona de disponibilidade precisa ter pelo menos uma tarefa. Por exemplo, considere um serviço do Amazon ECS com uma contagem desejada de duas tarefas configuradas para duas zonas de disponibilidade. Nesse cenário, a contagem de tarefas desejada será dividida uniformemente. Uma distribuição balanceada seria uma tarefa por zona de disponibilidade. Se houvesse duas tarefas na zona de disponibilidade 1 e nenhuma tarefa na zona de disponibilidade 2, o Amazon ECS iniciaria o rebalanceamento ao iniciar uma tarefa na zona de disponibilidade 2 antes de interromper uma tarefa na zona de disponibilidade 1. Agora, considere um serviço do Amazon ECS com uma contagem desejada de três tarefas configuradas para duas zonas de disponibilidade. Nesse cenário, a contagem de tarefas desejada não será dividida uniformemente. Uma distribuição balanceada seria uma tarefa na zona de disponibilidade 1 e duas tarefas na zona de disponibilidade 2, porque cada zona de disponibilidade tem pelo menos uma tarefa e a tarefa restante é colocada na zona de disponibilidade 2. Considere um serviço do Amazon ECS que tenha uma contagem desejada de cinco tarefas configuradas para três zonas de disponibilidade. Nesse cenário, a contagem de tarefas desejada não será dividida uniformemente. Uma distribuição balanceada seria uma tarefa na zona de disponibilidade 1 e duas tarefas cada nas zonas de disponibilidade 2 e 3. Após contabilizar cada zona de disponibilidade com uma tarefa cada, as duas tarefas restantes são distribuídas uniformemente entre as zonas de disponibilidade. ## Considerações para configurar o rebalanceamento de zonas de disponibilidade Ao configurar o rebalanceamento de zonas de disponibilidade, considere o seguinte: + O rebalanceamento da zona de disponibilidade oferece suporte aos provedores de capacidade do Fargate e do EC2 e é compatível com as instâncias gerenciadas do Amazon ECS. Para o Fargate, o Amazon ECS redistribuirá automaticamente as tarefas nas zonas de disponibilidade disponíveis para manter o equilíbrio. Para provedores de capacidade do EC2, o Amazon ECS rebalanceia as tarefas entre as instâncias de contêineres existentes da melhor forma possível, respeitando suas estratégias e restrições de posicionamento definidas. Porém, o Amazon ECS não pode iniciar novas instâncias em zonas de disponibilidade subutilizadas como parte do processo de rebalanceamento, limitando o rebalanceamento às instâncias de contêiner existentes. + O rebalanceamento de zonas de disponibilidade funciona nas seguintes configurações: + Serviços que usam a estratégia `Replica` + Os serviços que especificam a zona de disponibilidade se distribuem como a primeira estratégia de posicionamento de tarefas ou não especificam uma estratégia de posicionamento. + Não é possível usar o rebalanceamento de zonas de disponibilidade com serviços que atendem a qualquer um dos seguintes critérios: + Usam a estratégia `Daemon` + Usam o tipo de execução `EXTERNAL` (ECS Anywhere) + Usam 100% como valor de `maximumPercent` + Usam um Classic Load Balancer + Usa `attribute:ecs.availability-zone` como uma restrição de posicionamento de tarefas ## Estratégias e restrições de posicionamento com rebalanceamento de zonas de disponibilidade As estratégias de posicionamento determinam como o Amazon ECS seleciona instâncias de contêineres e zonas de disponibilidade para o término da colocação de tarefas. As restrições de posicionamento de tarefas são regras que determinam se uma tarefa pode ser executada em uma instância de contêiner específica. No EC2, é possível usar estratégias e restrições de posicionamento em conjunto com o rebalanceamento de zonas de disponibilidade. No entanto, para que o rebalanceamento de zonas de disponibilidade funcione, a estratégia de posicionamento de distribuição em zonas de disponibilidade deve ser a primeira estratégia especificada. O rebalanceamento de zonas de disponibilidade é compatível com várias combinações de estratégias de posicionamento. Por exemplo, você pode criar uma estratégia que primeiro distribua as tarefas uniformemente entre as zonas de disponibilidade e, em seguida, agrupe as tarefas com base na memória dentro de cada zona de disponibilidade. Nesse caso, o rebalanceamento de zonas de disponibilidade funciona porque a estratégia de distribuição em zonas de disponibilidade é especificada primeiro. É importante observar que o rebalanceamento de zonas de disponibilidade não funcionará se a primeira estratégia na matriz da estratégia de posicionamento não for um componente de distribuição de zona de disponibilidade. Esse requisito garante que o foco principal da distribuição de tarefas seja manter o equilíbrio entre as zonas de disponibilidade, o que é crucial para a alta disponibilidade. Para obter mais informações sobre estratégias e restrições de posicionamento de tarefas, consulte [Como o Amazon ECS posiciona tarefas em instâncias de contêineres](task-placement.md). Não há suporte para estratégias e restrições de posicionamento das tarefas que usam o Fargate. O Fargate fará o possível para distribuir tarefas em zonas de disponibilidade acessíveis. Se o provedor de capacidade incluir o Fargate e o Fargate Spot, o comportamento da distribuição será independente para cada provedor de capacidade. A estratégia a seguir distribui tarefas uniformemente em zonas de disponibilidade e, em seguida, agrupa as tarefas com base na memória em cada zona de disponibilidade. O rebalanceamento de zonas de disponibilidade é compatível com o serviço porque a estratégia `spread` é a primeira. ``` "placementStrategy": [ { "field": "attribute:ecs.availability-zone", "type": "spread" }, { "field": "memory", "type": "binpack" } ] ``` ## Ative o rebalanceamento de zonas de disponibilidade É necessário habilitar o rebalanceamento de zonas de disponibilidade para serviços novos e existentes. É possível habilitar e desabilitar o rebalanceamento de zonas de disponibilidade usando o console, as APIs, a AWS CLI ou o CloudFormation. O comportamento padrão do `AvailabilityZoneRebalancing` difere entre solicitações de criação e atualização: + Para criar solicitações de serviço, quando nenhum valor é especificado para `AvailabilityZoneRebalancing`, o Amazon ECS usa o valor padrão `ENABLED`. + Para atualizar solicitações de serviço, quando nenhum valor é especificado para `AvailabilityZoneRebalancing`, o Amazon ECS usa como padrão o valor `AvailabilityZoneRebalancing` do serviço existente. Se o serviço nunca teve um valor de `AvailabilityZoneRebalancing` definido, o Amazon ECS assumirá o valor `DISABLED`. | Tipo de serviço | solicitações de | Console | CLI | | --- | --- | --- | --- | | Existentes | [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) | [Atualizar um serviço do Amazon ECS](update-service-console-v2.md) | [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) | | Novo | [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) | [Criação de uma implantação de atualização contínua do Amazon ECS](create-service-console-v2.md) | [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) | O seguinte exemplo mostra como habilitar o rebalanceamento de serviços ao criar um novo serviço: ``` aws ecs create-service \ --cluster my-cluster \ --service-name my-service \ --task-definition my-task-definition:1 \ --desired-count 6 \ --availability-zone-rebalancing ENABLED ``` # Monitorar o rebalanceamento de zonas de disponibilidade do Amazon ECS Você pode verificar se o rebalanceamento de zonas de disponibilidade está habilitado para um serviço no console ou então chamar `describe-services`. O exemplo a seguir pode ser usado para verificar o status com a CLI. A resposta será `ENABLED` ou `DISABLED`. ``` aws ecs describe-services \ --services service-name \ --cluster cluster-name \ --query services[0].availabilityZoneRebalancing ``` ## Eventos de serviço O Amazon ECS envia eventos de ação de serviço para ajudar você a entender o ciclo de vida do reequilíbrio de zonas de disponibilidade. | Event | Cenário | Tipo | Saiba mais | | --- | --- | --- | --- | | SERVICE\$1REBALANCING\$1STARTED | O Amazon ECS inicia uma operação de rebalanceamento de zonas de disponibilidade | INFORMAÇÕES | [O serviço (*service-name*) não está balanceado em AZ com *number-tasks* tarefas na *Zona de disponibilidade 1*, *number-tasks* na *Zona de disponibilidade 2* e *number-tasks* na *Zona de disponibilidade 3*. Rebalanceamento de AZ em andamento.](service-rebalancing-event-messages-list.md#service-rebalancing-started) | | SERVICE\$1REBALANCING\$1COMPLETED | A operação de rebalanceamento de zonas de disponibilidade é concluída | INFORMAÇÕES | [O serviço (*service-name*) está balanceado em AZ com *number-tasks* tarefas na *Zona de disponibilidade 1*, *number-tasks* na *Zona de disponibilidade 2* e *number-tasks* na *Zona de disponibilidade 3*.](service-rebalancing-event-messages-list.md#service-rebalancing-completed) | | TASKS\$1STARTED | O Amazon ECS inicia com êxito tarefas como parte da operação de rebalanceamento das zonas de disponibilidade | INFORMAÇÕES | [O *service-name* iniciou *number-tasks* tarefas na *Zona de disponibilidade* para rebalancear AZ: *task-ids*.](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-started) | | TASKS\$1STOPPED | O Amazon ECS interrompeu com êxito tarefas como parte da operação de rebalanceamento de zonas de disponibilidade | INFORMAÇÕES | [O *service-name* interrompeu *number-tasks* tarefas na *Zona de disponibilidade* devido ao rebalanceamento de AZ: *task-id*.](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-stopped) | | SERVICE\$1TASK\$1PLACEMENT\$1FAILURE | O Amazon ECS falhou ao iniciar uma tarefa como parte da operação de rebalanceamento de zonas de disponibilidade | ERRO | Para o EC2, consulte [O serviço (*service-name*) não conseguiu colocar uma tarefa na *Zona de disponibilidade* porque nenhuma instância de contêiner atendeu a todos os requisitos.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure-instance) Para o Fargate, consulte [O serviço (*service-name*) não conseguiu colocar uma tarefa na *Zona de disponibilidade*.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure) | | TASKSET\$1SCALE\$1IN\$1FAILURE\$1BY\$1TASK\$1PROTECTION | A operação de rebalanceamento de zonas de disponibilidade está bloqueada porque a proteção de tarefas está em uso. | INFORMAÇÕES | [O serviço (*service-name*) não conseguiu fazer o rebalanceamento de AZ porque não foi possível escalar *task-set-name* devido a *reason*.](service-rebalancing-event-messages-list.md#service-rebalancing-task-protection-failure) | | SERVICE\$1REBALANCING\$1STOPPED | A operação de rebalanceamento de zonas de disponibilidade foi interrompida. O Amazon ECS envia eventos adicionais que fornecem mais informações. | INFORMAÇÕES | [O serviço (*service-name*) interrompeu o rebalanceamento de AZ.](service-rebalancing-event-messages-list.md#service-rebalancing-operation-stopped) | ## Eventos de alteração no estado da tarefa O Amazon ECS envia um evento de alteração de estado da tarefa (`START`) para cada tarefa que inicia como parte do processo de rebalanceamento. O Amazon ECS envia um evento de alteração de estado da tarefa (`STOPPED`) para cada tarefa que interrompe como parte do processo de rebalanceamento. O motivo é definido como `Availability-zone rebalancing initiated by (deployment ecs-svc/deployment-id)`. Para obter mais informações sobre eventos, consulte [Eventos de alteração de estado de tarefa do Amazon ECS](ecs_task_events.md). ## Solução de problemas de rebalanceamento de serviços Se você encontrar problemas com o rebalanceamento do serviço, considere as seguintes etapas de solução de problemas: O rebalanceamento não inicia Verificar se: + O rebalanceamento de serviço está habilitado para seu serviço + Seu serviço usa uma configuração compatível (consulte [Considerações para configurar o rebalanceamento de zonas de disponibilidade](#service-rebalancing-configurations)) + Seu serviço atingiu um estado estável Falhas no posicionamento de tarefas durante o rebalanceamento Se você vir eventos `SERVICE_TASK_PLACEMENT_FAILURE`: + No EC2: verifique se você tem instâncias de contêineres disponíveis na zona de disponibilidade de destino + No Fargate: verifique se há restrições de recursos ou de cotas de serviço limitando o posicionamento de tarefas + Revise suas restrições de posicionamento de tarefas para garantir que elas não estejam impedindo a distribuição adequada de tarefas O rebalanceamento é interrompido inesperadamente Se você vir eventos `SERVICE_REBALANCING_STOPPED`: + Verifique a proteção de tarefa que pode estar bloqueando a operação + Procure implantações simultâneas de serviços que possam interromper o rebalanceamento + Analise os eventos do serviço para obter informações adicionais sobre por que o rebalanceamento foi interrompido ## Práticas recomendadas para rebalanceamento de serviços Siga estas práticas recomendadas para aproveitar ao máximo o rebalanceamento de serviços: + **Monitore as operações de rebalanceamento**: configure os alarmes do CloudWatch para monitorar eventos de serviço relacionados ao rebalanceamento e identificar rapidamente quaisquer problemas. + **Considere o impacto na performance**: esteja ciente de que as operações de rebalanceamento podem aumentar temporariamente o uso de recursos à medida que novas tarefas são iniciadas antes que as antigas sejam interrompidas. + **Use a proteção de tarefas estrategicamente**: se você tiver tarefas críticas que não devem ser encerradas durante o rebalanceamento, considere usar a proteção de tarefas. + **Planeje a capacidade do EC2**: no EC2, garanta que você tenha instâncias de contêineres suficientes em todas as zonas de disponibilidade para dar suporte a um rebalanceamento eficaz. + **Teste o comportamento de rebalanceamento**: antes de confiar no rebalanceamento na produção, teste como seus serviços se comportam durante as operações de rebalanceamento em um ambiente que não seja de produção. # Uso do balanceamento de carga para distribuir o tráfego de serviço do Amazon ECS O serviço Amazon ECS pode ser configurado opcionalmente para usar o Elastic Load Balancing para distribuir tráfego entre as tarefas do serviço igualmente. **nota** Quando você usa conjuntos de tarefas, todas as tarefas do conjunto devem ser configuradas para usar o Elastic Load Balancing ou para não usar o Elastic Load Balancing. Os serviços do Amazon ECS hospedados no AWS Fargate oferecem suporte a Application Load Balancers, Network Load Balancers e Gateway Load Balancers. Use a tabela apresentada a seguir para descobrir qual tipo de balanceador de carga usar. | Tipo de balanceador de carga | Uso para estes casos | | --- | --- | | Application Load Balancer | Roteamento do tráfego HTTP/HTTPS (ou da camada 7).Os application load balancers oferecem vários recursos que os tornam atrativos para uso com serviços do Amazon ECS: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-load-balancing.html) | | Network Load Balancer | Roteamento do tráfego TCP ou UDP (ou da camada 4). | | Balanceador de carga de gateway | Roteamento do tráfego TCP ou UDP (ou da camada 4). Use dispositivos virtuais, como firewalls, sistemas de detecção e prevenção de intrusão e sistemas de inspeção profunda de pacotes. | Recomendamos usar Application Load Balancers nos serviços do Amazon ECS para aproveitar os recursos mais recentes, a menos que seu serviço exija um recurso que esteja disponível apenas com Network Load Balancers ou Gateway Load Balancers. Para obter mais informações sobre Elastic Load Balancing e as diferenças entre esses tipos de balanceadores de carga, consulte o [Guia do usuário do Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/). Com o load balancer, você paga somente pelo que utilizar. Para obter mais informações, consulte [Preço do Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/pricing/). # Otimização dos parâmetros de verificação de integridade do balanceador de carga para o Amazon ECS Os balanceadores de carga encaminham solicitações apenas para os destinos íntegros nas zonas de disponibilidade do balanceador de carga. Cada destino é registrado em um grupo de destino. O balanceador de carga verifica a integridade de cada destino usando as configurações de verificação de integridade do grupo de destino. Após você registrar o destino, ele deverá ser aprovado por uma verificação de integridade para ser considerado íntegro. O Amazon ECS realiza o monitoramento do balanceador de carga. O balanceador de carga envia periodicamente verificações de integridade para o contêiner do Amazon ECS. O agente do Amazon ECS monitora e aguarda que o balanceador de carga informe sobre a integridade do contêiner. Ele faz isso antes de considerar que o contêiner está em um estado íntegro. Dois parâmetros de verificação de integridade do Elastic Load Balancing afetam a velocidade de implantação: + Intervalo da verificação de integridade: determina o tempo aproximado, em segundos, entre verificações de integridade de um contêiner individual. Por padrão, o balanceador de carga verifica a cada 30 segundos. Esse parâmetro é denominado: + `HealthCheckIntervalSeconds` na API do Elastic Load Balancing + **Intervalo** no console do Amazon EC2 + Contagem de limites íntegros: determina o número de verificações de integridade consecutivas bem-sucedidas necessárias para que um contêiner não íntegro seja considerado íntegro. Por padrão, o balanceador de carga exige cinco verificações de integridade aprovadas antes de informar que o contêiner de destino está íntegro. Esse parâmetro é denominado: + `HealthyThresholdCount` na API do Elastic Load Balancing + **Limite íntegro** no console do Amazon EC2 **Importante:** para destinos recém-registrados, é necessária apenas uma verificação de integridade bem-sucedida para considerar o destino íntegro, independentemente da configuração da contagem de limiar de integridade. A contagem de limiar de integridade só se aplica quando um destino estiver fazendo a transição de um estado não íntegro para um estado íntegro. Com as configurações padrão, se um destino perder a integridade e então se recuperar, o tempo total para determinar a integridade de um contêiner será de 2 minutos e 30 segundos (`30 seconds * 5 = 150 seconds`). Você pode acelerar o processo de verificação de integridade se o serviço for inicializado e estabilizado em menos de 10 segundos. Para acelerar o processo, reduza o intervalo de verificação de integridade e a contagem de limite de integridade. + `HealthCheckIntervalSeconds` (nome da API do Elastic Load Balancing) ou **Intervalo** (nome do console do Amazon EC2): 5 + `HealthyThresholdCount` (nome da API do Elastic Load Balancing) ou **Limite íntegro** (nome do console do Amazon EC2): 2 Com essa configuração, o processo de verificação de integridade leva 10 segundos quando comparado ao padrão de 2 minutos e 30 segundos. Para obter mais informações sobre os parâmetros de verificação de integridade do Elastic Load Balancing, consulte [Health checks for your target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) no *Guia do usuário do Elastic Load Balancing*. # Otimização de parâmetros de drenagem da conexão do balanceador de carga para o Amazon ECS Para permitir a otimização, os clientes mantêm uma conexão keep alive com o serviço de contêiner. Isto permite que solicitações subsequentes desse cliente reutilizem a conexão existente. Quando quiser interromper o tráfego de um contêiner, você notifica o balanceador de carga. O balanceador de carga verifica periodicamente se o cliente fechou a conexão keep-alive. O Amazon ECS monitora o balanceador de carga e aguarda que ele informe que a conexão keep alive está fechada (o destino está em um estado `UNUSED`). A quantidade de tempo que o balanceador de carga aguarda para mover o destino para o estado `UNUSED` equivale ao atraso no cancelamento do registro. Você pode configurar o parâmetro do balanceador de carga a seguir para acelerar as implantações. + `deregistration_delay.timeout_seconds`: 300 (padrão) Quando houver um serviço com um tempo de resposta inferior a 1 segundo, defina o parâmetro com o seguinte valor para que o balanceador de carga espere apenas cinco segundos antes de interromper a conexão entre o cliente e o serviço de backend: + `deregistration_delay.timeout_seconds`: 5 **nota** Não defina o valor como cinco segundos quando tiver um serviço com solicitações de longa duração, como uploads lentos de arquivos ou conexões de fluxo. ## Capacidade de resposta do SIGTERM O Amazon ECS primeiro envia um sinal de parada à tarefa para notificar que a aplicação precisa ser concluída e encerrada. Esse sinal pode ser definido na imagem do contêiner com a instrução STOPSIGNAL e terá como padrão SIGTERM. Em seguida, o Amazon ECS envia uma mensagem de SIGKILL. Quando as aplicações ignoram o SIGTERM, o serviço do Amazon ECS deve esperar para enviar o sinal de SIGKILL antes de encerrar o processo. O tempo que o Amazon ECS espera para enviar a mensagem de SIGKILL é determinado pela seguinte opção de agente do Amazon ECS: + `ECS_CONTAINER_STOP_TIMEOUT`: 30 (padrão) Para obter mais informações sobre o parâmetro do agente de contêiner, consulte [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) no GitHub. Para acelerar o período de espera, defina o parâmetro do agente do Amazon ECS com o seguinte valor: + `ECS_CONTAINER_STOP_TIMEOUT`: 2 Se a aplicação levar mais de um segundo, multiplique o valor por dois e use esse número como valor. Nesse caso, o Amazon ECS aguarda dois segundos para que o contêiner seja desligado e, em seguida, envia uma mensagem de SIGKILL quando a aplicação não é interrompida. Você também pode modificar o código da aplicação para capturar o sinal de SIGTERM e reagir a ele. O seguinte exemplo está em JavaScript: ``` process.on('SIGTERM', function() { server.close(); }) ``` Esse código faz com que o servidor HTTP pare de receber novas solicitações, termine de responder a todas as solicitações em andamento e, em seguida, encerra o processo Node.js porque o loop de eventos não tem nada para fazer. Diante disso, se o processo levar apenas 500 ms para concluir as solicitações em andamento, ele é encerrado mais cedo, sem precisar esperar o tempo limite de encerramento e receber um SIGKILL. # Uso de um Application Load Balancer do Amazon ECS Um Application Load Balancer toma decisões de roteamento na camada da aplicação (HTTP/HTTPS), oferece suporte ao roteamento com base em caminho e pode encaminhar solicitações para uma ou mais portas em cada instância de contêiner no cluster. Os application load balancers oferecem suporte ao mapeamento de porta de host dinâmico. Por exemplo, se a definição de contêiner da tarefa especifica a porta 80 para uma porta de contêiner NGINX e a porta 0 para a porta do host, a porta do host é escolhida dinamicamente com base no intervalo de portas temporário da instância de contêiner (como entre 32768 e 61000 na AMI otimizado para Amazon ECS mais recente). Quando a tarefa é iniciada, o contêiner NGINX é registrado no Application Load Balancer como uma combinação entre o ID da instância e a porta, e o tráfego é distribuído para o ID da instância e para a porta correspondente a esse contêiner. Esse mapeamento dinâmico permite várias tarefas de um único serviço na mesma instância de contêiner. Para obter mais informações, consulte o [Guia do usuário para application load balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/). Para obter informações sobre as práticas recomendadas para a definição de parâmetros a fim de acelerar as implantações, consulte: + [Otimização dos parâmetros de verificação de integridade do balanceador de carga para o Amazon ECS](load-balancer-healthcheck.md) + [Otimização de parâmetros de drenagem da conexão do balanceador de carga para o Amazon ECS](load-balancer-connection-draining.md) Considere o seguinte ao usar Application Load Balancers com o Amazon ECS: + O Amazon ECS exige a função do IAM vinculada ao serviço, que fornece as permissões necessárias para registrar e cancelar o registro de destinos com o balanceador de carga quando as tarefas são criadas e interrompidas. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). + Para serviços em uma configuração somente IPv6, você deve definir o tipo de endereço IP do grupo de destino do Application Load Balancer como `dualstack` ou `dualstack-without-public-ipv4`. + Para serviços com tarefas que usam o modo de rede `awsvpc`, ao criar um grupo de destino para o serviço, é necessário escolher `ip` como o tipo de destino, e não `instance`. Isso ocorre porque as tarefas que usam o modo de rede `awsvpc` estão associadas a uma interface de rede elástica, e não a uma instância do Amazon EC2. + Se o serviço requerer acesso a diversas portas com balanceamento de carga, como a porta 80 e a porta 443 para um serviço HTTP/HTTPS, será possível configurar dois receptores. Um listener é responsável pelo HTTPS que encaminha a solicitação para o serviço e outro listener que é responsável por redirecionar solicitações HTTP para a porta HTTPS apropriada. Para obter mais informações, consulte [Criar um listener no Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-listener.html) no *Guia do usuário dos Application Load Balancers*. + A configuração de sub-rede do load balancer deve incluir todas as zonas de disponibilidade nas quais as instâncias de contêiner residem. + Após você criar um serviço, a configuração do balanceador de carga não poderá ser alterada no Console de gerenciamento da AWS. É possível usar o AWS Copilot, o AWS CloudFormation, a AWS CLI ou o SDK para modificar a configuração do balanceador de carga somente para o controlador de implantação rolling do `ECS`, e não o AWS CodeDeploy azul/verde ou externo. Quando você adiciona, atualiza ou remove uma configuração de balanceador de carga, o Amazon ECS inicia uma nova implantação com a configuração atualizada do Elastic Load Balancing. Isso faz com que as tarefas se registrem e cancelem o registro dos balanceadores de carga. Recomendamos verificar isso em um ambiente de teste antes de atualizar a configuração do Elastic Load Balancing. Para obter informações sobre como modificar a configuração, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) na *Referência da API do Amazon Elastic Container Service*. + Caso a tarefa de um serviço não passe nos critérios de verificação de integridade do balanceador de carga, a tarefa é interrompida e reiniciada. Esse processo continuará até que o serviço alcance o número de tarefas em execução desejadas. + Caso você esteja enfrentando problemas com os serviços habilitados pelo balanceador de carga, consulte [Solução de problemas relacionados aos balanceadores de carga de serviço no Amazon ECS](troubleshoot-service-load-balancers.md). + Ao usar o tipo de destino `instance`, as tarefas e o balanceador de carga devem estar na mesma VPC. Ao usar o tipo de destino `ip`, há suporte para conectividade entre VPCs. + Use um grupo de destino exclusivo para cada serviço. Usar o mesmo grupo de destino para vários serviços pode causar problemas durante a implantação do serviço. + Especifique grupos de destino que estejam associados a um Application Load Balancer. Para obter informações sobre como criar um Application Load Balancer, consulte [Create an Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) em *Application Load Balancers* # Uso de um Network Load Balancer no Amazon ECS Um Network Load Balancer toma decisões de roteamento na camada de transporte (TCP/SSL). Ele pode lidar com milhões de solicitações por segundo. Após o load balancer receber uma conexão, ele seleciona um destino do grupo de destino para a regra padrão usando um algoritmo de roteamento de hash de fluxo. Ele tenta abrir uma conexão TCP para o destino selecionado na porta especificada na configuração do listener. Ele encaminha a solicitação sem modificar os cabeçalhos. Os network load balancers oferecem suporte ao mapeamento de porta de host dinâmico. Por exemplo, se a definição de contêiner da tarefa especifica a porta 80 para uma porta de contêiner NGINX e a porta 0 para a porta do host, a porta do host é escolhida dinamicamente com base no intervalo de portas temporário da instância de contêiner (como entre 32768 e 61000 na AMI otimizado para Amazon ECS mais recente). Quando a tarefa é inicializada, o contêiner NGINX é registrado no Network Load Balancer como uma combinação de ID e porta da instância, e o tráfego é distribuído para o ID e para a porta da instância correspondentes a este contêiner. Esse mapeamento dinâmico permite várias tarefas de um único serviço na mesma instância de contêiner. Para obter mais informações, consulte o [Guia do usuário de network load balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/). Para obter informações sobre as práticas recomendadas para a definição de parâmetros a fim de acelerar as implantações, consulte: + [Otimização dos parâmetros de verificação de integridade do balanceador de carga para o Amazon ECS](load-balancer-healthcheck.md) + [Otimização de parâmetros de drenagem da conexão do balanceador de carga para o Amazon ECS](load-balancer-connection-draining.md) Considere o seguinte ao usar Network Load Balancers com o Amazon ECS: + O Amazon ECS exige a função do IAM vinculada ao serviço, que fornece as permissões necessárias para registrar e cancelar o registro de destinos com o balanceador de carga quando as tarefas são criadas e interrompidas. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). + Não é possível anexar mais de cinco grupos de destino a um serviço. + Para serviços em uma configuração somente IPv6, você deve definir o tipo de endereço IP do grupo de destino do Network Load Balancer como `dualstack`. + Para serviços com tarefas que usam o modo de rede `awsvpc`, ao criar um grupo de destino para o serviço, é necessário escolher `ip` como o tipo de destino, e não `instance`. Isso ocorre porque as tarefas que usam o modo de rede `awsvpc` estão associadas a uma interface de rede elástica, e não a uma instância do Amazon EC2. + A configuração de sub-rede do load balancer deve incluir todas as zonas de disponibilidade nas quais as instâncias de contêiner residem. + Após você criar um serviço, a configuração do balanceador de carga não poderá ser alterada no Console de gerenciamento da AWS. É possível usar o AWS Copilot, o AWS CloudFormation, a AWS CLI ou o SDK para modificar a configuração do balanceador de carga somente para o controlador de implantação rolling do `ECS`, e não o AWS CodeDeploy azul/verde ou externo. Quando você adiciona, atualiza ou remove uma configuração de balanceador de carga, o Amazon ECS inicia uma nova implantação com a configuração atualizada do Elastic Load Balancing. Isso faz com que as tarefas se registrem e cancelem o registro dos balanceadores de carga. Recomendamos verificar isso em um ambiente de teste antes de atualizar a configuração do Elastic Load Balancing. Para obter informações sobre como modificar a configuração, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) na *Referência da API do Amazon Elastic Container Service*. + Caso a tarefa de um serviço não passe nos critérios de verificação de integridade do balanceador de carga, a tarefa é interrompida e reiniciada. Esse processo continuará até que o serviço alcance o número de tarefas em execução desejadas. + Ao usar um Gateway Load Balancer configurado com endereços IP como destinos e a Preservação do IP do Cliente desativada, as solicitações parecem se originar do endereço IP privado do Gateway Load Balancers. Isso significa que, ao permitir solicitações de entrada e verificações de integridade no grupo de segurança de destino, os serviços protegidos por um Gateway Load Balancer ficam efetivamente expostos. + Para tarefas do Fargate, você deve usar a versão da plataforma `1.4.0` (Linux) ou `1.0.0` (Windows). + Caso você esteja enfrentando problemas com os serviços habilitados pelo balanceador de carga, consulte [Solução de problemas relacionados aos balanceadores de carga de serviço no Amazon ECS](troubleshoot-service-load-balancers.md). + Ao usar o tipo de destino `instance`, as tarefas e o balanceador de carga devem estar na mesma VPC. Ao usar o tipo de destino `ip`, há suporte para conectividade entre VPCs. + A preservação do endereço IP do cliente do Network Load Balancer é compatível com os destinos do Fargate. + Use um grupo de destino exclusivo para cada serviço. Usar o mesmo grupo de destino para vários serviços pode causar problemas durante a implantação do serviço. + Você deve especificar grupos de destino que estejam associados a um Network Load Balancer. Para obter informações sobre como criar um Network Load Balancer, consulte [Create a Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) em *Network Load Balancers* **Importante** Se a definição de tarefa do serviço usar o modo de rede `awsvpc` (exigido para o Fargate), será preciso escolher `ip` como tipo de destino, e não `instance`. Isso ocorre porque as tarefas que usam o modo de rede `awsvpc` estão associadas a uma interface de rede elástica, e não a uma instância do Amazon EC2. Você não pode registrar instâncias por ID de instância se eles tiverem os seguintes tipos de instância: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3 e T1. É possível registrar instâncias desses tipos por endereço IP. # Uso de um Gateway Load Balancer para o Amazon ECS Um balanceador de carga de gateway opera na terceira camada do modelo Open Systems Interconnection (OSI), a camada de rede. Ele escuta todos os pacotes IP em todas as portas e encaminha o tráfego para o grupo de destino especificado na regra do listener. Ele mantém a perdurabilidade dos fluxos para um dispositivo de destino específico usando 5 tuplas (para fluxos TCP/UDP) ou 3 tuplas (para fluxos não TCP/UDP). Por exemplo, se a definição de contêiner da tarefa especifica a porta 80 para uma porta de contêiner NGINX e a porta 0 para a porta do host, a porta do host é escolhida dinamicamente com base no intervalo de portas temporário da instância de contêiner (como entre 32768 e 61000 na AMI otimizado para Amazon ECS mais recente). Quando a tarefa é iniciada, o contêiner NGINX é registrado no Gateway Load Balancer como uma combinação entre o ID da instância e a porta, e o tráfego é distribuído para o ID da instância e para a porta correspondente a esse contêiner. Esse mapeamento dinâmico permite várias tarefas de um único serviço na mesma instância de contêiner. Para obter mais informações, consulte [What is a Gateway Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html) em *Gateway Load Balancers*. Para obter informações sobre as práticas recomendadas para a definição de parâmetros a fim de acelerar as implantações, consulte: + [Otimização dos parâmetros de verificação de integridade do balanceador de carga para o Amazon ECS](load-balancer-healthcheck.md) + [Otimização de parâmetros de drenagem da conexão do balanceador de carga para o Amazon ECS](load-balancer-connection-draining.md) Considere o seguinte ao usar Gateway Load Balancers com o Amazon ECS: + O Amazon ECS exige a função do IAM vinculada ao serviço, que fornece as permissões necessárias para registrar e cancelar o registro de destinos com o balanceador de carga quando as tarefas são criadas e interrompidas. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). + Para serviços em uma configuração somente IPv6, você deve definir o tipo de endereço IP do grupo de destino do Gateway Load Balancer como `dualstack`. + Balanceadores de carga de gateway não são compatíveis com serviços com tarefas que não usam `awsvpc`, mas outro modo de rede. + A configuração de sub-rede do load balancer deve incluir todas as zonas de disponibilidade nas quais as instâncias de contêiner residem. + Após você criar um serviço, a configuração do balanceador de carga não poderá ser alterada no Console de gerenciamento da AWS. É possível usar o AWS Copilot, o AWS CloudFormation, a AWS CLI ou o SDK para modificar a configuração do balanceador de carga somente para o controlador de implantação rolling do `ECS`, e não o AWS CodeDeploy azul/verde ou externo. Quando você adiciona, atualiza ou remove uma configuração de balanceador de carga, o Amazon ECS inicia uma nova implantação com a configuração atualizada do Elastic Load Balancing. Isso faz com que as tarefas se registrem e cancelem o registro dos balanceadores de carga. Recomendamos verificar isso em um ambiente de teste antes de atualizar a configuração do Elastic Load Balancing. Para obter informações sobre como modificar a configuração, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) na *Referência da API do Amazon Elastic Container Service*. + Caso a tarefa de um serviço não passe nos critérios de verificação de integridade do balanceador de carga, a tarefa é interrompida e reiniciada. Esse processo continuará até que o serviço alcance o número de tarefas em execução desejadas. + Ao usar um Gateway Load Balancer configurado com endereços IP como destinos, as solicitações parecem se originar do endereço IP privado do Gateway Load Balancers. Isso significa que, ao permitir solicitações de entrada e verificações de integridade no grupo de segurança de destino, os serviços protegidos por um Gateway Load Balancer ficam efetivamente expostos. + Para tarefas do Fargate, você deve usar a versão da plataforma `1.4.0` (Linux) ou `1.0.0` (Windows). + Caso você esteja enfrentando problemas com os serviços habilitados pelo balanceador de carga, consulte [Solução de problemas relacionados aos balanceadores de carga de serviço no Amazon ECS](troubleshoot-service-load-balancers.md). + Ao usar o tipo de destino `instance`, as tarefas e o balanceador de carga devem estar na mesma VPC. Ao usar o tipo de destino `ip`, há suporte para conectividade entre VPCs. + Use um grupo de destino exclusivo para cada serviço. Usar o mesmo grupo de destino para vários serviços pode causar problemas durante a implantação do serviço. + Você deve especificar grupos de destino associados a um Gateway Load Balancer. Para obter informações sobre como criar um Gateway Load Balancer, consulte [Introdução a Gateway Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html) em *Gateway Load Balancers* **Importante** Se a definição de tarefa do serviço usar o modo de rede `awsvpc` (exigido para o Fargate), será preciso escolher `ip` como tipo de destino, e não `instance`. Isso ocorre porque as tarefas que usam o modo de rede `awsvpc` estão associadas a uma interface de rede elástica, e não a uma instância do Amazon EC2. Você não pode registrar instâncias por ID de instância se eles tiverem os seguintes tipos de instância: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3 e T1. É possível registrar instâncias desses tipos por endereço IP. # Registrar vários grupos de destino em um serviço Amazon ECS O serviço do Amazon ECS pode atender ao tráfego de vários balanceadores de carga e expor várias portas com balanceamento de carga quando você especificar vários grupos de destino em uma definição de serviço. Para criar um serviço que especifique vários grupos de destino, é necessário criar o serviço usando a API do Amazon ECS, o SDK, a AWS CLI ou um modelo do CloudFormation. Depois que o serviço é criado, você pode visualizar o serviço e os grupos de destino registrados nele com o Console de gerenciamento da AWS. Você deve usar `[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)` para modificar a configuração do balanceador de carga de um serviço existente. Vários grupos de destino podem ser especificados em uma definição de serviço usando o seguinte formato. Para obter a sintaxe completa de uma definição de serviço, consulte [Modelo de definição de serviço](sd-template.md). ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"container_name", "containerPort":container_port }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"container_name", "containerPort":container_port } ] ``` ## Considerações Quando você especificar vários grupos de destino em uma definição de serviço, considere o seguinte. + Para serviços que usam um Application Load Balancer ou um Network Load Balancer, não é possível anexar mais de cinco grupos de destino a um serviço. + Especificar vários grupos de destino em uma definição de serviço só é compatível com as seguintes condições: + O serviço deve usar um Application Load Balancer ou um Network Load Balancer. + O serviço deve usar o tipo de controlador de implantação (`ECS`). Isso pode ser a implantação nativa/azul verde do Amazon ECS ou a implantação de atualização contínua. + Especificar vários grupos de destino é compatível com serviços que contêm tarefas que usam os tipos de inicialização do Fargate e do EC2. + Quando você criar um serviço que especifica vários grupos de destino, deverá ser criada a função vinculada ao serviço do Amazon ECS. A função é criada omitindo o parâmetro `role` nas solicitações de API ou a propriedade `Role` no CloudFormation. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). ## Exemplos de definições de serviço Veja a seguir alguns exemplos de casos de uso para especificar vários grupos de destino em uma definição de serviço. Para obter a sintaxe completa de uma definição de serviço, consulte [Modelo de definição de serviço](sd-template.md). ### Ter balanceadores de carga separados para tráfego interno e externo No seguinte caso de uso, um serviço usa dois load balancers, um para tráfego interno e um segundo para tráfego voltado para a Internet, para o mesmo contêiner e porta. ``` "loadBalancers":[ //Internal ELB { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"nginx", "containerPort":8080 }, //Internet-facing ELB { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"nginx", "containerPort":8080 } ] ``` ### Expor várias portas do mesmo contêiner No seguinte caso de uso, um serviço usa um load balancer, mas expõe várias portas do mesmo contêiner. Por exemplo, um contêiner Jenkins pode expor a porta 8080 para a interface da Web do Jenkins e a porta 50000 para a API. ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"jenkins", "containerPort":8080 }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"jenkins", "containerPort":50000 } ] ``` ### Expor portas de vários contêineres No seguinte caso de uso, um serviço usa um load balancer e dois grupos de destino para expor portas de contêineres separados. ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"webserver", "containerPort":80 }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"database", "containerPort":3306 } ] ``` # Como escalar automaticamente o serviço do Amazon ECS *Escalabilidade automática* é a capacidade de aumentar ou diminuir automaticamente o número de tarefas desejadas no serviço do Amazon ECS. O Amazon ECS utiliza o serviço do Application Auto Scaling para fornecer essa funcionalidade. Para obter mais informações, consulte o [Guia do usuário do Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). O Amazon ECS publica métricas do CloudWatch com o uso médio, pelo serviço, da CPU e da memória. Para obter mais informações, consulte [Métricas de utilização do serviço do Amazon ECS](service_utilization.md). É possível usar essas e outras métricas do CloudWatch para expandir o serviço (adicionar mais tarefas) para lidar com alta demanda em horários de pico e para reduzir o serviço (executar menos tarefas) de modo a reduzir os custos durante períodos de baixa utilização. O Auto Scaling do serviço do Amazon ECS oferece suporte aos seguintes tipos de escalabilidade automática: + [Use uma métrica de destino para escalar os serviços do Amazon ECS](service-autoscaling-targettracking.md): aumenta ou diminui o número de tarefas que o serviço executa com base em um valor de destino para uma métrica específica. Isso é semelhante à forma como o termostato mantém a temperatura da casa. Você seleciona a temperatura, e o termostato faz o resto. + [Usar incrementos predefinidos com base em alarmes do CloudWatch para ajustar a escala de serviços do Amazon ECS](service-autoscaling-stepscaling.md): aumenta ou diminui o número de tarefas que o serviço executa com base em um conjunto de ajustes de escalabilidade, conhecidos como ajustes em etapas, que variam conforme o tamanho da violação do alarme. + [Usar ações programadas para escalar os serviços do Amazon ECS](service-autoscaling-schedulescaling.md): aumenta ou diminui o número de tarefas que o serviço executa com base na data e hora. + [Usar padrões históricos para escalar os serviços do Amazon ECS com escalabilidade preditiva](predictive-auto-scaling.md): aumenta ou diminui o número de tarefas que o serviço executa com base em data analytics da carga histórica para detectar padrões diários ou semanais nos fluxos de tráfego. ## Considerações Ao usar políticas de escalabilidade, considere o seguinte: + O Amazon ECS envia dados de métricas ao CloudWatch em intervalos de um minuto. As métricas não estarão disponíveis até que os clusters e os serviços enviem as métricas para o CloudWatch, e você não poderá criar alarmes do CloudWatch para métricas não existentes. + As políticas de escalabilidade são compatíveis com um período de desaquecimento. Esse é o número de segundos para esperar que uma ação de escalabilidade anterior entre em vigor. + Para eventos de aumento, a intenção é aumentar de forma contínua (mas não excessiva). Depois que o Auto Scaling do serviço é expandido com êxito usando uma política de escalabilidade, ele começará a calcular o tempo de desaquecimento. A política de escalabilidade não aumentará novamente a capacidade desejada, a menos que um aumento da escala horizontalmente seja iniciado ou que o período de esfriamento termine. Enquanto o período de desaquecimento após expansão estiver em vigor, a capacidade adicionada pela ação de expansão de início será calculada como parte da capacidade desejada para a próxima ação de expansão. + Para eventos de redução, a intenção é reduzir de forma conservadora para proteger a disponibilidade da aplicação, de modo que as ações de redução sejam bloqueadas até que o período de desaquecimento tenha expirado. Porém, se outro alarme acionar uma ação de aumento da escala na horizontal durante o período de esfriamento da redução da escala na horizontal, o Service Auto Scaling aumentará a escala horizontalmente do destino imediatamente. Nesse caso, o período de desaquecimento após redução é interrompido e não é concluído. + O programador de serviço respeita a contagem desejada em todos os momentos, mas desde que você tenha políticas de escalabilidade e alarmes ativos em um serviço, o Auto Scaling do serviço pode alterar uma contagem desejada que você definiu manualmente. + Se a contagem desejada de um serviço estiver definida abaixo do valor de capacidade mínimo e um alarme acionar uma atividade de aumento horizontal de escala, o Auto Scaling do serviço aumenta a escala da contagem desejada até o valor de capacidade mínimo e continua aumentando conforme necessário, com base na política de ajuste de escala associada ao alarme. Porém, uma atividade de redução não ajusta a contagem desejada, pois ela já está abaixo do valor mínimo de capacidade. + Se a contagem desejada de um serviço for definida acima do valor máximo de capacidade e um alarme acionar uma atividade de redução de escala, o Auto Scaling do serviço aumenta a contagem desejada até o valor máximo de capacidade e continua a reduzir conforme necessário, com base na política de ajuste de escala associada ao alarme. Porém, uma atividade de expansão não ajusta a contagem desejada, pois ela já está acima do valor máximo de capacidade. + Durante ações de escalabilidade, a contagem real de tarefas em execução em um serviço é o valor que o Auto Scaling do serviço usa como ponto de partida, ao contrário da contagem desejada. Esta deve ser a capacidade de processamento. Isso evita a escalabilidade excessiva (sem controle) que não pode ser atendida, por exemplo, caso não haja recursos de instância de contêiner suficientes para colocar as tarefas adicionais. Se a capacidade da instância de contêiner estiver disponível depois, a ação de escalabilidade pendente poderá continuar, e as ações de escalabilidade adicionais poderão continuar depois do período de desaquecimento. + Se quiser que a contagem de tarefas seja dimensionada em zero quando não houver trabalho a ser feito, defina uma capacidade mínima de 0. Com políticas de dimensionamento com monitoramento do objetivo, quando a capacidade real é 0 e a métrica indica que há demanda de workload, o Auto Scaling do serviço aguarda o envio de um ponto de dados antes da expansão. Nesse caso, ele é expandido pela quantidade mínima possível como ponto de partida e, em seguida, retoma a escalabilidade com base na contagem real de tarefas em execução. + O Application Auto Scaling desativa processos de redução da escala na horizontal enquanto as implantações do Amazon ECS estão em andamento. No entanto, processos de aumento continuam a ocorrer, a menos que sejam suspensos, durante uma implantação. Esse comportamento não se aplica aos serviços do Amazon ECS usando o controlador de implantação externo. Para obter mais informações, consulte [Escalabilidade automática e implantações do serviço](#service-auto-scaling-deployments). + Você tem várias opções de ajuste de escala automático de aplicação para tarefas do Amazon ECS. O rastreamento de destinos é o modo mais fácil de usar. Com isso, tudo o que você precisa fazer é definir um valor de destino para uma métrica, como a utilização média da CPU. Em seguida, o escalador automático gerencia automaticamente o número de tarefas necessárias para atingir esse valor. Com a escalabilidade por etapas, é possível reagir mais rapidamente às mudanças na demanda, pois define os limites específicos para suas métricas de escalabilidade e quantas tarefas adicionar ou remover quando os limites são ultrapassados. E, o mais importante, é possível reagir rapidamente às mudanças na demanda minimizando a quantidade de tempo em que um alarme de limite é violado. Para obter mais informações sobre as práticas recomendadas para o ajuste de escala automático do serviço, consulte [Otimização do ajuste de escala automático de serviços do Amazon ECS](capacity-autoscaling-best-practice.md). ## Escalabilidade automática e implantações do serviço O Application Auto Scaling desativa processos de redução da escala na horizontal enquanto as implantações do Amazon ECS estão em andamento. No entanto, processos de aumento continuam a ocorrer, a menos que sejam suspensos, durante uma implantação. Esse comportamento não se aplica aos serviços do Amazon ECS usando o controlador de implantação externo. Se você quiser suspender processos de aumento enquanto as implantações estiverem em andamento, siga as etapas a seguir. 1. Chame o comando [describe-scalable-targets](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scalable-targets.html), especificando o ID do recurso do serviço associado ao destino escalável no Application Auto Scaling (Exemplo: `service/default/sample-webapp`). Registre a saída. Você precisará dela quando chamar o próximo comando. 1. Chame o comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html), especificando o ID, o namespace e a dimensão escalável do recurso. Especifique `true` para `DynamicScalingInSuspended` e `DynamicScalingOutSuspended`. 1. Depois que a implantação estiver concluída, será possível chamar o comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) para retomar a escalabilidade. Para obter mais informações, consulte [Suspender e retomar a escalabilidade do Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html). # Use uma métrica de destino para escalar os serviços do Amazon ECS Com as políticas de dimensionamento com monitoramento do objetivo, você seleciona uma métrica e define um valor pretendido. O Amazon ECS Service Auto Scaling cria e gerencia os alarmes do CloudWatch que controla a política de escalabilidade e calcula o ajuste da escalabilidade com base na métrica e no valor de destino. A política de escalabilidade adiciona ou remove tarefas de serviço conforme necessário para manter a métrica no valor de destino especificado ou próxima a ele. Além de manter a métrica próxima ao valor de destino, uma política de escalabilidade de rastreamento de destino também se ajusta às flutuações na métrica, devido a um padrão de carga de flutuação, e minimiza as flutuações rápidas no número de tarefas que estão sendo executadas no serviço. As políticas de rastreamento de destinos eliminam a necessidade de definir manualmente os alarmes e os ajustes de escalabilidade do CloudWatch. O Amazon ECS lida com isso automaticamente com base no destino definido. Considere os fatores a seguir quando usar políticas de rastreamento de destino: + Uma política de escalabilidade de rastreamento de destino pressupõe que ela deve aumentar a escalabilidade quando a métrica especificada estiver acima do valor de destino. Você não pode usar uma política de escalabilidade de rastreamento de destino para expandir quando a métrica especificada estiver abaixo do valor de destino. + Uma política de escalabilidade de rastreamento de destino não escala quando a métrica especificada tem dados insuficientes. Ela não aumenta a escalabilidade porque não interpreta dados insuficientes como baixa utilização. + É possível ver lacunas entre o valor de destino e os pontos de dados de métrica reais. Isso ocorre porque o Auto Scaling do serviço sempre atua de forma conservadora, ao arredondar para cima ou para baixo ao determinar a capacidade a ser adicionada ou removida. Isso evita que ele adicione capacidade insuficiente ou remova muita capacidade. + Para garantir a disponibilidade do aplicativo, o serviço se expande proporcionalmente à métrica o mais rápido possível, mas é reduzido gradualmente. + O Application Auto Scaling desativa processos de redução da escala na horizontal enquanto as implantações do Amazon ECS estão em andamento. No entanto, processos de aumento continuam a ocorrer, a menos que sejam suspensos, durante uma implantação. Esse comportamento não se aplica aos serviços do Amazon ECS usando o controlador de implantação externo. Para obter mais informações, consulte [Escalabilidade automática e implantações do serviço](service-auto-scaling.md#service-auto-scaling-deployments). + É possível ter várias políticas de dimensionamento com monitoramento do objetivo para um serviço do Amazon ECS, desde que cada uma delas use uma métrica diferente. A intenção do Auto Scaling do serviço é sempre priorizar a disponibilidade. Portanto, seu comportamento será diferente, dependendo de as políticas de monitoramento do objetivo estarem prontas para aumento ou redução. Ele vai aumentar a escala do serviço horizontalmente se qualquer uma das políticas de rastreamento de destino estiver pronta para aumentar a escala horizontalmente, mas só vai reduzir a escala horizontalmente se todas as políticas de monitoramento de destino (com a parte da redução da escala horizontalmente ativada) estiverem prontas para reduzir a escala horizontalmente. + Não edite nem exclua os alarmes do CloudWatch que o Auto Scaling do serviço gerencia para uma política de dimensionamento com monitoramento do objetivo. O Auto Scaling do serviço exclui os alarmes automaticamente quando você exclui a política de dimensionamento. + A métrica `ALBRequestCountPerTarget` para as políticas de dimensionamento de monitoramento de destinos não é compatível com o tipo de implantação azul/verde. Para obter mais informações sobre políticas de escalabilidade de rastreamento de destino, consulte [Políticas de escalabilidade de rastreamento de destino](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) no *Guia do usuário do Application Auto Scaling*. # Criar uma política de escalabilidade de rastreamento de destino para ajuste de escala automático do serviço do Amazon ECS Crie uma política de escalabilidade de rastreamento de destino para que o Amazon ECS aumente ou diminua automaticamente a contagem de tarefas desejadas em seu serviço. O rastreamento de destino funciona a partir de um valor métrico de destino. ## Console 1. Além das permissões padrão do IAM para criar e atualizar serviços, você precisa de permissões adicionais. Para obter mais informações, consulte [Permissões obrigatórias do IAM para o ajuste de escala automático do serviço Amazon ECS](auto-scaling-IAM.md). 1. Determine as métricas a serem usadas para a política. As seguintes métricas estão disponíveis: + **ECSServiceAverageCPUUtilization**: utilização média da CPU que o serviço deveria usar. + **ECSServiceAverageMemoryUtilization**: utilização média da memória que o serviço deveria usar. + **ALBRequestCountPerTarget**: o número médio de solicitações por minuto que a tarefa deve idealmente receber. 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. Escolha **Definir o número de tarefas**. 1. Em **Contagem de tarefas do serviço do Amazon ECS**, escolha **Usar ajuste de escala automático**. A seção **Contagem de tarefas** é exibida. 1. Em **Número mínimo de tarefas**, insira o limite inferior do número de tarefas a serem usadas pelo ajuste de escala automático. A contagem desejada não será inferior a essa contagem. 1. Em **Máximo**, insira o limite superior do número de tarefas a serem usadas pelo ajuste de escala automático. A contagem desejada não ultrapassará essa contagem. 1. Escolha **Salvar**. A página de políticas será exibida. 1. Escolha **Criar política de escalabilidade**. A página **Criar política** é exibida. 1. Em **Scaling policy type** (Tipo de política de escalabilidade), escolha **Target tracking** (Rastreamento de destino). 1. Em **Policy name** (Nome da política), insira o nome da política. 1. Em **Tipo de métrica**, escolha suas métricas na lista de opções. 1. Em **Utilização pretendida**, insira o valor desejado para o percentual de tarefas que o Amazon ECS deve manter. O ajuste de escala automático do serviço expandirá sua capacidade até que a utilização média seja igual à utilização pretendida ou até atingir o número máximo de tarefas especificado. 1. Em **Configurações adicionais**, faça o seguinte 1. Em **Período de espera após reduzir a escala horizontalmente**, insira a quantidade de tempo em segundos após a conclusão de uma ação de redução antes que uma outra atividade de redução possa iniciar. 1. Em **Período de espera após aumentar a escala horizontalmente**, insira a quantidade de tempo em segundos para aguardar que uma atividade de ajuste de escala anterior entre em vigor. 1. Para criar somente uma política de aumento da escala horizontal, selecione **Desabilitar a ação de redução**. 1. Escolha **Criar política de escalabilidade**. ## AWS CLI 1. Registre seu serviço do Amazon ECS como um destino escalável usando o comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html). 1. Crie uma política de escalabilidade usando o comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html). # Usar incrementos predefinidos com base em alarmes do CloudWatch para ajustar a escala de serviços do Amazon ECS Com as políticas de escalabilidade em etapas, é possível criar e gerenciar os alarmes do CloudWatch que invocam o processo de escalabilidade. Quando um alarme é violado, o Amazon ECS inicia a política de escalabilidade associada a esse alarme. A política de escalabilidade em etapas escala as tarefas usando um conjunto de ajustes conhecido como ajustes em etapas. A dimensão dos ajustes varia de acordo com a magnitude da violação do alarme. + Se a violação exceder o primeiro limite, o Amazon ECS aplicará o primeiro ajuste em etapa. + Se a violação exceder o segundo limite, o Amazon ECS aplicará o segundo ajuste em etapa, e assim por diante. É altamente recomendável usar uma política de escalabilidade de rastreamento de destino para escalar métricas, como utilização média de CPU ou contagem média de solicitações por destino. Métricas que diminuem quando a capacidade aumenta e aumentam quando a capacidade diminui podem ser usadas para aumentar ou reduzir a escala do número de tarefas proporcionalmente usando o rastreamento de destino. Isso ajuda a garantir que o Amazon ECS siga estritamente a curva de demanda para seus aplicativos. # Criar uma política de escalabilidade em etapas para ajuste de escala automático do serviço do Amazon ECS Crie uma política de escalabilidade em etapas para que o Amazon ECS aumente ou diminua automaticamente o número desejado de tarefas em seu serviço. A escalabilidade em etapas é executada com base em um conjunto de ajustes de escalabilidade, conhecidos como ajustes em etapas, que variam com base no tamanho da ruptura do alarme. ## Console 1. Além das permissões padrão do IAM para criar e atualizar serviços, você precisa de permissões adicionais. Para obter mais informações, consulte [Permissões obrigatórias do IAM para o ajuste de escala automático do serviço Amazon ECS](auto-scaling-IAM.md). 1. Determine as métricas a serem usadas para a política. As seguintes métricas estão disponíveis: + **ECSServiceAverageCPUUtilization**: utilização média da CPU que o serviço deveria usar. + **ECSServiceAverageMemoryUtilization**: utilização média da memória que o serviço deveria usar. + **ALBRequestCountPerTarget**: o número médio de solicitações por minuto que a tarefa deve idealmente receber. 1. Crie um alarme do CloudWatch para as métricas. Para obter mais informações, consulte [Criar um alarme do CloudWatch com base em um limite estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) no *Guia do usuário do Amazon CloudWatch*. 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. Escolha **Definir o número de tarefas**. 1. Em **Contagem de tarefas do serviço do Amazon ECS**, escolha **Usar ajuste de escala automático**. A seção **Contagem de tarefas** é exibida. 1. Em **Número mínimo de tarefas**, insira o limite inferior do número de tarefas a serem usadas pelo ajuste de escala automático. A contagem desejada não será inferior a essa contagem. 1. Em **Máximo**, insira o limite superior do número de tarefas a serem usadas pelo ajuste de escala automático. A contagem desejada não ultrapassará essa contagem. 1. Escolha **Salvar**. A página de políticas será exibida. 1. Escolha **Criar política de escalabilidade**. A página **Criar política** é exibida. 1. Em **Tipo de política de escalabilidade**, escolha **Escalabilidade em etapas**. 1. Configure as propriedades de aumentar a escala horizontalmente. Em **Etapas para adicionar tarefas**, faça o seguinte: 1. Em **Policy name** (Nome da política), insira o nome da política. 1. Em **Nome do alarme do CloudWatch**, escolha o alarme do CloudWatch. 1. Em **Tipo de agregação de métrica**, escolha como comparar a métrica selecionada ao limite definido. 1. Em **Tipos de ajuste**, escolha se o ajuste é baseado em uma alteração no número de tarefas ou em uma alteração na porcentagem de tarefas. 1. Em **Ações a serem tomadas**, insira os valores da ação a ser tomada. Escolha **Adicionar etapa** para adicionar outras ações. 1. Configure as propriedades de reduzir a escala horizontalmente. Em **Etapas para remover tarefas**, faça o seguinte: 1. Em **Policy name** (Nome da política), insira o nome da política. 1. Em **Nome do alarme do CloudWatch**, escolha o alarme do CloudWatch. 1. Em **Tipo de agregação de métrica**, escolha como comparar a métrica selecionada ao limite definido. 1. Em **Tipos de ajuste**, escolha se o ajuste é baseado em uma alteração no número de tarefas ou em uma alteração na porcentagem de tarefas. 1. Em **Ações a serem tomadas**, insira os valores da ação a ser tomada. Escolha **Adicionar etapa** para adicionar outras ações. 1. Em **Período de espera**, insira a quantidade de tempo, em segundos, para aguardar que uma atividade de ajuste de escala anterior entre em vigor. Para uma política de adição, esse é o momento após uma atividade de aumento horizontal de escala em que a política de ajuste de escala bloqueia as atividades de redução horizontal de escala e limita quantas tarefas podem ser ampliadas por vez. Para uma política de remoção, esse é o momento após uma atividade de redução horizontal de escala que precisa ser concluída antes que outras atividades do mesmo tipo possam iniciar. 1. Escolha **Criar política de escalabilidade**. ## AWS CLI 1. Registre seu serviço do Amazon ECS como um destino escalável usando o comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html). 1. Crie uma política de escalabilidade usando o comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html). # Usar ações programadas para escalar os serviços do Amazon ECS Com a escalabilidade programada, é possível configurar a escalabilidade automática para a aplicação com base em alterações de carga previsíveis ao criar ações programadas que aumentam ou diminuem o número de tarefas em momentos específicos. Isso permite escalar a aplicação de forma proativa para corresponder às alterações de carga previsíveis. Essas ações de escalabilidade programadas permitem otimizar os custos e a performance. Sua aplicação tem um número de tarefas suficiente para lidar com o pico de tráfego de meio de semana, mas não faz provisionamento excessivo de número de tarefas em outros momentos. É possível usar a escalabilidade programada e as políticas de escalabilidade em conjunto para obter os benefícios de abordagens proativas e reativas para a escalabilidade. Após a execução de uma ação de escalabilidade programada, a política de escalabilidade pode continuar a tomar decisões sobre a necessidade de escalar ainda mais o número de tarefas. Isso ajuda a garantir que você tenha um número de tarefas suficiente para lidar com a carga de sua aplicação. Embora sua aplicação seja escalada para atender à demanda, a capacidade atual deve estar dentro dos números de tarefas mínimo e máximo definidos pela ação programada. Você pode configurar a escala do cronograma usando a AWS CLI. Para obter mais informações sobre o ajuste de escala programado, consulte [Scheduled Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) no *Guia do usuário do Application Auto Scaling*. # Criar uma ação programada para o ajuste de escala automático do serviço do Amazon ECS Crie uma ação programada para fazer com que o Amazon ECS aumente ou diminua o número de tarefas executadas pelo serviço com base na data e na hora. ## Console 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. Escolha **Ajuste de escala automático do serviço**. A página de ajuste de escala automático do serviço é exibida. 1. Se você não configurou a escalabilidade automática do serviço, escolha **Definir o número de tarefas**. A seção **Contagem de tarefas de serviços do Amazon ECS** é exibida. Em **Contagem de tarefas do serviço Amazon ECS**, escolha **Usar ajuste de escala automático do serviço para ajustar a contagem de tarefas desejada do seu serviço**. A seção **Contagem de tarefas** é exibida. 1. Em **Número mínimo de tarefas**, insira o limite inferior do número de tarefas a serem usadas pelo ajuste de escala automático. A contagem desejada não será inferior a essa contagem. 1. Em **Máximo**, insira o limite superior do número de tarefas a serem usadas pelo ajuste de escala automático. A contagem desejada não ultrapassará essa contagem. 1. Escolha **Escolher Salvar**. A página de políticas será exibida. 1. Escolha **Ações programadas** e, em seguida, escolha **Criar**. A página **Criar ação de programação** é exibida. 1. Em **Nome da ação**, insira um nome exclusivo. 1. Em **Time zone** (Fuso horário), escolha um fuso horário. Todos os fusos horários listados são do banco de dados de fuso horário da IANA. Para obter mais informações, consulte a [Lista de fusos horários no banco de dados de FH](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). 1. Em **Hora de início**, insira a **Data** e a **Hora** em que a ação começa. Se você escolher uma programação recorrente, o horário inicial definirá quando a primeira ação programada na série recorrente será executada. 1. Em **Recurrence** (Recorrência), selecione uma das opções disponíveis. + Para escalar em uma programação recorrente, escolha com que frequência o Amazon ECS deverá executar a ação programada. + Se você escolher uma opção que começa com **Taxa**, a expressão cron será criada para você. + Se você escolher **Cron**, insira uma expressão do cron que especifique quando executar a ação, em UTC. + Para escalar apenas uma vez, escolha **Uma vez**. 1. Em **Ajustes de tarefas**, faça o seguinte: + Em **Mínimo**, insira o número mínimo de tarefas que o serviço deve executar. + Em **Máximo**, insira o número máximo de tarefas que o serviço deve executar. 1. Escolha **Criar ação programada**. ## CLI Use o AWS CLI da seguinte maneira para configurar políticas de escalonamento agendado para seu serviço. Substitua cada *espaço reservado para entrada do usuário* por suas próprias informações. **Exemplo: para escalar apenas uma vez** Utilize o seguinte comando [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html) com o `--start-time "YYYY-MM-DDThh:mm:ssZ"` e uma ou ambas as opções `--MinCapacity` e `--MaxCapacity`. ``` aws application-autoscaling put-scheduled-action --service-namespace ecs \ --resource-id service/my-cluster/my-service \ --scheduled-action-name my-one-time-schedule \ --start-time 2021-01-30T12:00:00 \ --scalable-target-action MinCapacity=3,MaxCapacity=10 ``` **Para programar a escalabilidade em uma programação recorrente** Utilize o seguinte comando [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html). Substitua os valores de *user input* pelos seus. ``` aws application-autoscaling put-scheduled-action --service-namespace ecs \ --resource-id service/my-cluster/my-service \ --scheduled-action-name my-recurring-action \ --schedule "rate(5 hours)" \ --start-time 2021-01-30T12:00:00 \ --end-time 2021-01-31T22:00:00 \ --scalable-target-action MinCapacity=3,MaxCapacity=10 ``` O cronograma de recorrência especificado é executado de acordo com o fuso horário UTC. Para especificar um fuso horário diferente, inclua a opção `--time-zone` e especifique o nome canônico do fuso horário IANA, como no exemplo a seguir. ``` --time-zone "America/New_York" ``` Para obter mais informações, consulte a [Lista de fusos horários no banco de dados de FH](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). # Usar padrões históricos para escalar os serviços do Amazon ECS com escalabilidade preditiva A escalabilidade preditiva utiliza dados de carga anteriores dos fluxos de tráfego para analisar padrões diários ou semanais. Em seguida, ela usa essa análise para prever necessidades futuras e aumentar proativamente as tarefas em seu serviço, conforme necessário. O ajuste de escala automático preditivo é mais útil nas situações a seguir. + Tráfego cíclico: maior utilização de recursos durante o horário comercial e utilização reduzida de recursos durante a noite e nos fins de semana. + Padrões recorrentes de workloads intermitentes: exemplos incluem processamento em lote, testes ou análise periódica de dados. + Aplicações com tempo de inicialização longo: isso pode afetar a performance da aplicação durante eventos de aumentar a escala horizontalmente, causando latência perceptível. Se suas aplicações demoram muito para inicializar e o tráfego aumenta em um padrão regular, considere o uso de escalabilidade preditiva. Ela ajuda você a escalar mais rapidamente aumentando proativamente o número de tarefas para cargas previstas, em vez de usar políticas de escalabilidade dinâmica, como Rastreamento de destino ou Escalabilidade em etapas, sozinhas. Ao ajudar você a evitar a possibilidade de provisionar excessivamente o número de tarefas, a escalabilidade preditiva também pode economizar dinheiro. Por exemplo, considere uma aplicação com elevado índice de utilização durante o horário comercial e baixo uso durante a noite. No início de cada dia útil, a escalabilidade preditiva pode aumentar a escala para execução de tarefas antes do primeiro fluxo de tráfego. Isso ajuda sua aplicação a manter alta disponibilidade e performance ao passar de um período de menor utilização para um período de maior utilização. Você não precisa esperar que a escalabilidade dinâmica reaja à mudança de tráfego. Você também não precisa gastar tempo revisando os padrões de carga da aplicação e tentando alocar a quantidade certa de tarefas usando a escalabilidade programada. O ajuste de escala preditivo é um recurso de nível de serviço que dimensiona a tarefa do seu serviço independentemente do dimensionamento da capacidade computacional subjacente (por exemplo, EC2 ou Fargate). Para o Fargate, a AWS gerencia e ajusta automaticamente a escala da capacidade subjacente com base nos requisitos da tarefa. Para a capacidade do EC2, é possível usar provedores de capacidade do grupo do Auto Scaling para escalar automaticamente as instâncias do EC2 subjacentes com base nos requisitos de ajuste de escala das suas tarefas. **Topics** + [Visão geral da escalabilidade preditiva](#predictive-auto-scaling-overview) + [Criar uma política de escalabilidade preditiva](predictive-scaling-create-policy.md) + [Avaliar as políticas de escalabilidade preditiva](predictive-scaling-graphs.md) + [Substituir a previsão](predictive-scaling-overriding-forecast-capacity.md) + [Usar métricas personalizadas](predictive-scaling-custom-metrics.md) ## Saiba como o ajuste de escala preditivo funciona com o Amazon ECS Aqui você pode conhecer as considerações relacionadas o uso da escalabilidade preditiva, como ela funciona e quais são os limites. ### Considerações sobre o uso da escalabilidade preditiva + Você deseja garantir que a escalabilidade preditiva seja adequada à sua workload. Você pode verificar isso configurando políticas de escalabilidade no modo **somente previsão** e ver a recomendação feita pelo console. Você deve avaliar a previsão e as recomendações antes de começar a usar a escalabilidade preditiva. + Antes que a escalabilidade preditiva possa iniciar a previsão, pelo menos 24 horas de dados históricos são necessários. Quanto mais dados históricos estiverem disponíveis, mais eficaz será a previsão, sendo duas semanas o ideal. Também será necessário aguardar 24 horas antes que a escalabilidade preditiva possa gerar novas previsões quando um serviço do Amazon ECS é excluído e um novo serviço é criado. Uma maneira de acelerar isso é usar métricas personalizadas para agregar métricas no novo serviço e no serviço antigo do Amazon ECS. + Escolha uma métrica de carga que represente com precisão a carga total da sua aplicação e que seja o aspecto mais importante a ser escalado. + A escalabilidade dinâmica com escalabilidade preditiva ajuda você a acompanhar de perto a demanda da sua aplicação para que você possa reduzir a escala durante períodos de calmaria e aumentá-la durante aumentos inesperados no tráfego. Quando várias políticas de escalabilidade estão ativas, cada política determina o número de tarefas desejadas de forma independente, e esse número é definido como o maior entre eles. + É possível usar a escalabilidade preditiva junto com suas políticas de escalabilidade dinâmica, como rastreamento de destino ou escalabilidade em etapas, para que suas aplicações sejam dimensionadas com base em padrões históricos e em tempo real. Por si só, a escalabilidade preditiva não reduz a escala para suas tarefas. + Se você usar um perfil personalizado ao chamar a API `register-scalable-target`, poderá receber um erro dizendo que a política de escalabilidade preditiva só pode funcionar com o SLR habilitado. Nesse caso, você deve chamar `register-scalable-target` novamente, mas sem role-arn. Use SLR ao registrar o destino escalável e chame a API `put-scaling-policy`. ### Como a escalabilidade preditiva funciona Use a escalabilidade preditiva criando uma política de escala preditiva que especifique a métrica do CloudWatch a ser monitorada e analisada. A escalabilidade preditiva deve ter pelo menos 24 horas de dados para começar a prever valores futuros. Depois que você cria a política, a escala preditiva começa a analisar os dados de métricas dos últimos 14 dias para identificar padrões. Essa análise é usada para gerar as próximas 48 horas de previsões horárias de requisitos. Os dados mais recentes do CloudWatch são usados para atualizar a previsão a cada seis horas. À medida que novos dados são recebidos, a escalabilidade preditiva é capaz de melhorar continuamente a precisão das previsões futuras. Quando você ativa a escala preditiva pela primeira vez, ela é executada no modo *somente de previsão*. Eae gera previsões nesse modo, mas não escala seu serviço do Amazon ECS com base nessas previsões. Isso significa que você pode avaliar a exatidão e a adequação da previsão. Você pode visualizar os dados de previsão usando a operação da API `GetPredictiveScalingForecast` ou o Console de gerenciamento da AWS. Quando você decidir começar a usar a escala preditiva, alterne a política de escalabilidade para o modo *prever e escalar*. O cenário a seguir ocorre nesse modo. Seu serviço do Amazon ECS é escalado no início de cada hora com base na previsão para essa hora, por padrão. Você pode optar por começar mais cedo usando a propriedade `SchedulingBufferTime` na operação da API `PutScalingPolicy`. Isso faz com que novas tarefas sejam iniciadas antes da demanda prevista e concede a elas tempo para inicializar e se preparar para lidar com o tráfego. ### Limite máximo de tarefas Ao registrar serviços do Amazon ECS para escalabilidade, você define um número máximo de tarefas que podem ser iniciadas por serviço. Por padrão, quando políticas de escalabilidade estão definidas, não é possível aumentar o número de tarefas além do limite máximo. Como alternativa, é possível permitir que o número máximo de tarefas do serviço seja aumentado automaticamente se a previsão se aproximar ou exceder o número máximo de tarefas do serviço do Amazon ECS. **Atenção** Tenha cuidado ao permitir que o número máximo de tarefas seja aumentado automaticamente. Isso pode fazer com que mais instâncias do que o pretendido sejam executadas se a capacidade máxima aumentada não for monitorada e gerenciada. O número máximo de tarefas aumentado passará a ser o novo número máximo normal de tarefas para o serviço do Amazon ECS até que você o atualize manualmente. O número máximo de tarefas não diminui automaticamente de volta para o máximo original. ### Regiões compatíveis + Leste dos EUA (Norte da Virgínia) + Leste dos EUA (Ohio) + Oeste dos EUA (N. da Califórnia) + Oeste dos EUA (Oregon) + África (Cidade do Cabo) + Ásia-Pacífico (Hong Kong) + Ásia-Pacífico (Jacarta) + Ásia-Pacífico (Mumbai) + Ásia-Pacífico (Osaka) + Ásia-Pacífico (Seul) + Ásia-Pacífico (Singapura) + Ásia-Pacífico (Sydney) + Ásia-Pacífico (Tóquio) + Canadá (Central) + China (Pequim) + China (Ningxia) + Europa (Frankfurt) + Europa (Irlanda) + Europa (Londres) + Europa (Milão) + Europa (Paris) + Europa (Estocolmo) + Oriente Médio (Bahrein) + South America (São Paulo) + AWS GovCloud (Leste dos EUA) + AWS GovCloud (Oeste dos EUA) # Criar uma política de escalabilidade preditiva para ajuste de escala automático do serviço do Amazon ECS Crie uma política de escalabilidade preditiva para que o Amazon ECS aumente ou diminua o número de tarefas executadas pelo serviço com base em dados de histórico. **nota** Um novo serviço precisa fornecer pelo menos 24 horas de dados antes que uma previsão possa ser gerada. ## Console 1. Além das permissões padrão do IAM para criar e atualizar serviços, você precisa de permissões adicionais. Para obter mais informações, consulte [Permissões obrigatórias do IAM para o ajuste de escala automático do serviço Amazon ECS](auto-scaling-IAM.md). 1. Determine as métricas a serem usadas para a política. As seguintes métricas estão disponíveis: + **ECSServiceAverageCPUUtilization**: utilização média da CPU que o serviço deveria usar. + **ECSServiceAverageMemoryUtilization**: utilização média da memória que o serviço deveria usar. + **ALBRequestCountPerTarget**: o número médio de solicitações por minuto que a tarefa deve idealmente receber. Como alternativa, você pode usar uma métrica personalizada. É necessário definir os seguintes valores: + Carga: uma métrica que representa com precisão a carga total da aplicação e é o aspecto mais importante a ser escalado. + Métrica de escalabilidade: o melhor indicador de quanta utilização é ideal para sua aplicação. 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. Escolha **Ajuste de escala automático do serviço** e depois **Definir o número de tarefas**. 1. Em **Contagem de tarefas do serviço do Amazon ECS**, escolha **Usar ajuste de escala automático**. A seção **Contagem de tarefas** é exibida. 1. Em **Número mínimo de tarefas**, insira o limite inferior do número de tarefas a serem usadas pelo ajuste de escala automático. A contagem desejada não será inferior a essa contagem. 1. Em **Máximo**, insira o limite superior do número de tarefas a serem usadas pelo ajuste de escala automático. A contagem desejada não ultrapassará essa contagem. 1. Escolha **Salvar**. A página de políticas será exibida. 1. Escolha **Criar política de escalabilidade**. A página **Criar política** é exibida. 1. Em **Tipo de política de escalabilidade**, escolha **Escalabilidade preditiva**. 1. Em **Policy name** (Nome da política), insira o nome da política. 1. Em **Métricas**, escolha suas métricas na lista de opções. Se tiver escolhido **Application Load Balancer request count per target** (Número de solicitações do Application Load Balancer por destino), escolha um grupo de destino em **Target group** (Grupo de destino). A opção **Número de solicitações do Application Load Balancer por destino** só será válida de você tiver anexado um grupo de destino do Application Load Balancer para seu serviço. Se você escolheu **Par de métricas personalizadas**, escolha métricas individuais nas listas para **Métrica de carga** e **Métrica de escalabilidade**. 1. Em **Utilização pretendida**, insira o valor desejado para o percentual de tarefas que o Amazon ECS deve manter. O ajuste de escala automático do serviço expandirá sua capacidade até que a utilização média seja igual à utilização pretendida ou até atingir o número máximo de tarefas especificado. 1. Escolha **Criar política de escalabilidade**. ## AWS CLI Use a AWS CLI conforme mostrado a seguir para configurar políticas de escalabilidade preditiva para seu serviço do Amazon ECS. Substitua cada *espaço reservado para entrada do usuário* por suas próprias informações. Para obter mais informações sobre as métricas do CloudWatch que você pode especificar para uma política de escalabilidade preditiva, consulte [PredictivEscalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html) na *Referência da API do Amazon EC2 Auto Scaling*. ### Exemplo 1: uma política de escalabilidade preditiva com memória predefinida. Veja a seguir um exemplo de política com uma configuração de memória predefinida. ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 40, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceMemoryUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` O exemplo a seguir ilustra a criação da política via execução do comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) com o arquivo de configuração especificado. ``` aws application-autoscaling put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` Em caso de êxito, esse comando retornará o ARN da política. ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` ### Exemplo 2: uma política de escalabilidade preditiva com CPU predefinida. Veja a seguir um exemplo de política com uma configuração de CPU predefinida. ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 0.00000004, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceCPUUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` O exemplo a seguir ilustra a criação da política via execução do comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) com o arquivo de configuração especificado. ``` aws aas put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` Em caso de êxito, esse comando retornará o ARN da política. ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` # Avaliar as políticas de escalabilidade preditiva para o Amazon ECS Antes de usar uma política de escalabilidade preditiva para escalar seus serviços, revise as recomendações e outros dados da política no console do Amazon ECS. Isso é importante porque você não quer que uma política de escalabilidade preditiva escale sua capacidade real até saber que suas previsões estão corretas. Se o serviço for novo, aguarde 24 horas para criar a primeira previsão. Ao criar uma previsão, o AWS usa dados históricos. Se seu serviço ainda não tiver muitos dados históricos recentes, a escalabilidade preditiva poderá preencher temporariamente a previsão com agregados criados com base nos agregados históricos disponíveis no momento. As previsões são preenchidas até duas semanas anteriores à data de criação da política. ## Visualizar recomendações de escalabilidade preditiva Para realizar uma análise eficaz, o ajuste de escala automático do serviço deve ter pelo menos duas políticas de escalabilidade preditiva para comparação. (Porém, ainda é possível analisar as conclusões de uma única política.) Ao criar várias políticas, é possível avaliar uma política que usa uma métrica em relação a uma política que usa outra métrica. Também é possível avaliar o impacto de diferentes combinações de valores de destino e métricas. Depois que as políticas de escalabilidade preditiva são criadas, o Amazon ECS imediatamente começa a avaliar qual política faria um trabalho melhor ao escalar seu grupo. **Para visualizar suas recomendações no console do Amazon ECS** 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. Escolha **Ajuste de escala automático do serviço**. 1. Escolha a política de escalabilidade preditiva e, em seguida, escolha **Ações**, **Escalabilidade preditiva** e **Visualizar recomendação**. Você pode visualizar detalhes sobre uma política junto com nossa recomendação. A recomendação indica se é melhor usar a política de escalabilidade preditiva ou não usá-la. Se você não tiver certeza se uma política de escalabilidade preditiva é apropriada para seu grupo, analise as colunas **Impacto na disponibilidade** e **Impacto no custo** para escolher a política certa. As informações de cada coluna indicam qual é o impacto da política. + **Impacto na disponibilidade**: descreve se a política evitaria um impacto negativo na disponibilidade ao provisionar tarefas suficientes para lidar com a workload em comparação com não usar a política. + **Impacto no custo**: descreve se a política evitaria um impacto negativo em seus custos ao não provisionar em excesso as tarefas em comparação com não usar a política. Com o provisionamento excessivo, seus serviços tornam-se subutilizados ou ociosos, o que só aumenta o impacto nos custos. Se você tiver várias políticas, uma etiqueta **Melhor previsão** será exibida ao lado do nome da política que oferece mais benefícios de disponibilidade a um custo menor. O impacto na disponibilidade tem um peso maior. 1. (Opcional) Para selecionar o período de tempo desejado para os resultados da recomendação, escolha o valor de sua preferência no menu suspenso **Período de avaliação**: **2 dias**, **1 semana** ou **2 semanas**. Por padrão, o período de avaliação são as duas últimas semanas. Um período de avaliação mais longo oferece mais pontos de dados para os resultados da recomendação. Porém, adicionar mais pontos de dados pode não melhorar os resultados, se seus padrões de carga tiverem sido alterados, como após um período de demanda excepcional. Nesse caso, é possível obter uma recomendação mais focada analisando dados mais recentes. **nota** As recomendações são geradas somente para políticas que estão no modo **Somente previsão**. O recurso de recomendações funciona melhor quando uma política está no modo **Somente previsão** durante o período de avaliação. Se você iniciar uma política no modo de **Prever e escalar** e alterná-la para o modo **Somente previsão** posteriormente, é provável que as conclusões dessa política tenham desvios. Isso ocorre porque a política já contribuiu em favor da capacidade real. ## Analisar grafos de monitoramento de escalabilidade preditiva No console, é possível analisar a previsão dos dias, semanas ou meses anteriores para visualizar a performance da política ao longo do tempo. Você também pode usar essas informações para avaliar a precisão das previsões ao decidir se permitirá que uma política escale o número real de tarefas. **Para revisar grafos de monitoramento de escalabilidade preditiva no console do Amazon ECS** 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. Escolha **Ajuste de escala automático do serviço**. 1. Escolha a política de escalabilidade preditiva e, em seguida, escolha **Ações**, **Escalabilidade preditiva** e **Visualizar grafo**. 1. Na seção **Monitorar**, você pode visualizar as previsões passadas e futuras de carga e de capacidade da política em relação aos valores reais. O grafo **Carga** exibe a previsão de carga e os valores reais para a métrica de carga escolhida. O grafo **Capacidade** mostra o número de tarefas previstas pela política. Também inclui o número real de tarefas iniciadas. A linha vertical separa os valores históricos das previsões futuras. Esses grafos ficam disponíveis logo após a criação da política. 1. (Opcional) Para alterar a quantidade de dados históricos exibidos no gráfico, escolha o valor de sua preferência no menu suspenso **Período de avaliação** na parte superior da página. O período de avaliação não transforma os dados desta página de maneira alguma. Ele altera apenas a quantidade de dados históricos exibidos. **Compare dados no grafo **Carga**** Cada linha horizontal representa um conjunto diferente de pontos de dados relatados em intervalos de uma hora: 1. A **Carga real observada** usa a estatística SUM da métrica de carga escolhida para exibir a carga horária total no passado. 1. A **Carga prevista pela política** exibe a previsão de carga horária. Essa previsão é baseada nas duas semanas anteriores de observações da carga real. **Compare dados no grafo **Capacidade**** Cada linha horizontal representa um conjunto diferente de pontos de dados relatados em intervalos de uma hora: 1. **Número real de tarefas observado** mostra a capacidade real do serviço do Amazon ECS no passado, o que depende de suas outras políticas de escalabilidade e do tamanho mínimo do grupo em vigor no período selecionado. 1. **Capacidade prevista pela política** exibe a capacidade básica que você pode esperar ter no início de cada hora quando a política estiver no modo de **Prever e escalar**. 1. **Número de tarefas necessário inferido** mostra o número ideal de tarefas em seu serviço para manter a métrica de escalabilidade no valor de destino que você escolheu. 1. **Número mínimo de tarefas** mostra o número mínimo de tarefas em seu serviço. 1. **Capacidade máxima** mostra o número máximo de tarefas em seu serviço. Com o objetivo de calcular a capacidade necessária inferida, começamos supondo que cada tarefa é igualmente utilizada em um valor de destino especificado. Na prática, o número de tarefas não é utilizado igualmente. Porém, ao supor que a utilização é distribuída uniformemente entre tarefas, podemos fazer uma estimativa da probabilidade de quantidade de capacidade necessária. O requisito de número de tarefas é calculado de modo a ser inversamente proporcional à métrica de escalabilidade que você usou para sua política de escalabilidade preditiva. Em outras palavras, à medida que o número de tarefas aumenta, a métrica de escalabilidade diminui na mesma proporção. Por exemplo, se o número de tarefas dobra, a métrica de escalabilidade deve diminuir pela metade. A fórmula da capacidade necessária inferida: `sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)` Por exemplo, pegamos `actualServiceUnits` (`10`) e `scalingMetricValue` (`30`) para determinada hora. Em seguida, pegamos a `targetUtilization` especificada em sua política de escalabilidade preditiva (`60`) e calculamos a capacidade necessária inferida para a mesma hora. Isso retorna um valor de `5`. Isso significa que cinco é a quantidade inferida de capacidade necessária para manter a capacidade em proporção inversa direta ao valor de destino da métrica de escala. **nota** Há várias alavancas disponíveis para você ajustar e melhorar a economia de custos e a disponibilidade de sua aplicação. Utilize escalabilidade preditiva para a capacidade de linha de base e escalabilidade dinâmica para lidar com capacidade adicional. A escalabilidade dinâmica funciona independentemente da escalabilidade preditiva, aumentando e reduzindo a escala horizontalmente com base na utilização atual. Primeiro, o Amazon ECS calcula o número recomendado de tarefas para cada política de escalabilidade não programada. Em seguida, ele escala com base na política que fornece o maior número de tarefas. Para permitir que a redução da escala horizontalmente ocorra quando a carga diminui, seu serviço deve sempre ter pelo menos uma política de escalabilidade dinâmica com a parte de redução da escala horizontalmente habilitada. Você pode melhorar a performance da escalabilidade verificando se a capacidade mínima e máxima não são muito restritivas. Uma política com um número recomendado de tarefas que não esteja dentro da faixa de capacidade mínima e máxima será impedida de aumentar e reduzir a escala horizontalmente. # Monitorar métricas de escalabilidade preditiva para Amazon ECS com o CloudWatch É possível usar o Amazon CloudWatch para monitorar seus dados para escalabilidade preditiva. Uma política de escalabilidade preditiva coleta dados que são usados para prever sua carga futura. Os dados coletados são armazenados automaticamente no CloudWatch em intervalos regulares e podem ser usados para visualizar a performance da política ao longo do tempo. Você também pode criar alarmes do CloudWatch para receber uma notificação quando os indicadores de desempenho mudarem além dos limites definidos por você. ## Visualizar dados históricos de previsão Os dados de previsão de carga para uma política de escalabilidade preditiva podem ser visualizados no CloudWatch e podem ser úteis ao visualizar previsões em relação a outras métricas do CloudWatch em um único grafo. Você também pode ver tendências ao longo do tempo visualizando um intervalo de tempo mais amplo. É possível acessar até 15 meses de métricas históricas a fim de obter uma melhor visão do desempenho da política. **Para visualizar dados históricos de previsão usando o console do CloudWatch** 1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. No painel de navegação, escolha **Metrics** (Métricas) e, em seguida, **All metrics** (Todas as métricas). 1. Selecione o namespace da métrica **Ajuste de escala automático da aplicação**. 1. Escolha **Previsões de carga de escalabilidade preditiva**. 1. No campo de pesquisa, insira o nome da política de escalabilidade preditiva ou o nome do grupo do serviço do Amazon ECS e pressione a tecla Enter para filtrar os resultados. 1. Para criar um gráfico de uma métrica, marque a caixa de seleção ao lado da métrica. Para alterar o nome do gráfico, escolha o ícone de lápis. Para alterar o período, selecione um dos valores predefinidos ou escolha **custom (personalizado)**. Para obter mais informações, consulte [Representar uma métrica em gráficos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html) no *Guia do usuário do Amazon CloudWatch*. 1. Para alterar a estatística, escolha a guia **Métricas em gráfico**. Escolha o cabeçalho de coluna ou um valor individual e, em seguida, escolha uma estatística diferente. Embora seja possível escolher qualquer estatística para cada métrica, nem todas as estatísticas são úteis para as métricas **PredictiveScalingLoadForecast**. Por exemplo, as estatísticas **Média**, **Mínimo** e **Máximo** são úteis, mas a estatística **Soma** não. 1. Para adicionar outra métrica ao gráfico, em **Browse** (Procurar), escolha **All** (Todas), encontre a métrica específica e marque a caixa de seleção ao lado dela. Adicione até 10 métricas. 1. (Opcional) Para adicionar o gráfico a um painel do CloudWatch, escolha **Actions** (Ações), **Add to dashboard** (Adicionar ao painel). ## Criar métricas de precisão usando matemática métrica Com matemática métrica, você pode consultar várias métricas do CloudWatch e usar expressões matemáticas para criar novas séries temporais de acordo com essas métricas. Você pode visualizar as séries temporais resultantes no console do CloudWatch e adicioná-las aos painéis. Para obter mais informações sobre matemática métrica, consulte [Usar matemática métrica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) no *Guia do usuário do Amazon CloudWatch*. Usando matemática métricas, é possível representar graficamente de diferentes maneiras os dados gerados pelo ajuste de escala automático para a escalabilidade preditiva. Isso ajuda a monitorar o desempenho da política ao longo do tempo e a entender se é possível melhorar sua combinação de métricas. Por exemplo, você pode usar uma expressão de matemática métrica para monitorar o [mean absolute percentage error](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error) (MAPE – Erro percentual absoluto médio). A métrica MAPE ajuda a monitorar a diferença entre os valores previstos e os valores efetivos observados durante uma determinada janela de previsão. Mudanças no valor de MAPE podem indicar se o desempenho da política está se degradando ao longo do tempo conforme a natureza da sua aplicação muda. Um aumento no MAPE sinaliza uma lacuna maior entre os valores previstos e os valores efetivos. **Exemplo: expressão de matemática métrica** Para começar a usar esse tipo de gráfico, você pode criar uma expressão de matemática métrica como a mostrada no exemplo a seguir. Em vez de uma só métrica, há uma matriz de estruturas de consulta de dados métricos para `MetricDataQueries`. Cada item em `MetricDataQueries` obtém uma métrica ou executa uma expressão matemática. O primeiro item, `e1`, é a expressão matemática. A expressão designada define o parâmetro `ReturnData` como `true`, resultando na produção de uma única série temporal. Para todas as outras métricas, o valor `ReturnData` é `false`. No exemplo, a expressão designada usa os valores efetivos e previstos como entrada, e retorna a nova métrica (MAPE). `m1` é a métrica do CloudWatch que contém os valores efetivos de carga (supondo que a utilização de CPU seja a métrica de carga originalmente especificada para a política denominada `my-predictive-scaling-policy`). `m2` é a métrica do CloudWatch que contém os valores previstos de carga. A sintaxe matemática para a métrica MAPE é a seguinte: *média de (abs ((efetivo - previsto)/(efetivo)))* ### Visualizar suas métricas de precisão e definir alarmes Para visualizar os dados da métrica de precisão, selecione a guia **Metrics** (Métricas) no console do CloudWatch. Nele, é possível representar graficamente os dados. Para obter mais informações, consulte [Adição de uma expressão matemática a um gráfico do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console) no *Guia do usuário do Amazon CloudWatch*. Na seção **Metrics** (Métricas), você também pode criar um alarme com base em uma métrica que esteja monitorando. Enquanto estiver na guia **Graphed metrics** (Métricas representadas em gráficos), selecione o ícone **Create alarm** (Criar alarme) na coluna **Actions** (Ações). O ícone **Create alarm** (Criar alarme) é representado como um pequeno sino. Para obter mais informações e opções de notificação, consulte [Criação de um alarme do CloudWatch com base em uma expressão matemática de métrica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html) e [Notificação de usuários sobre alterações de alarme no Guia do usuário ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html) do *Amazon CloudWatch*. Como alternativa, você pode usar [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) e [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) para realizar cálculos usando matemática métrica e criar alarmes com base na saída. # Usar ações programadas para substituir os valores de previsão para o Amazon ECS Às vezes, você pode ter informações adicionais sobre seus futuros requisitos de aplicações que o cálculo de previsão não pode levar em conta. Por exemplo, os cálculos de previsão podem subestimar as tarefas necessárias para um evento de marketing futuro. Você pode usar ações programadas para substituir temporariamente a previsão durante períodos futuros. As ações programadas podem ser executadas de forma recorrente ou em uma data e hora específicas quando houver flutuações de demanda únicas. Por exemplo, você pode criar uma ação programada com um número maior de tarefas que o previsto. Em runtime, o Amazon ECS atualiza o número mínimo de tarefas em seu serviço. Como o ajuste de escala preditivo otimiza o número de tarefas, uma ação programada com um número mínimo de tarefas maior do que os valores de previsão é respeitada. Isso impede que o número de tarefas seja inferior ao esperado. Para interromper a substituição da previsão, use uma segunda ação agendada para retornar o número mínimo de tarefas à configuração original. O procedimento a seguir descreve as etapas necessárias para substituir a previsão durante períodos futuros. **Topics** + [Etapa 1: (Opcional) Analisar dados de séries temporais](#analyzing-time-series-data) + [Etapa 2: Criar duas ações programadas](#scheduling-capacity) **Importante** Este tópico pressupõe que você esteja tentando substituir a previsão para escalar para uma capacidade maior do que a prevista. Se você precisar diminuir temporariamente o número de tarefas sem a interferência de uma política de ajuste de escala preditivo, use o modo *somente previsão*. Enquanto estiver no modo somente de previsão, a escala preditiva continuará a gerar previsões, mas não aumentará automaticamente o número de tarefas. Você então poderá monitorar a utilização dos recursos e diminuir manualmente o número de tarefas conforme necessário. ## Etapa 1: (Opcional) Analisar dados de séries temporais Comece analisando os dados de séries temporais de previsão. Essa é uma etapa opcional, mas é útil quando você deseja entender os detalhes da previsão. 1. **Recuperar a previsão** Após a criação da previsão, é possível consultar um período específico na previsão. O objetivo da consulta é obter uma visão completa dos dados de séries temporais para um período específico. Sua consulta pode incluir até dois dias de dados de previsão futura. Se você usa a escalabilidade preditiva há algum tempo, também pode acessar seus dados de previsão anteriores. No entanto, a duração máxima de tempo entre as horas inicial e final é de 30 dias. Para obter a previsão usando o comando da AWS CLI [get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html), forneça os seguintes parâmetros no comando: + Inclua o nome do cluster no parâmetro `resource-id`. + Insira o nome da política no parâmetro `--policy-name`. + Insira a hora de início no parâmetro `--start-time` para retornar apenas os dados de previsão para depois ou no horário especificado. + Insira a hora de término no parâmetro `--end-time` para retornar apenas os dados de previsão para antes do horário especificado. ``` aws application-autoscaling get-predictive-scaling-forecast \ --service-namespace ecs \ --resource-id service/MyCluster/test \ --policy-name cpu40-predictive-scaling-policy \ --scalable-dimension ecs:service:DesiredCount \ --start-time "2021-05-19T17:00:00Z" \ --end-time "2021-05-19T23:00:00Z" ``` Se bem-sucedido, o comando retornará uma resposta semelhante à seguinte. ``` { "LoadForecast": [ { "Timestamps": [ "2021-05-19T17:00:00+00:00", "2021-05-19T18:00:00+00:00", "2021-05-19T19:00:00+00:00", "2021-05-19T20:00:00+00:00", "2021-05-19T21:00:00+00:00", "2021-05-19T22:00:00+00:00", "2021-05-19T23:00:00+00:00" ], "Values": [ 153.0655799339254, 128.8288551285919, 107.1179447150675, 197.3601844551528, 626.4039934516954, 596.9441277518481, 677.9675713779869 ], "MetricSpecification": { "TargetValue": 40.0, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ASGCPUUtilization" } } } ], "CapacityForecast": { "Timestamps": [ "2021-05-19T17:00:00+00:00", "2021-05-19T18:00:00+00:00", "2021-05-19T19:00:00+00:00", "2021-05-19T20:00:00+00:00", "2021-05-19T21:00:00+00:00", "2021-05-19T22:00:00+00:00", "2021-05-19T23:00:00+00:00" ], "Values": [ 2.0, 2.0, 2.0, 2.0, 4.0, 4.0, 4.0 ] }, "UpdateTime": "2021-05-19T01:52:50.118000+00:00" } ``` A resposta inclui duas previsões: `LoadForecast` e `CapacityForecast`. `LoadForecast` mostra a previsão de carga horária. `CapacityForecast` mostra os valores de previsão para a capacidade que é necessária em uma base horária para lidar com a carga prevista enquanto mantém um `TargetValue` de 40,0 (40% de utilização média da CPU). 1. **Identificar o período-alvo** Identifique a hora ou horas em que a flutuação de demanda única deverá ocorrer. Lembre-se de que as datas e os horários mostrados na previsão estão em UTC. ## Etapa 2: Criar duas ações programadas Em seguida, crie duas ações programadas para um período específico em que sua aplicação terá uma carga maior do que a prevista. Por exemplo, se você tiver um evento de marketing que irá direcionar o tráfego para seu site por um período limitado, poderá programar uma ação única para atualizar a capacidade mínima quando ele começar. Em seguida, agende outra ação para retornar a capacidade mínima para a configuração original quando o evento terminar. 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, escolha o cluster. 1. Na página de detalhes do cluster, na seção **Serviços**, escolha o serviço. A página de detalhes do serviço é exibida. 1. Escolha **Ajuste de escala automático do serviço**. A página de políticas será exibida. 1. Escolha **Ações programadas** e, em seguida, escolha **Criar**. A página **Criar ação de programação** é exibida. 1. Em **Nome da ação**, insira um nome exclusivo. 1. Em **Time zone** (Fuso horário), escolha um fuso horário. Todos os fusos horários listados são do banco de dados de fuso horário da IANA. Para obter mais informações, consulte a [Lista de fusos horários no banco de dados de FH](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). 1. Em **Hora de início**, insira a **Data** e a **Hora** em que a ação começa. 1. Em **Recurrence (Recorrência)**, escolha **Once (Uma vez)**. 1. Em **Ajustes de tarefas**, para Mínimo, insira um valor inferior ou igual ao número máximo de tarefas. 1. Escolha **Criar ação programada**. A página de políticas será exibida. 1. Configure uma segunda ação programada para retornar o número mínimo de tarefas para a configuração original no final do evento. A escalabilidade preditiva pode escalar o número de tarefas somente quando o valor definido para **Minínimo** é menor que os valores da previsão. **Para criar duas ações programadas para eventos únicos (AWS CLI)** Para usar o AWS CLI para criar as ações programadas, use o comando [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html). Por exemplo, vamos definir uma programação que mantenha uma capacidade mínima de três instâncias em 19 de maio às 17h por oito horas. Os comandos a seguir mostram como implementar esse cenário. O primeiro comando [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) instrui o Amazon EC2 Auto Scaling a atualizar a capacidade mínima do grupo do Auto Scaling especificado às 17h UTC em 19 de maio de 2021. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \ --auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3 ``` O segundo comando instrui o Amazon EC2 Auto Scaling a definir a capacidade mínima do grupo como um à 1h da manhã UTC em 20 de maio de 2021. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \ --auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1 ``` Após você adicionar essas ações programadas ao grupo do Auto Scaling, o Amazon EC2 Auto Scaling fará o seguinte: + Às 17h UTC em 19 de maio de 2021, a primeira ação programada é executada. Se o grupo tiver menos de três instâncias, ele será expandido para três instâncias. Durante esse período e nas próximas oito horas, o Amazon EC2 Auto Scaling poderá continuar a aumentar a escala na horizontal se a capacidade prevista for maior do que a capacidade real ou se houver uma política de escalabilidade dinâmica em vigor. + À 1h da manhã UTC em 20 de maio de 2021, a segunda ação programada é executada. Isso retorna a capacidade mínima para sua configuração original no final do evento. ### Escalabilidade com base em programações recorrentes Para substituir a previsão para o mesmo período de tempo todas as semanas, crie duas ações programadas e forneça a lógica de hora e data usando uma expressão cron. A expressão cron consiste em cinco campos separados por espaços: [Minute] [Hour] [Day\$1of\$1Month] [Month\$1of\$1Year] [Day\$1of\$1Week]. Os campos podem conter quaisquer valores permitidos, incluindo caracteres especiais. Por exemplo, esta expressão cron executa a ação todas as terças-feiras às 6h30. O asterisco é usado como um curinga para corresponder a todos os valores de um campo. ``` 30 6 * * 2 ``` ### Consulte também Para obter mais informações sobre como gerenciar ações programadas, consulte [Usar ações programadas para escalar os serviços do Amazon ECS](service-autoscaling-schedulescaling.md). # Política avançada de escalabilidade preditiva usando métricas personalizadas para o Amazon ECS É possível usar métricas predefinidas ou personalizadas em uma política de escalabilidade preditiva. As métricas personalizadas são úteis quando métricas predefinidas (como CPU, memória etc.) não são suficientes para descrever suficientemente a carga da aplicação. Ao criar uma política de escalabilidade preditiva com métricas personalizadas, você pode especificar outras métricas do CloudWatch fornecidas pela AWS. Como alternativa, você pode especificar métricas que define e publica. Você também pode usar a matemática de métricas para agregar e transformar métricas existentes em uma nova série temporal que a AWS não rastreia automaticamente. Um exemplo é combinar valores em seus dados calculando novas somas ou médias, o que é chamado de *agregação*. Os dados resultantes são chamados de um *agregado*. A seção a seguir contém as práticas recomendados e exemplos de como sstruturar o JSON para a política. ## Pré-requisitos Para adicionar métricas personalizadas à política de escalação preditiva, é necessário ter as permissões `cloudwatch:GetMetricData`. Para especificar suas próprias métricas em vez de usar as métricas que a AWS fornecer, é necessário primeiro publicá-las no CloudWatch. Para mais informações, consulte [Publishing custom metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) (Publicar métricas personalizadas) no *Guia do usuário do Amazon CloudWatch*. Se publicar suas próprias métricas, certifique-se de publicar os pontos de dados com uma frequência mínima de cinco minutos. Os pontos de dados são recuperados do CloudWatch com base na duração do período necessário. Por exemplo, a especificação da métrica de carga usa métricas por hora para medir a carga em sua aplicação. O CloudWatch usa seus dados de métrica publicados para fornecer um único valor de dados para qualquer período de uma hora, agregando todos os pontos de dados com a data/hora que caem dentro de cada período de uma hora. ## Práticas recomendadas As seguintes práticas recomendadas podem ajudar no uso mais eficaz de métricas personalizadas: + A métrica mais útil para a especificação da métrica de carga é uma métrica que representa a carga em um grupo do Auto Scaling como um todo. + A métrica mais útil para escalar a especificação da métrica de escalabilidade é um throughput médio ou métrica de utilização por tarefa. + A utilização visada deve corresponder ao tipo de métrica de escalabilidade. Para uma configuração de política que usa utilização da CPU, isso é um percentual desejado, por exemplo. + Se essas recomendações não forem seguidas, provavelmente os valores futuros previstos da série temporal estarão incorretos. Para validar se os dados estão corretos, você pode visualizar os valores previstos no console. Como alternativa, depois de criar sua política de escalabilidade preditiva, inspecione os objetos `LoadForecast` retornados por uma chamada para a API [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html). + Recomendamos enfaticamente configurar a escalabilidade preditiva no modo apenas previsão para que você possa avaliar a previsão antes que a escalabilidade preditiva comece a modificar ativamente a escala. ## Limitações + Você pode consultar pontos de dados de até 10 métricas em uma especificação métrica. + Para os propósitos desse limite, uma expressão conta como uma métrica. ## Solucionar problemas com uma política de escalabilidade preditiva com métricas personalizadas Se ocorrer um problema ao usar métricas personalizadas, recomendamos fazer o seguinte: + Se você encontrar um problema em uma implantação azul/verde enquanto usa uma expressão de pesquisa, certifique-se de criar uma expressão de pesquisa que procure uma correspondência parcial, e não uma correspondência exata. Verifique também se a consulta está encontrando apenas grupos do Auto Scaling em execução na aplicação específica. Para mais informações sobre essa sintaxe de expressão de pesquisa, consulte [CloudWatch search expression syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html) (Sintaxe de expressão de pesquisa do CloudWatch) no *Guia do usuário do Amazon CloudWatch*. + O comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) valida uma expressão quando você cria sua política de dimensionamento. No entanto, existe a possibilidade de que esse comando não identifique a causa exata dos erros detectados. Para corrigir os problemas, solucione os erros que você recebe em uma resposta de uma solicitação para o comando [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html). Você também pode solucionar problemas da expressão no console do CloudWatch. + É necessário especificar `false` para `ReturnData` se `MetricDataQueries` especificar a função SEARCH() (BUSCAR) por conta própria sem uma função matemática como SUM() (SOMA). Isso ocorre porque as expressões de pesquisa podem retornar várias séries temporais, e uma especificação métrica baseado em uma expressão pode retornar apenas uma série temporal. + Todas as métricas envolvidas em uma expressão de pesquisa devem ter a mesma resolução. # Construir o JSON para métricas personalizadas de escalabilidade preditiva com o Amazon ECS A seção a seguir contém exemplos de como configurar escalação preditiva para consultar dados do CloudWatch. Há dois métodos diferentes de configurar essa opção, e o método escolhido afeta qual será o formato usado para estruturar JSON para a política de escalação preditiva. Quando você usa matemática de métricas, o formato do JSON varia ainda mais com base na matemática de métrica que está sendo aplicada. 1. Para criar uma política que obtenha dados diretamente de outras métricas do CloudWatch fornecidas pela AWS ou das métricas que você publica no CloudWatch, consulte [Exemplo de política de escalabilidade preditiva com métricas personalizadas de carga e escalabilidade usando a AWS CLI](#predictive-scaling-custom-metrics-example1). ## Exemplo de política de escalabilidade preditiva com métricas personalizadas de carga e escalabilidade usando a AWS CLI Para criar uma política de escalação preditiva com métricas personalizadas de carga e dimensionamento com a AWS CLI, armazene os argumentos para a `--predictive-scaling-configuration` em um arquivo JSON denominado `config.json`. Você começa a adicionar métricas personalizadas substituindo os valores substituíveis no exemplo a seguir por suas métricas e sua meta de utilização. ``` { "MetricSpecifications": [ { "TargetValue": 50, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Id": "scaling_metric", "MetricStat": { "Metric": { "MetricName": "MyUtilizationMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Average" } } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "MyLoadMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Sum" } } ] } } ] } ``` Para obter mais informações, consulte [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html) na *Amazon EC2 Auto Scaling API Reference* (Referência de API do Amazon EC2 Auto Scaling). **nota** Veja a seguir alguns recursos adicionais que podem ajudar você a encontrar nomes de métricas, namespaces, dimensões e estatísticas para as métricas do CloudWatch: Para mais informações sobre as métricas disponíveis para produtos da AWS, consulte [Produtos da AWS que publicam métricas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html) no *Guia do usuário do Amazon CloudWatch*. Para obter os valores exatos de nome da métrica, namespace e dimensões (se aplicável) para uma métrica do CloudWatch com a AWS CLI, consulte [list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html). Para criar essa política, execute o comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) usando como entrada o arquivo JSON, como demonstrado no exemplo a seguir. ``` aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json ``` Se bem-sucedido, esse comando gerará o nome do recurso da Amazon (ARN) da política. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy", "Alarms": [] } ``` # Usar expressões de matemática métrica A seção a seguir fornece informações sobre o uso matemática métrica com políticas de escalabilidade preditiva em sua política. ## Noções básicas de matemática métrica Se tudo o que deseja fazer é agregar dados métricos existentes, a matemática métrica do CloudWatch poupa o esforço e o custo de publicar outra métrica no CloudWatch. Você pode usar qualquer métrica que a AWS fornece, e também pode usar métricas definidas como parte de suas aplicações. Para obter mais informações, consulte [Usar matemática métrica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) no *Guia do usuário do Amazon CloudWatch*. Se você optar por usar uma expressão matemática métrica em sua política de escalabilidade preditiva, considere os seguintes pontos: + As operações matemáticas métricas usam os pontos de dados da combinação exclusiva de nome da métrica, namespace e pares de métricas de chaves-valor da dimensão. + Você pode usar qualquer operador aritmético (\$1 - \$1 / ^), função estatística (como AVG ou SUM) ou outra função compatível com o CloudWatch. + Você pode usar as métricas e os resultados de outras expressões matemáticas nas fórmulas da expressão matemática. + Suas expressões matemáticas métricas podem ser compostas de agregações diferentes. No entanto, uma prática recomendada para o resultado final da agregação é usar `Average` para a métrica de escalabilidade e `Sum` para a métrica de carga. + Qualquer expressão usada em uma especificação de métrica deve eventualmente retornar uma única série temporal. Para usar matemática métrica, faça o seguinte: + Escolha uma ou mais métricas do CloudWatch. Em seguida, crie a expressão. Para obter mais informações, consulte [Usar matemática métrica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) no *Guia do usuário do Amazon CloudWatch*. + Verifique se a expressão matemática métrica é válida usando o console do CloudWatch ou a API do CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html). ## Exemplo de política de escalação preditiva que combina métricas por meio da matemática de métricas (AWS CLI) Às vezes, ao invés de especificar a métrica diretamente, talvez seja necessário processar seus dados de alguma forma, primeiramente. Por exemplo, você pode ter uma aplicação que extrai o trabalho de uma fila do Amazon SQS e talvez queira usar o número de itens na fila como critério para escalabilidade preditiva. O número de mensagens na fila não define unicamente o número necessário de instâncias. Portanto, é necessário mais trabalho para criar uma métrica que possa ser usada para calcular a lista de pendências por instância. Veja a seguir um exemplo de política de escalabilidade preditiva para esse cenário. Ele especifica métricas de escalabilidade e carga baseadas na métrica `ApproximateNumberOfMessagesVisible` do Amazon SQS, que é o número de mensagens disponíveis para recuperação da fila. Ele também usa a métrica `GroupInServiceInstances` do Amazon EC2 Auto Scaling e uma expressão matemática para calcular a lista de pendências por instância para a métrica de escalabilidade. ``` aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \ --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json --service-namespace ecs \ --resource-id service/MyCluster/test \ "MetricSpecifications": [ { "TargetValue": 100, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Label": "Get the queue size (the number of messages waiting to be processed)", "Id": "queue_size", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Get the group size (the number of running instances)", "Id": "running_capacity", "MetricStat": { "Metric": { "MetricName": "GroupInServiceInstances", "Namespace": "AWS/AutoScaling", "Dimensions": [ { "Name": "AutoScalingGroupName", "Value": "my-asg" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Calculate the backlog per instance", "Id": "scaling_metric", "Expression": "queue_size / running_capacity", "ReturnData": true } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ], }, "Stat": "Sum" }, "ReturnData": true } ] } } ] } ``` O exemplo retorna o ARN da política. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy", "Alarms": [] } ``` # Interconexão de serviços do Amazon ECS As aplicações executadas em tarefas do Amazon ECS muitas vezes precisam receber conexões da Internet ou se conectar a outras aplicações executadas nos serviços do Amazon ECS. Se você precisar de conexões externas da Internet, recomendamos usar o Elastic Load Balancing. Para obter mais informações sobre balanceamento de carga integrado, consulte [Uso do balanceamento de carga para distribuir o tráfego de serviço do Amazon ECS](service-load-balancing.md). Se você precisar de uma aplicação para se conectar a outras aplicações executadas nos serviços do Amazon ECS, o Amazon ECS oferecerá as maneiras a seguir de fazer isso sem um balanceador de carga: + *Amazon ECS Service Connect* Recomendamos o Service Connect, que fornece a configuração do Amazon ECS para descoberta de serviços, conectividade e monitoramento de tráfego. Com o Service Connect, as aplicações podem usar nomes curtos e portas padrão para se conectar aos serviços do Amazon ECS no mesmo cluster e em outros clusters, inclusive entre VPCs na mesma Região da AWS. Ao usar o Service Connect, o Amazon ECS gerencia todas as partes da descoberta de serviços: criar os nomes que podem ser descobertos, gerenciar dinamicamente as entradas de cada tarefa à medida que as tarefas começam e são interrompidas, executar um agente em cada tarefa configurada para descobrir os nomes. Sua aplicação pode pesquisar os nomes usando a funcionalidade padrão para nomes do DNS e fazendo conexões. Caso a aplicação já faça isso, não será necessário modificá-la para usar o Service Connect. Você fornece a configuração completa dentro de cada serviço e definição de tarefa. O Amazon ECS gerencia as alterações nessa configuração em cada implantação de serviço, para garantir que todas as tarefas em uma implantação se comportem da mesma maneira. Por exemplo, um problema comum do DNS como descoberta de serviços é controlar uma migração. Se você alterar um nome do DNS de modo a direcionar para os novos endereços IP substitutos, poderá levar o tempo máximo de TTL antes que todos os clientes comecem a usar o novo serviço. Com o Service Connect, a implantação do cliente atualiza a configuração substituindo as tarefas do cliente. Você pode configurar o disjuntor de implantação e outras configurações de implantação para afetar as alterações do Service Connect da mesma forma que qualquer outra implantação. Para obter mais informações, consulte [Uso do Service Connect para conectar serviços do Amazon ECS com nomes abreviados](service-connect.md). + *Descoberta de serviço do Amazon ECS* Outra abordagem para a comunicação entre serviços é a comunicação direta por meio da descoberta de serviços. Nessa abordagem, você pode usar a integração da descoberta de serviços do AWS Cloud Map com o Amazon ECS. Usando a descoberta de serviços, o Amazon ECS sincroniza a lista de tarefas executadas com o AWS Cloud Map, que mantém um nome de host do DNS que resolve os endereços IP internos de uma ou mais tarefas desse serviço específico. Outros serviços na Amazon VPC podem usar esse nome de host do DNS para enviar tráfego diretamente a outro contêiner usando o endereço IP interno. Essa abordagem de comunicação entre serviços fornece baixa latência. Não há componentes extras entre os contêineres. O tráfego viaja diretamente de um contêiner para o outro. Essa abordagem é adequada ao usar o modo de rede `awsvpc`, em que cada tarefa tem seu próprio endereço IP exclusivo. A maioria dos softwares é compatível apenas com o uso de registros `A` do DNS, que resolvem diretamente os endereços IP. Ao usar o modo de rede `awsvpc`, o endereço IP de cada tarefa é um registro `A`. No entanto, se você estiver usando o modo de rede `bridge`, vários contêineres podem estar compartilhando o mesmo endereço IP. Além disso, os mapeamentos dinâmicos de portas fazem com que os contêineres recebam números de porta aleatoriamente nesse único endereço IP. A essa altura, um registro `A` não é mais suficiente para a descoberta de serviços. Você também deve usar um registro `SRV`. Esse tipo de registro pode rastrear endereços IP e números de porta, mas exige que você configure as aplicações adequadamente. Algumas aplicações pré-criadas que você usa podem não oferecer suporte a registros `SRV`. Outra vantagem do modo de rede `awsvpc` é ter um grupo de segurança exclusivo para cada serviço. Você pode configurar esse grupo de segurança para permitir conexões de entrada somente dos serviços upstream específicos que precisam se comunicar com esse serviço. A principal desvantagem da comunicação direta entre serviços usando a descoberta de serviços é que você deve implementar uma lógica extra para ter repetições e lidar com falhas de conexão. Os registros DNS têm um período de vida útil (TTL) que controla por quanto tempo são armazenados em cache. Leva algum tempo para que o registro DNS seja atualizado e o cache expire para que as aplicações possam obter a versão mais recente do registro DNS. Portanto, sua aplicação pode acabar resolvendo o registro DNS de modo a direcionar para outro contêiner que não está mais lá. A aplicação precisa processar repetições e ter uma lógica para ignorar backends problemáticos. Para obter mais informações, consulte . [Uso da descoberta de serviços para conectar serviços do Amazon ECS com nomes DNS](service-discovery.md) + *Amazon VPC Lattice * O Amazon VPC Lattice é um serviço gerenciado de rede de aplicações usado pelos clientes do Amazon ECS para observar, proteger e monitorar aplicações criadas em serviços de computação, VPCs e contas da AWS sem precisar modificar seu código. O VPC Lattice usa grupos de destino, que são uma coleção de recursos computacionais. Esses destinos executam a aplicação ou serviço e podem ser instâncias do Amazon EC2, endereços IP, funções do Lambda e Application Load Balancers. Ao associarem seus serviços do Amazon ECS a um grupo de destino do VPC Lattice, os clientes agora podem habilitar tarefas do Amazon ECS como destinos IP no VPC Lattice. O Amazon ECS registra automaticamente as tarefas no grupo de destino do VPC Lattice quando as tarefas do serviço registrado são iniciadas. Para obter mais informações, consulte [Use o Amazon VPC Lattice para conectar, observar e proteger seus serviços do Amazon ECS](ecs-vpc-lattice.md). ## Tabela de compatibilidade de modo de rede A tabela a seguir inclui a compatibilidade entre essas opções e os modos de rede de tarefas. Na tabela, “client” (cliente) refere-se à aplicação que está fazendo as conexões de dentro de uma tarefa do Amazon ECS. **** | Opções de interconexão | Conectado | `awsvpc` | Host | | --- | --- | --- | --- | | Descoberta de serviço | sim, mas exige que os clientes conheçam os registros SRV no DNS sem hostPort. | sim | sim, mas exige que os clientes conheçam os registros SRV no DNS sem hostPort. | | Service Connect | sim | sim | não | | VPC Lattice | sim | sim | sim | # Uso do Service Connect para conectar serviços do Amazon ECS com nomes abreviados O Amazon ECS Service Connect fornece gerenciamento da comunicação entre serviços conforme a configuração do Amazon ECS. Ele cria uma descoberta de serviços e uma malha de serviços no Amazon ECS. Isso fornece a configuração completa dentro de cada serviço que você gerencia por implantações de serviço, uma maneira unificada de consultar os serviços nos namespaces que não dependem da configuração de DNS da VPC, além de métricas e dos logs padronizados para monitorar todas as aplicações. O Service Connect apenas realiza a interconexão de serviços. O diagrama a seguir mostra um exemplo de rede do Service Connect com duas sub-redes na VPC e dois serviços. Um serviço do cliente que executa o WordPress com uma tarefa em cada sub-rede. Um serviço de servidor que executa o MySQL com uma tarefa em cada sub-rede. Ambos os serviços são altamente disponíveis e resilientes a problemas de tarefas e zonas de disponibilidade, pois cada serviço executa várias tarefas espalhadas por duas sub-redes. As setas sólidas mostram uma conexão do WordPress com o MySQL. Por exemplo, um comando da CLI `mysql --host=mysql` executado de dentro do contêiner do WordPress na tarefa com o endereço IP `172.31.16.1`. O comando usa o nome curto `mysql` na porta padrão do MySQL. O nome e a porta se conectam ao proxy do Service Connect na mesma tarefa. O proxy na tarefa do WordPress usa balanceamento de carga round-robin e qualquer informação de falha anterior na detecção de valores discrepantes para escolher a qual tarefa do MySQL se conectar. Conforme mostrado pelas setas sólidas no diagrama, o proxy se conecta ao segundo proxy na tarefa do MySQL com o endereço IP `172.31.16.2`. O segundo proxy se conecta ao servidor MySQL local na mesma tarefa. Ambos os proxies relatam o desempenho da conexão que é visível em gráficos nos consoles Amazon ECS e Amazon CloudWatch para que você possa obter métricas de performance de todos os tipos de aplicações da mesma forma. ![\[Exemplo de rede do Service Connect mostrando serviços mínimos de HA\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/images/serviceconnect.png) Os termos a seguir são usados com o Service Connect. **nome da porta** A configuração de definição de tarefa do Amazon ECS que atribui um nome a um mapeamento de porta específico. Essa configuração só é usada pelo Amazon ECS Service Connect. **alias do cliente** A configuração do serviço do Amazon ECS que atribui o número da porta usada no endpoint. Além disso, o alias do cliente pode atribuir o nome DNS do endpoint, substituindo o nome da descoberta. Se um nome de descoberta não for fornecido no serviço do Amazon ECS, o nome do alias do cliente substituirá o nome da porta como o nome do endpoint. Para ver exemplos de endpoints, consulte a definição de *endpoint*. Vários aliases de cliente podem ser atribuídos a um serviço do Amazon ECS. Essa configuração só é usada pelo Amazon ECS Service Connect. **nome da descoberta** O nome intermediário opcional que você pode criar para uma porta especificada na definição da tarefa. Esse nome é usado para criar um serviço do AWS Cloud Map. Se esse nome não for fornecido, será usado o nome da porta da definição da tarefa. Vários nomes de descoberta podem ser atribuídos a uma porta específica de um serviço do Amazon ECS. Essa configuração só é usada pelo Amazon ECS Service Connect. Os nomes dos serviços do AWS Cloud Map devem ser exclusivos dentro de um namespace. Devido a essa limitação, você só pode ter uma configuração do Service Connect sem um nome de descoberta para uma definição de tarefa específica em cada namespace. **endpoint** O URL para se conectar a uma API ou site. O URL contém o protocolo, um nome DNS e a porta. Para obter mais informações sobre endpoints em geral, consulte [endpoint](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#endpoint) no *Glossário da AWS* na Referência geral da Amazon Web Services. O Service Connect cria endpoints que se conectam aos serviços do Amazon ECS e configura as tarefas nos serviços do Amazon ECS para se conectarem aos endpoints. O URL contém o protocolo, um nome DNS e a porta. Você seleciona o protocolo e o nome da porta na definição da tarefa, pois a porta deve corresponder à aplicação que está dentro da imagem do contêiner. No serviço, você seleciona cada porta pelo nome e pode atribuir o nome DNS. Se você não especificar um nome DNS na configuração do serviço do Amazon ECS, será usado por padrão o nome da porta da definição da tarefa. Por exemplo, um endpoint do Service Connect pode ser `http://blog:80`, `grpc://checkout:8080` ou `http://_db.production.internal:99`. **Serviço do Service Connect** A configuração de um único endpoint em um serviço do Amazon ECS. Isso faz parte da configuração do Service Connect, que consiste em uma única linha na **Service Connect and discovery name configuration** (Configuração do Service Connect e do nome da descoberta) no console ou em um objeto da lista `services` da configuração JSON de um serviço do Amazon ECS. Essa configuração só é usada pelo Amazon ECS Service Connect. Para obter mais informações, consulte [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html) na Referência de API do Amazon Elastic Container Service. **namespace** O nome do recurso da Amazon (ARN) abreviado ou completo do namespace AWS Cloud Map para uso com o Service Connect. O namespace deve estar na mesma Região da AWS que o serviço e o cluster do Amazon ECS. O tipo de namespace no AWS Cloud Map não afeta o Service Connect. O namespace pode ser aquele que é compartilhado com sua Conta da AWS usando o AWS Resource Access Manager (AWS RAM) nas Regiões da AWS em que AWS RAM está disponível. Para obter mais informações sobre namespaces compartilhados, consulte [Compartilhamento de namespaces do AWS Cloud Map entre contas](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) no *Guia do desenvolvedor do AWS Cloud Map*. O Service Connect usa o namespace AWS Cloud Map como um agrupamento lógico de tarefas do Amazon ECS que se comunicam entre si. Cada serviço do Amazon ECS pode pertencer a apenas um namespace. Os serviços em um namespace podem ser distribuídos entre diferentes clusters do Amazon ECS dentro da mesma Região da AWS. Se o namespace for compartilhado, os serviços poderão ser distribuídos entre as Contas da AWS de proprietário e consumidor do namespace. É possível organizar serviços de forma flexível, seguindo qualquer critério desejado. **serviço de cliente** Um serviço que executa uma aplicação cliente de rede. Esse serviço deve ter um namespace configurado. Cada tarefa do serviço pode descobrir e se conectar a todos os endpoints do namespace por meio de um contêiner do proxy do Service Connect. Se algum dos seus contêineres na tarefa precisar se conectar a um endpoint em um serviço em um namespace, escolha um serviço de cliente. Se uma aplicação de frontend, de proxy reverso ou de balanceador de carga receber tráfego externo por meio de outros métodos, como o Elastic Load Balancing, ela poderá usar esse tipo de configuração do Service Connect. **serviço cliente-servidor** Um serviço do Amazon ECS que executa uma aplicação de rede ou de serviço Web. Esse serviço deve ter um namespace e pelo menos um endpoint configurados. Cada tarefa do serviço pode ser acessada por meio dos endpoints. O contêiner do proxy do Service Connect recebe o nome e a porta do endpoint para direcionar o tráfego para os contêineres da aplicação na tarefa. Se algum dos contêineres expuser e receber tráfego de rede em uma porta, escolha um serviço cliente-servidor. Essas aplicações não precisam se conectar a outros serviços cliente-servidor no mesmo namespace, mas a configuração do cliente é necessária. Esse tipo de configuração do Service Connect pode ser utilizado por backend, middleware, camada de negócios ou pela maioria dos microsserviços. Se você quiser que uma aplicação de frontend, de proxy reverso ou de balanceador de carga receba tráfego de outros serviços configurados com o Service Connect no mesmo namespace, esses serviços deverão usar esse tipo de configuração do Service Connect. O recurso Service Connect cria uma rede virtual de serviços relacionados. A mesma configuração de serviços pode ser usada em vários namespaces diferentes para executar conjuntos de aplicações independentes, mas idênticas. O Service Connect define o contêiner do proxy no serviço do Amazon ECS. Dessa forma, a mesma definição de tarefa pode ser usada para executar aplicações idênticas em namespaces diferentes com diferentes configurações do Service Connect. Cada tarefa realizada pelo serviço executa um contêiner proxy na tarefa. O Service Connect é adequado para conexões entre serviços do Amazon ECS dentro do mesmo namespace. Para as seguintes aplicações, você precisa usar um método de interconexão adicional para se conectar a um serviço do Amazon ECS que esteja configurado com o Service Connect: + Tarefas que estão configuradas em outros namespaces + Tarefas que não estão configuradas para o Service Connect + Outras aplicações fora do Amazon ECS Essas aplicações podem se conectar por meio do proxy do Service Connect, mas não conseguem resolver os nomes dos endpoints do Service Connect. Para que essas aplicações resolvam os endereços IP das tarefas do Amazon ECS, é necessário usar outro método de interconexão. **Topics** + [Preços](#service-connect-pricing) + [Componentes do Amazon ECS Service Connect](service-connect-concepts-deploy.md) + [Visão geral da configuração do Amazon ECS Service Connect](service-connect-concepts.md) + [Amazon ECS Service Connect com Namespaces compartilhados do AWS Cloud Map](service-connect-shared-namespaces.md) + [Logs de acesso do Amazon ECS Service Connect](service-connect-envoy-access-logs.md) + [Criptografia do tráfego do Amazon ECS Service Connect](service-connect-tls.md) + [Configuração do Amazon ECS Service Connect com a AWS CLI](create-service-connect.md) ## Preços + O preços do Amazon ECS Service Connect depende de você usar ou não a infraestrutura do AWS Fargate ou do Amazon EC2 para hospedar workloads em contêiner. Ao usar o Amazon ECS no AWS Outposts, os preços seguem o mesmo modelo de quando você está usando o Amazon EC2 diretamente. Para obter mais informações, consulte [Preços do Amazon ECS](https://aws.amazon.com/ecs/pricing). + O uso do Amazon ECS Service Connect não gera custos adicionais. + Não há cobrança adicional para o uso do AWS Cloud Map quando utilizado pelo Service Connect. + Os clientes pagam pelos recursos computacionais usados pelo Amazon ECS Service Connect, incluindo vCPU e memória. Como o agente do Amazon ECS Service Connect é executado dentro de uma tarefa do cliente, sua execução não gera custos adicionais. Os recursos de tarefa são compartilhados entre a workload do cliente e o agente do Amazon ECS Service Connect. + Quando os clientes usam a funcionalidade de criptografia de tráfego do Amazon ECS Service Connect com CA Privada da AWS, eles pagam pela autoridade de certificação privada criada e por cada certificado do TLS emitido. Para obter mais detalhes, consulte [Preço do Autoridade de Certificação Privada da AWS](https://aws.amazon.com/private-ca/pricing/). Para estimar o custo mensal dos certificados do TLS, os clientes precisam saber o número dos serviços do Amazon ECS que têm o TLS habilitado, multiplicar esse número pelo custo do certificado e depois multiplicar por seis. Como o Amazon ECS Service Connect faz automaticamente o rodízio de certificados do TLS a cada cinco dias, em média, seis certificados são emitidos por serviço do Amazon ECS, por mês. # 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 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 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 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 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 # Visão geral da configuração do Amazon ECS Service Connect Ao usar o Service Connect, existem parâmetros que você precisa configurar em seus recursos. A tabela a seguir descreve os parâmetros de configuração dos recursos do Amazon ECS. | Local dos parâmetros | Tipo de aplicação | Descrição | Obrigatório | | --- | --- | --- | --- | | definição da tarefa | Cliente | Não há alterações disponíveis para o Service Connect nas definições de tarefa do cliente. | N/D | | definição da tarefa | Cliente-servidor | Os servidores devem adicionar campos name às portas nos portMappings de contêineres. Para obter mais informações, consulte . [portMappings](task_definition_parameters.md#ContainerDefinition-portMappings) | Sim | | definição da tarefa | Cliente-servidor | Opcionalmente, os servidores podem fornecer um protocolo de aplicação (por exemplo, HTTP) para receber métricas específicas do protocolo para suas aplicações de servidor (por exemplo, HTTP 5xx). | Não | | Definição de serviço | Cliente | Os serviços do cliente devem adicionar uma serviceConnectConfiguration para configurar o namespace a ser associado. Esse namespace deve conter todos os serviços de servidor que esse serviço precisa descobrir. Para obter mais informações, consulte [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Sim | | Definição de serviço | Cliente-servidor | Os serviços do servidor devem adicionar uma serviceConnectConfiguration para configurar os nomes de DNS, números de portas e namespace nos quais o serviço está disponível. Para obter mais informações, consulte [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Sim | | Cluster | Cliente | Os clusters podem adicionar um namespace padrão do Service Connect. Novos serviços no cluster herdam o namespace quando o Service Connect é configurado em um serviço. | Não | | Cluster | Cliente-servidor | Não há alterações disponíveis para o Service Connect em clusters que se aplicam aos serviços de servidor. As definições de tarefa e os serviços do servidor devem definir a respectiva configuração. | N/D | **Visão geral das etapas para configurar o Service Connect** As etapas apresentadas a seguir fornecem uma visão geral de como configurar o Service Connect. **Importante** O Service Connect cria serviços do AWS Cloud Map em sua conta. Modificar esses recursos AWS Cloud Map registrando/cancelando manualmente o registro de instâncias, alterando os atributos da instância ou excluindo um serviço, pode causar um comportamento inesperado no tráfego da sua aplicação ou em implantações subsequentes. O Service Connect não oferece suporte a links na definição de tarefa. 1. Adicione os nomes das portas aos mapeamentos das portas nas definições das suas tarefas. Além disso, você pode identificar o protocolo de camada 7 da aplicação para obter métricas adicionais. 1. Crie um cluster com um namespace do AWS Cloud Map, use um namespace compartilhado ou crie o namespace separadamente. Para uma organização simples, crie um cluster com o nome desejado para o namespace e especifique o nome idêntico para o namespace. Nesse caso, o Amazon ECS cria um novo namespace HTTP com a configuração necessária. O Service Connect não usa nem cria zonas hospedadas por DNS no Amazon Route 53. 1. Configure serviços para criar endpoints do Service Connect dentro do namespace. 1. Implemente serviços para criar os endpoints. O Amazon ECS adiciona um contêiner do proxy do Service Connect a cada tarefa e cria os endpoints do Service Connect no AWS Cloud Map. Esse contêiner não é configurado na definição da tarefa e a definição da tarefa pode ser reutilizada sem modificação para criar vários serviços no mesmo namespace ou em vários namespaces. 1. Implemente aplicações clientes como serviços para conexão aos endpoints. O Amazon ECS as conecta a endpoints do Service Connect por meio do proxy do Service Connect de cada tarefa. As aplicações só usam o proxy para se conectar aos endpoints do Service Connect. Não há configuração adicional para usar o proxy. O proxy executa balanceamento de carga round-robin, detecção de valores discrepantes e novas tentativas. Para obter mais informações sobre o proxy, consulte [Proxy do Service Connect](service-connect-concepts-deploy.md#service-connect-concepts-proxy). 1. Monitore o tráfego por meio do proxy Service Connect no Amazon CloudWatch. ## Configuração do cluster É possível configurar um namespace padrão para o Service Connect ao criar ou ao atualizar o cluster. O nome do namespace que você especifica como padrão pode estar na mesma Região da AWS e conta ou na mesma Região da AWS e ser compartilhado por outra Conta da AWS usando o AWS Resource Access Manager. Se você criar um cluster e especificar um namespace padrão do Service Connect, o cluster aguardará no status `PROVISIONING` enquanto o Amazon ECS cria o namespace. É possível ver um `attachment` no status do cluster que mostra o status do namespace. Os anexos não são exibidos por padrão na AWS CLI. Você deve adicionar `--include ATTACHMENTS` para vê-los. Se você quiser usar um namespace compartilhado com sua Conta da AWS usando o AWS RAM, especifique o nome do recurso da Amazon (ARN) do namespace na configuração do cluster. Para obter mais informações sobre o uso de namespaces compartilhados do AWS Cloud Map, consulte [Amazon ECS Service Connect com Namespaces compartilhados do AWS Cloud Map](service-connect-shared-namespaces.md). ## Configuração de serviço O Service Connect foi projetado para exigir a configuração mínima. Você precisa definir um nome para cada mapeamento de porta que você gostaria de usar com o Service Connect na definição da tarefa. No serviço, você precisa ativar o Service Connect e selecionar um namespace em sua Conta da AWS ou um namespace compartilhado para criar um serviço de cliente. Para criar um serviço de cliente-servidor, você precisa adicionar uma única configuração do serviço do Service Connect que corresponda ao nome de um dos mapeamentos de porta. O Amazon ECS reutiliza o número da porta e o nome da porta da definição da tarefa para definir o serviço e o endpoint do Service Connect. Para substituir esses valores, você pode usar os outros parâmetros **Descoberta**, **DNS** e **Porta** no console ou `discoveryName` e `clientAliases`, respectivamente, na API do Amazon ECS. ## Configuração da verificação de integridade inicial O Service Connect garante que as tarefas estejam íntegras antes de rotear o tráfego para elas. Quando uma tarefa é iniciada (durante implantações, escala ou substituições), o Service Connect monitora a integridade da tarefa para garantir que ela esteja pronta para aceitar tráfego. Você deve definir verificações de integridade para o contêiner essencial em sua definição de tarefa para permitir esse comportamento. O comportamento da verificação de integridade inicial explica possíveis atrasos na obtenção do estado em que uma tarefa está pronta para aceitar tráfego: + Se uma tarefa for `HEALTHY`, ela estará imediatamente disponível para o tráfego. + Se a integridade de uma tarefa for `UNKNOWN`, o Service Connect seguirá a configuração de verificação de integridade (consulte [Verificação de integridade](task_definition_parameters.md#container_definition_healthcheck)) dos contêineres essenciais da tarefa para calcular um tempo limite, de até `8 minutes`, antes de disponibilizá-la para o tráfego, mesmo que ela permaneça `UNKNOWN`. + Se uma tarefa for `UNHEALTHY`, o Amazon ECS poderá iniciar tarefas de substituição. Se nenhuma tarefa íntegra estiver disponível, sua implantação poderá ser revertida com base na configuração do serviço. Para todo o tráfego contínuo, o Service Connect usa verificações de integridade passivas com base na detecção de valores discrepantes para rotear o tráfego com eficiência. # Amazon ECS Service Connect com Namespaces compartilhados do AWS Cloud Map O Amazon ECS Service Connect oferece suporte ao uso de namespaces compartilhados do AWS Cloud Map entre várias Contas da AWS dentro da mesma Região da AWS. Esse recurso permite criar aplicações distribuídas nas quais serviços executados em diferentes Contas da AWS podem descobrir e se comunicar uns com os outros por meio do Service Connect. Os namespaces compartilhados são gerenciados usando o AWS Resource Access Manager (AWS RAM), que permite o compartilhamento seguro de recursos entre contas. Para obter mais informações sobre namespaces compartilhados, consulte [Compartilhamento de namespaces do AWS Cloud Map entre contas](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) no *Guia do desenvolvedor do AWS Cloud Map*. **Importante** Você deve usar a permissão gerenciada `AWSRAMPermissionCloudMapECSFullPermission` para compartilhar o namespace para que o Service Connect funcione corretamente com ele. Quando você usa namespaces compartilhados do AWS Cloud Map com o Service Connect, serviços de várias Contas da AWS podem participar do mesmo namespace de serviço. Isso é útil especialmente para organizações com várias Contas da AWS que precisam manter a comunicação entre serviços além dos limites da conta, preservando a segurança e o isolamento. **nota** Para se comunicar com serviços que estão em VPCs diferentes, você precisará configurar a conectividade entre VPCs. Isso pode ser feito usando uma conexão de emparelhamento da VPC. Para obter mais informações, consulte [Criar ou excluir uma conexão de emparelhamento da VPC](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) no *Guia de emparelhamento da Amazon Virtual Private Cloud (VPC)*. # Usar namespaces compartilhados do AWS Cloud Map com o Amazon ECS Service Connect A configuração de namespaces compartilhados do AWS Cloud Map para o Service Connect envolve as seguintes etapas: proprietário do namespace criando-o, proprietário compartilhando-o por meio do AWS Resource Access Manager (AWS RAM), consumidor aceitando o compartilhamento de recursos e consumidor configurando o Service Connect para usar o namespace compartilhado. ## Etapa 1: criar o namespace do AWS Cloud Map O proprietário do namespace cria um namespace do AWS Cloud Map que será compartilhado com outras contas. **Para criar um namespace para compartilhamento usando o Console de gerenciamento da AWS** 1. Abra o console AWS Cloud Map do em [https://console.aws.amazon.com/cloudmap/](https://console.aws.amazon.com/cloudmap/). 1. Escolha **Create namespace (Criar namespace)**. 1. Insira um **nome de namespace**. Esse nome será usado pelos serviços em todas as contas participantes. 1. Para **Tipo de namespace**, escolha o tipo apropriado para o seu caso de uso: + **Chamadas de API**: namespaces HTTP para descoberta de serviços sem a funcionalidade de DNS. + **Chamadas de API e consultas ao DNS em VPCs**: namespaces de DNS privados para descoberta de serviços com consultas ao DNS privadas em uma VPC. + **Chamadas de API e consultas ao DNS públicas**: namespaces de DNS públicos para descoberta de serviços com consultas ao DNS públicas. 1. Escolha **Create namespace (Criar namespace)**. ## Etapa 2: compartilhar o namespace usando o AWS RAM O proprietário do namespace usa o AWS RAM para compartilhar o namespace com outras Contas da AWS. **Para compartilhar um namespace usando o console do AWS RAM** 1. Abra o console do AWS RAM em [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/). 1. Escolha **Criar compartilhamento de recursos**. 1. Em **Nome**, insira um nome descritivo para o compartilhamento de recursos. 1. Na seção **Recursos**: 1. Em **Tipo de recurso**, escolha **Namespaces do Cloud Map**. 1. Selecione o namespace criado na etapa anterior. 1. Na seção **Permissões gerenciadas**, especifique **AWSRamPermissionCloudMapECSFullPermission**. **Importante** Você deve usar a permissão gerenciada `AWSRAMPermissionCloudMapECSFullPermission` para compartilhar o namespace para que o Service Connect funcione corretamente com ele. 1. Na seção **Entidades principais**, especifique as Contas da AWS com as quais você deseja compartilhar o namespace. Você pode inserir IDs de conta ou IDs de unidades organizacionais. 1. Escolha **Criar compartilhamento de recursos**. ## Etapa 3: aceitar o compartilhamento de recursos As contas de consumidores de namespace devem aceitar o convite de compartilhamento de recursos para usar o namespace compartilhado. **Para aceitar um convite de compartilhamento de recursos usando o console do AWS RAM** 1. Na conta de consumidor, abra o console do AWS RAM em [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/). 1. No painel de navegação, selecione **Compartilhado comigo**; em seguida, escolha **Compartilhamentos de recursos**. 1. Selecione o convite de compartilhamento de recursos e escolha **Aceitar compartilhamento de recursos**. 1. Depois de aceitar, anote o ARN do namespace compartilhado nos detalhes do recurso. Você usará esse ARN ao configurar os serviços do Service Connect. ## Etapa 4: configurar um serviço do Amazon ECS com o namespace compartilhado Depois de aceitar o namespace compartilhado, o consumidor do namespace pode configurar os serviços do Amazon ECS para usar o namespace compartilhado. A configuração é semelhante ao uso de um namespace normal, mas você deve especificar o ARN do namespace em vez do nome. Para obter um procedimento detalhado de criação de serviço, consulte [Criação de uma implantação de atualização contínua do Amazon ECS](create-service-console-v2.md). **Para criar um serviço com um namespace compartilhado usando o Console de gerenciamento da AWS** 1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Na página **Clusters**, selecione o cluster no qual deseja criar o serviço. 1. Em **Serviços**, escolha **Criar**. 1. Depois de preencher outros detalhes, dependendo da sua workload, na seção **Service Connect**, escolha **Usar Service Connect**. 1. Em **Namespace**, insira o ARN completo do namespace compartilhado. O formato do ARN é: `arn:aws:servicediscovery:region:account-id:namespace/namespace-id` 1. Defina as configurações restantes do Service Connect conforme necessário para seu tipo de serviço (cliente ou cliente-servidor). 1. Conclua o processo de criação de serviço. Você também pode configurar serviços usando a AWS CLI ou os SDKs da AWS especificando o ARN do namespace compartilhado no parâmetro `namespace` do `serviceConnectConfiguration`. ``` aws ecs create-service \ --cluster my-cluster \ --service-name my-service \ --task-definition my-task-def \ --service-connect-configuration '{ "enabled": true, "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890", "services": [{ "portName": "web", "discoveryName": "my-service", "clientAliases": [{ "port": 80, "dnsName": "my-service" }] }] }' ``` ## Considerações Considere o seguinte ao usar namespaces compartilhados do AWS Cloud Map com o Service Connect: + O AWS RAM deve estar disponível na Região da AWS em que você deseja usar o namespace compartilhado. + O namespace compartilhado deve estar na mesma Região da AWS que os serviços e clusters do Amazon ECS. + Você deve usar o ARN do namespace, não o ID, ao configurar o Service Connect com um namespace compartilhado. + Todos os tipos de namespace são aceitos: HTTP, DNS privado e DNS público. + Se o acesso a um namespace compartilhado for revogado, as operações do Amazon ECS que exigirem interação com o namespace (como`CreateService`, `UpdateService` ECS `ListServicesByNamespace`) falharão. Para obter mais informações sobre como solucionar problemas de permissões com namespaces compartilhados, consulte [Solução de problemas do Amazon ECS Service Connect com namespaces compartilhados do AWS Cloud Map](service-connect-shared-namespaces-troubleshooting.md). + Para descoberta de serviços usando consultas ao DNS em um namespace de DNS privado compartilhado: + O proprietário do namespace precisará chamar `create-vpc-association-authorization` com o ID da zona hospedada privada associada ao namespace e a VPC do consumidor. ``` aws route53 create-vpc-association-authorization --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678 ``` + O consumidor do namespace precisará chamar `associate-vpc-with-hosted-zone` com o ID da zona hospedada privada. ``` aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678 ``` + Somente o proprietário do namespace pode gerenciar o compartilhamento de recursos. + Os consumidores de namespace podem criar e gerenciar serviços dentro do namespace compartilhado, mas não podem modificar o namespace em si. + Os nomes de descoberta devem ser exclusivos no namespace compartilhado, independentemente da conta que cria o serviço. + Os serviços no namespace compartilhado podem descobrir e se conectar a serviços de outras contas da AWS que tenham acesso ao namespace. + Ao habilitar o TLS para o Service Connect e usar um namespace compartilhado, a autoridade de certificação (CA) CA Privada da AWS tem como escopo o namespace. Quando o acesso ao namespace compartilhado é revogado, o acesso à CA é interrompido. + Ao trabalhar com um namespace compartilhado, proprietários e consumidores de namespace não têm acesso às métricas do Amazon CloudWatch entre contas, por padrão. As métricas de destino são publicadas somente em contas que possuem serviços de cliente. Uma conta que possui serviços de cliente não tem acesso às métricas recebidas por uma conta que possui serviços de cliente/servidor e vice-versa. Para permitir o acesso entre contas às métricas, configure a observabilidade entre contas do CloudWatch. Para obter mais informações sobre a configuração da observabilidade entre contas, consulte [Observabilidade entre contas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html) no *Guia do usuário do Amazon CloudWatch*. Para obter mais informações sobre as métricas do CloudWatch para o Service Connect, consulte [Métricas do CloudWatch do Amazon ECS](available-metrics.md). # Solução de problemas do Amazon ECS Service Connect com namespaces compartilhados do AWS Cloud Map Use as informações a seguir para solucionar problemas com namespaces compartilhados do AWS Cloud Map e com o Service Connect. Para obter mais informações sobre a localização de mensagens de erro, consulte [Solução de problemas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html). As mensagens de erro relacionadas a problemas de permissões aparecem por causa da falta de permissões ou se o acesso ao namespace for revogado. **Importante** Você deve usar a permissão gerenciada `AWSRAMPermissionCloudMapECSFullPermission` para compartilhar o namespace para que o Service Connect funcione corretamente com ele. A mensagem de erro aparece em um dos seguintes formatos: Ocorreu um erro (ClientException) ao chamar a operação
If you see this page, the nginx web server is successfully installed and working. Further configuration is required.
For online documentation and support please refer to
nginx.org.
Commercial support is available at
nginx.com.
Thank you for using nginx.
``` **Para visualizar as métricas do Service Connect** O proxy do Service Connect cria métricas de aplicações (conexão HTTP, HTTP2, gRPC ou TCP) nas métricas do CloudWatch. Ao usar o console do CloudWatch, consulte as dimensões de métricas adicionais de **DiscoveryName**, (**DiscoveryName, ServiceName, ClusterName**), **TargetDiscoveryName** e (**TargetDiscoveryName, ServiceName, ClusterName**) no namespace do Amazon ECS. Para obter mais informações sobre essas métricas e dimensões, consulte [Visualizar métricas disponíveis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html) no Guia do usuário do Amazon CloudWatch Logs. # Uso da descoberta de serviços para conectar serviços do Amazon ECS com nomes DNS O serviço do Amazon ECS pode ser opcionalmente configurado para usar a descoberta de serviço do Amazon ECS. A descoberta de serviço usa ações de API do AWS Cloud Map para gerenciar namespaces HTTP e DNS para serviços do Amazon ECS. Para obter mais informações, consulte [O que é o AWS Cloud Map?](https://docs.aws.amazon.com/cloud-map/latest/dg/Welcome.html) no *Guia do desenvolvedor do AWS Cloud Map*. A descoberta de serviço está disponível nas seguintes regiões da AWS: | Nome da Região | Região | | --- | --- | | Leste dos EUA (Norte da Virgínia) | us-east-1 | | Leste dos EUA (Ohio) | us-east-2 | | 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 (Taipei) | ap-east-2 | | Ásia-Pacífico (Mumbai) | ap-south-1 | | Ásia-Pacífico (Hyderabad) | ap-south-2 | | Ásia-Pacífico (Tóquio) | ap-northeast-1 | | Ásia-Pacífico (Seul) | ap-northeast-2 | | Ásia-Pacífico (Osaka) | ap-northeast-3 | | Ásia-Pacífico (Singapura) | ap-southeast-1 | | Ásia-Pacífico (Sydney) | ap-southeast-2 | | Ásia-Pacífico (Jacarta) | ap-southeast-3 | | Ásia-Pacífico (Melbourne) | ap-southeast-4 | | Ásia-Pacífico (Malásia) | ap-southeast-5 | | Ásia-Pacífico (Nova Zelândia) | ap-southeast-6 | | Ásia-Pacífico (Tailândia) | ap-southeast-7 | | Canadá (Central) | ca-central-1 | | Oeste do Canadá (Calgary) | ca-west-1 | | China (Pequim) | cn-north-1 | | China (Ningxia) | cn-northwest-1 | | Europa (Frankfurt) | eu-central-1 | | Europa (Zurique) | eu-central-2 | | Europa (Irlanda) | eu-west-1 | | Europa (Londres) | eu-west-2 | | Europa (Paris) | eu-west-3 | | Europa (Milão) | eu-south-1 | | Europa (Estocolmo) | eu-north-1 | | Israel (Tel Aviv) | il-central-1 | | Europa (Espanha) | eu-south-2 | | Oriente Médio (Emirados Árabes Unidos) | me-central-1 | | México (Central) | mx-central-1 | | Oriente Médio (Barém) | me-south-1 | | América do Sul (São Paulo) | sa-east-1 | | AWS GovCloud (Leste dos EUA) | us-gov-east-1 | | AWS GovCloud (Oeste dos EUA) | us-gov-west-1 | ## Conceitos de descoberta de serviço A descoberta de serviço consiste nos seguintes componentes: + **Namespace de descoberta de serviço**: grupo lógico de serviços de descoberta de serviço que compartilham o mesmo nome de domínio, como `example.com`, que é onde você deseja rotear o tráfico. É possível criar um namespace com uma chamada para o comando `aws servicediscovery create-private-dns-namespace` ou no console do Amazon ECS. É possível usar o comando `aws servicediscovery list-namespaces` para exibir as informações resumidas sobre os namespaces criados pela conta atual. Para obter mais informações sobre os comandos de descoberta de serviço, consulte `[create-private-dns-namespace](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/create-private-dns-namespace.html)` e `[list-namespaces](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/list-namespaces.html)` no *Guia de referência da AWS CLI do AWS Cloud Map (descoberta de serviço)*. + **Serviço de descoberta de serviço**: existe no namespace de descoberta de serviço e consiste no nome do serviço e na configuração do DNS para o namespace. Ele fornece os seguintes componentes principais: + **Service registry (Registro do serviço)**: permite pesquisar um serviço por meio de DNS ou ações de API do AWS Cloud Map disponíveis que podem ser usados para se conectar ao serviço. + **Instância de descoberta de serviço**: existe no serviço de descoberta de serviço e consiste nos atributos associados a cada serviço do Amazon ECS no diretório de serviços. + **Atributos de instância**: os metadados a seguir são adicionados como atributos personalizados para cada serviço do Amazon ECS configurado para usar a descoberta de serviço: + **`AWS_INSTANCE_IPV4`**: para um registro `A`, o endereço IPv4 que o Route 53 retorna em resposta a consultas de DNS e que o AWS Cloud Map retorna ao descobrir detalhes da instância, por exemplo, `192.0.2.44`. + **`AWS_INSTANCE_IPV6`**: para um registro `AAAA`, o endereço IPv6 que Route 53 retorna em resposta a consultas ao DNS e que AWS Cloud Map retorna ao descobrir detalhes da instância, por exemplo, ` 2001:0db8:85a3:0000:0000:abcd:0001:2345`. `AWS_INSTANCE_IPv4` e `AWS_INSTANCE_IPv6` são adicionados aos serviços de pilha dupla do Amazon ECS. Apenas `AWS_INSTANCE_IPv6` é adicionado para serviços somente IPv6 do Amazon ECS. + **`AWS_INSTANCE_PORT`** – o valor da porta associado ao serviço de descoberta de serviço. + **`AVAILABILITY_ZONE`** – a zona de disponibilidade na qual a tarefa foi iniciada. Para tarefas que usam o EC2, essa é a zona de disponibilidade na qual a instância de contêiner existe. Para tarefas que usam o Fargate, essa é a zona de disponibilidade na qual a interface de rede elástica existe. + **`REGION`** – a região em que a tarefa existe. + **`ECS_SERVICE_NAME`** – o nome do serviço do Amazon ECS ao qual a tarefa pertence. + **`ECS_CLUSTER_NAME`** – o nome do cluster do Amazon ECS ao qual a tarefa pertence. + **`EC2_INSTANCE_ID`** – o ID da instância de contêiner na qual a tarefa foi posicionada. Esse atributo personalizado não será adicionado se a tarefa estiver usando o Fargate. + **`ECS_TASK_DEFINITION_FAMILY`** – a família de definições de tarefa que a tarefa está usando. + **`ECS_TASK_SET_EXTERNAL_ID`**: se um conjunto de tarefas for criado para uma implantação externa e for associado a um registro de descoberta de serviço, o atributo `ECS_TASK_SET_EXTERNAL_ID` conterá o ID externo do conjunto de tarefas. + **Verificações de integridade do Amazon ECS**: o Amazon ECS executa verificações de integridade periódicas em nível de contêiner. Se não passar na verificação de integridade, o endpoint é removido do roteamento de DNS e marcado como não íntegro. ## Considerações sobre descoberta de serviço As seguintes informações devem ser considerada ao usar a descoberta de serviço: + A descoberta de serviços é compatível com as tarefas no Fargate se você está usando a versão 1.1.0 ou posterior da plataforma. Para obter mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md). + Os serviços configurados para usar a descoberta de serviços têm um limite de 1.000 tarefas por serviço. Isso se deve a uma cota de serviço do Route 53. + O fluxo de trabalho Create Service (Criar serviço) no console do Amazon ECS é compatível apenas com o registro de serviços em namespaces DNS privados. Quando um namespace DNS privado do AWS Cloud Map for criado, será criada automaticamente uma zona hospedada privada do Route 53. + Os atributos DNS da VPC devem ser configurados para resoluções DNS bem-sucedidas. Para obter informações sobre como configurar os atributos, consulte [Suporte a DNS na sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support) no *Guia do usuário da Amazon VPC*. + O Amazon ECS não oferece suporte ao registro de serviços em namespaces AWS Cloud Map compartilhados. + Os registros de DNS criados para um serviço de descobertra de serviço sempre são registrados com o endereço IP privado da tarefa, em vez do endereço IP público, mesmo quando são usados namespaces públicos. + A descoberta de serviço exige que as tarefas especifiquem o modo de rede `awsvpc`, `bridge` ou `host` (`none` não é compatível). + Se a definição de tarefa de serviço usar o modo de rede `awsvpc`, será possível criar qualquer combinação de registros `A` ou `SRV` para cada tarefa de serviço. Se você usar registros `SRV`, uma porta será necessária. Além disso, você poderá criar registros `AAAA` se o serviço usar sub-redes de pilha dupla. Se o serviço usar sub-redes somente IPv6, não será possível criar registros `A`. + Se a definição de tarefa de serviço usa o modo de rede `bridge` ou `host`, o único tipo de registro DNS com suporte é o registro SRV. Crie um registro SRV para cada tarefa de serviço. O registro SRV deve especificar o nome do contêiner e a combinação de portas do contêiner da definição de tarefa. + Os registros de DNS de um serviço de descoberta de serviço podem ser consultados na VPC. Eles usam o seguinte formato: `Your application is now running on a container in Amazon ECS.