Docker na AWS: EC2 ou Elastic Beanstalk? Veja a diferença na prática

Dá para rodar um container direto numa EC2, e funciona. A diferença aparece quando a máquina morre ou quando você precisa entregar uma versão nova. Rodei a mesma aplicação com Docker nos dois caminhos, EC2 e Elastic Beanstalk, e terminei a instância para mostrar o que cada um faz por você.

A aula é de abril de 2024 e o console muda com o tempo: confira a plataforma Docker atual na documentação do Elastic Beanstalk.

A mesma aplicação nos dois caminhos

Usei a aplicação da BIA, em Node com React, que já vem com Dockerfile e docker-compose.yml. Tirei o banco do compose para ficar só com a aplicação web. Localmente ela sobe na porta 3001, mapeada para a 8080 do container.

O desenho abaixo mostra a diferença: na EC2 solta, o docker build acontece na máquina que você montou. No Elastic Beanstalk, você entrega um zip e ele cuida do resto.

Caminho 1: Docker direto na EC2

Na EC2, o trabalho é seu do começo ao fim:

1. Role IAM com a policy AmazonSSMManagedInstanceCore, para eu entrar na máquina pelo Session Manager (SSM) sem par de chaves.
2. Instância Amazon Linux de 64 bits, t3.micro, VPC padrão, subnet com IP público e 10 GB de disco.
3. Security group com regra de entrada HTTP, porta 80, liberada para o mundo.
4. User data com o script do projeto, que instala Git, Docker e Node e ajusta as permissões.
5. Conectar, clonar e ajustar: entrei pelo SSM, dei git clone e editei o docker-compose.yml com o nano, trocando a porta para 80:8080.
6. Subir: docker compose up -d. O build na máquina levou 78 segundos no total.

A aplicação respondeu na porta 80 pelo IP da instância. Para uma aplicação simples, isso atende, e dá até para configurar o Docker para reiniciar o container sempre que ele cair.

Os problemas estão em volta. Se essa máquina morrer, a aplicação sai do ar junto, e se a zona de disponibilidade em que ela está cair, também. E o projeto precisa ser baixado dentro da máquina para o build acontecer lá.

Caminho 2: o mesmo projeto no Elastic Beanstalk

O Elastic Beanstalk é um serviço gerenciado da AWS para rodar aplicações. Você cria a aplicação (bia) e, dentro dela, os ambientes. Criei um só, o bia-aula-yt.

Na criação do ambiente, o que ele já resolve:

• Endpoint. Ele entrega um endereço elasticbeanstalk.com para a aplicação.
• Plataforma. Em vez de preparar a máquina com user data para rodar Docker, você escolhe a plataforma Docker sobre Amazon Linux, e ele aplica patches de segurança e atualizações.
• Single instance, que é o que eu precisava para este caso.
• Service role. A permissão que o Elastic Beanstalk usa em seu nome para mexer em Auto Scaling, Load Balancer, EC2 e S3. O console lista cada permissão que ela envolve.
• Instance profile. A role da EC2, com as permissões para log, X-Ray e S3, de onde a instância baixa o pacote.. Criei a minha no IAM.
• Security group. O Elastic Beanstalk trabalha por convenção: se você não escolhe nenhum, ele cria um com a porta 80 liberada, e não dá para desabilitar o que ele cria. Para ter controle maior, crie o seu e escolha-o.

Depois do Submit, o log de eventos mostra o que ele montou sem você pedir: um bucket no S3 para guardar as versões, o security group e um IP elástico para a instância.

Entregar a aplicação: um zip, sem entrar na máquina

Na EC2, entregar foi conectar, clonar e rodar o build. No Elastic Beanstalk você sobe um pacote zip.

Ajustei o docker-compose.yml como antes (porta 80:8080) e, dentro da pasta do projeto, gerei o zip pela linha de comando (funciona em Linux e Mac; no Windows dá para zipar a pasta pelo explorador, desde que tudo fique na raiz):

zip -r bia.zip *

Os arquivos precisam ficar na raiz do zip, sem pasta por fora. Para conferir, extraí o zip numa pasta separada (out) com o unzip e vi que os arquivos ficaram soltos ali.

Em Upload and deploy, escolhi o bia.zip, e o Elastic Beanstalk deu o nome de versão bia.version1. O pacote vai para a área Application Versions, e de lá o serviço faz o deploy na EC2. Como cada versão fica guardada, subir outra e voltar para a anterior vira um deploy, e o rollback é só escolher a versão antiga.

Fiz a entrega no modo mais simples; dá para ligar o deploy a um pipeline com o CodePipeline, usar o eb deploy ou acionar por script.

O teste: terminar a instância

Com o deploy concluído, o docker ps na instância mostrou o container da BIA rodando. Então terminei a instância.

O Elastic Beanstalk percebeu que o ambiente estava sem instância e lançou outra, refez o vínculo com o IP elástico e mandou o Application Version fazer o deploy na máquina nova. O endereço continuou o mesmo.

Levou cerca de 3 minutos até o container subir de novo, e eu não fiz nada.

O Elastic Beanstalk em si não cobra a mais: você paga pelos recursos que ele usa, como o S3 com as versões, o IP elástico e a EC2. Valores e Free Tier mudam, então confira na página de preços da AWS.

A parte que pesa: o build exige uma instância maior

No Elastic Beanstalk roda bem mais coisa na instância do que numa EC2 solta. Para fazer o docker build ali, a t3.micro não dá conta e trava. Por isso escolhi a t3.medium no ambiente, como mostra a lista de instâncias acima.

Dá para usar uma t3.micro e reduzir esse custo. A saída é não fazer o build na instância: gere a imagem fora e publique no ECR, deixe no zip só o docker-compose.yml apontando para essa imagem e faça o deploy. A instância passa a só baixar a imagem (um docker pull) e rodar, e a carga cai bastante. O mesmo caminho cabe num pipeline: o CodePipeline faz o build, entrega a imagem ao ECR e produz o artefato com o compose para o Elastic Beanstalk.

Como escolher

A EC2 sozinha serve quando você quer o container no ar e aceita cuidar da máquina: o role, o security group, a conexão, o build e o que acontecer se ela cair. O Elastic Beanstalk entrega, para a mesma aplicação:

• o endereço e o IP elástico prontos;
• a plataforma Docker já preparada e com patches aplicados;
• a entrega por zip, com versões guardadas e rollback;
• a instância substituída sozinha, com a versão e o IP de volta;
• o caminho aberto para pipeline.

Para quem está começando projetos na AWS, vale a pena usar o Elastic Beanstalk, mesmo numa aplicação simples e sem load balancer. O preço é a instância maior, a menos que você mova o build para o ECR.

Ao terminar, encerre o ambiente: ele desliga a máquina e libera os recursos, e você evita cobrança de uma instância fora do Free Tier.

Checklist

• Mesma aplicação testada na EC2 (role SSM, security group na porta 80, clone, docker compose up -d).
• Aplicação e ambiente criados no Elastic Beanstalk com plataforma Docker e single instance.
• Service role e instance profile criados, e security group escolhido por você ou deixado por convenção.
• Zip com os arquivos na raiz, conferido com unzip.
• Deploy pelo Upload and deploy e versão guardada em Application Versions.
• Instância terminada de propósito para ver a recuperação, com o mesmo IP.
• Instância t3.medium para o build na instância, ou imagem no ECR para rodar em t3.micro.
• Ambiente encerrado ao final do teste.

Esse mesmo projeto, com pipeline, deploy por script e alta disponibilidade, é a base dos desafios da Formação AWS para Elastic Beanstalk.