Amazon ECS na prática: o que ele resolve que a EC2 sozinha não

Rodar um container numa EC2 é fácil. Mantê-lo de pé quando a máquina cai, ou só o container cai, é o problema. Abaixo, o que o Amazon ECS assume nesse trabalho e como cluster, service, Auto Scaling Group e load balancer se encaixam num único desenho.

Gravei a aula em fevereiro de 2023, e telas e opções do console mudam com o tempo. O conceito se mantém; para o que está vigente, confira a documentação oficial do ECS.

O que o ECS tira das suas costas

O ECS é o serviço de orquestração de containers da AWS, totalmente gerenciado. A diferença está aí: você deixa de ser responsável por uma tarefa crítica, que é manter o seu container rodando.

Uso como exemplo uma aplicação WordPress, cuja imagem oficial está no Docker Hub, o repositório principal do Docker. Se quiser ver essa aplicação subindo sem ECS, tenho o WordPress na AWS com Docker.

O caminho convencional: uma EC2 com Docker

Quem ainda não conhece o ECS faz o óbvio. Lança uma EC2, uma máquina virtual na AWS, instala o Docker, talvez o Docker Compose, sobe as variáveis de ambiente e manda o container rodar. Libera o acesso, e o usuário chega na aplicação.

Agora imagine que a máquina caiu. A saída é lançar outra EC2, subir o container de novo e redirecionar o usuário. Faz isso manualmente toda vez?

Há dois problemas juntos: garantir que haja uma máquina disponível e saber se o container está rodando. Se só o container cair, quem percebe? Esse costuma ser o mindset inicial, e é o que o ECS substitui.

O cluster: máquinas como poder computacional

No ECS, você cria um cluster, que é uma série de recursos computacionais agrupados. Você diz quantas instâncias EC2 quer dentro dele, por exemplo duas.

O mindset que muda o jogo é este: no ECS, as máquinas virtuais são poder computacional. O cluster precisa de instâncias para ter onde rodar as coisas.

Service, task e task definition

Cada peça tem um post só dela. O resumo para seguir:

• Task: de forma simplista, um container rodando.
• Service: lança as tasks (você não lança uma sozinha), mantém o número que você pediu e faz a atualização no deploy ou na troca de imagem.
• Task definition: parente próxima do Docker Compose. Guarda o que o service não sabe da aplicação: imagem, porta, variáveis de ambiente e recursos, como 500 MB de memória.

Ao criar o service, você indica a task definition e quantas tasks quer.

O service cuida das tasks, o Auto Scaling Group cuida das máquinas

Digamos que você pediu uma task. O service trabalha sem parar para ter uma rodando. Se ela morrer, e container foi feito para morrer, o service procura poder computacional no cluster e lança outra. Por isso nada de guardar informação dentro do container: ela vai embora.

Se eu mudar para duas tasks, para ter alta disponibilidade (o que mudar na aplicação para isso está em Docker com alta disponibilidade), ele olha o cluster, vê uma EC2 livre e lança a segunda lá. Isso depende do tamanho: no meu exemplo, o recurso descrito na task definition ocupa uma EC2 inteira, então a segunda task precisa de outra máquina.

Quem cuida das máquinas é um serviço em comunicação com o cluster, o Auto Scaling Group. Se eu disse que queria duas EC2 no cluster, ele trabalha para manter as duas. O service mantém as tasks, o Auto Scaling Group mantém as instâncias. Para ver como esse grupo se configura, veja o Auto Scaling Group com launch template.

Faltou poder computacional para mais containers? Aumente-o no cluster com o Auto Scaling Group. O service continua pedindo "preciso lançar mais task", encontra capacidade e lança. Para a configuração atual, consulte a documentação de Auto Scaling do cluster.

O usuário chega pelo load balancer

Com duas EC2 e duas tasks, o acesso passa por um load balancer na frente. Ele distribui o tráfego. Para saber para onde mandar, há um Target Group, que se comunica com o service e conhece as duas tasks disponíveis.

Ele também trabalha junto com o service no deploy: enquanto uma task é trocada, o Target Group para de mandar tráfego para ela e envia só para a outra. Terminou, volta a mandar para as duas. A task antiga morre, a nova sobe e só então recebe tráfego.

No caso do WordPress, talvez você nem faça deploy, porque a imagem é a oficial e, se não for atualizar, não há o que trocar. O deploy faz mais sentido no segundo cenário. Para saber como o load balancer se liga ao service no ECS atual, veja a documentação de load balancing do service.

Quando a imagem é sua: ECR e rollback

No segundo cenário, a aplicação é sua: você baixa o projeto do GitHub, containeriza e só depois sobe para a AWS. Na sua máquina você só consegue gerar a imagem local, então usa o ECR, o registro de imagens da AWS, e a imagem passa a ser usada na task definition.

Subindo várias imagens com versões diferentes, você pode ter task definitions apontando para versões distintas, a 1, a 2, a 3. Se a 1 está rodando e você faz o deploy da 2 e dá problema, o rollback para a 1 fica facilitado. O cluster, junto com o service, faz a orquestração. O passo a passo disso está em primeiro container em produção no ECS.

O que ficou de fora

Eu mesmo disse na aula que falta muita coisa: Security Group, permissão para o ECR conversar com o cluster e outros pontos. Estranhar tanto termo novo é normal. Quando o cérebro tenta encaixar peças novas de uma vez, dá confusão, e isso faz parte do aprendizado.

Checklist

• Explicar por que uma EC2 com Docker não mantém o container disponível sozinha.
• Descrever o cluster como poder computacional composto por instâncias EC2.
• Diferenciar task, service e task definition.
• Saber quem mantém as tasks (service) e quem mantém as máquinas (Auto Scaling Group).
• Explicar o papel do load balancer e do Target Group durante um deploy.
• Usar o ECR e versões de imagem para facilitar o rollback.

Se você quer montar isso na prática, com cluster, service e load balancer funcionando de ponta a ponta, é o caminho da Formação AWS.