Troubleshooting no Elastic Beanstalk: ache o erro no log da EC2

Deploy no Elastic Beanstalk que falha ou fica rodando sem terminar, e o console não diz o porquê? Entre na instância EC2 pelo SSM e leia o log do próprio Elastic Beanstalk. Mostro isso em dois casos que reproduzi: um zip montado errado e uma máquina pequena demais.

A origem foi um desafio que passei na Formação AWS, em que muita gente travava num deploy de aplicação Docker. A aula é de dezembro de 2023, e telas e instâncias do console mudam. O que vale é o método. O local dos logs está na documentação oficial.

Por que olhar o log da EC2

Dá para mandar os logs do Elastic Beanstalk para o CloudWatch. Só que, quando o deploy não termina, você não sabe se o log não chegou ao CloudWatch ou se a aplicação deu problema. No caso dos meus alunos, o build da imagem Docker acontecia na própria EC2 e não finalizava.

Por isso o caminho é o arquivo onde o Elastic Beanstalk escreve na instância: /var/log/eb-engine.log. É a fonte do que aparece no console e do que vai para o CloudWatch. Ver esse arquivo acontecendo, no olho, tira a dúvida.

Se você ainda não fez um primeiro deploy, comece pelo post Elastic Beanstalk com Docker. Aqui parto do ambiente criado e vou direto ao diagnóstico.

1Criar o ambiente e conectar na instância

Criei uma aplicação BIA-YT e um ambiente BIA-YT-ENV com a plataforma Docker, a aplicação de exemplo do Elastic Beanstalk e Single Instance. As escolhas que importam:

• Instance profile: uma role com as permissões do Elastic Beanstalk e também uma policy para SSM, que é como entro na EC2 sem chave SSH.
• Rede: IP público e as três zonas de disponibilidade.
• Security group: basta um que libere a porta 80 para o mundo.
• Instância: t3.micro, monitoramento no padrão (aprimorado).

O ambiente leva uns 3 minutos para subir. Nesse tempo, abra o CloudShell da AWS: é um terminal que usa a sua sessão do console, sem credenciais na sua máquina (veja o post sobre o CloudShell). Clone o projeto da BIA, que tem um script de conexão por SSM:

git clone https://github.com/henrylle/bia
cd bia/scripts
./start-session-bash.sh <id-da-instancia>

O script recebe o ID da instância e abre a sessão. O ID está na EC2 que o Elastic Beanstalk lançou para o ambiente. Dentro da sessão:

sudo su
cat /var/log/eb-engine.log

Com o ambiente saudável, o fim do arquivo mostra o CommandService Response com "status":"SUCCESS" e a linha Platform Engine finished execution on command: app-deploy. Esse é o deploy que terminou bem.

2Acompanhar um novo deploy com tail

Antes de fazer o deploy, deixe o log correndo na sessão:

tail -f /var/log/eb-engine.log

Em outra aba, no Elastic Beanstalk, clique em Upload and deploy, escolha o zip e confirme. O zip vai para o S3, o Elastic Beanstalk o recebe na instância e o log começa a andar: extração do pacote, hooks e o build do Docker.

3Erro explícito, o zip com pasta

Montei dois zips, um com problema e um certo. No com problema, os arquivos do projeto estavam dentro de uma pasta no zip. É um erro comum: o Elastic Beanstalk procura o Dockerfile ou o Dockerrun.aws.json na raiz do zip.

No log, a falha apareceu na hora:

[ERROR] An error occurred during execution of command [app-deploy] - [Docker Specific Build Application]. Stop running the command. Error: Dockerfile and Dockerrun.aws.json are both missing, abort deployment

O mesmo texto aparece na aba Events do ambiente: "Both 'Dockerfile' and 'Dockerrun.aws.json' are missing in your source bundle". Aqui o console já bastava, e a correção é refazer o zip com o conteúdo na raiz.

4O deploy que não avança

Com o zip certo, o log passou da etapa inicial. Ele encontrou o Dockerfile, viu a imagem node:18-slim, não precisou baixar nenhuma imagem e começou o docker compose build. E parou aí. A última linha do log é esta:

[INFO] Running command /bin/sh -c docker compose pull --ignore-buildable
[INFO]  server Skipped - No image to be pulled
[INFO] successfully execute command: docker compose pull --ignore-buildable
[INFO] Running command /bin/sh -c docker compose build

Era o que acontecia com os alunos: o deploy ficava rodando, sem saída, e o Elastic Beanstalk não dava mais feedback. Depois de um tempo, o ambiente ficou em estado Degraded. A aba Events só registra o deploy em andamento, sem instância enviando dados.

Só o console deixa você perdido: nada diz que o build parou. O log da EC2 mostra a última linha executada, o docker compose build, que não anda. Nesse caso a causa era a máquina: o t3.micro não tinha poder computacional para concluir o build. Olhar a CPU e outras métricas da instância confirmaria o mesmo. Para entender que o comando parou ali, é preciso um pouco de Docker.

5Ambiente com instância maior e comparação

O ambiente travado não se resolve esperando. Criei outro, BIA-YT-ENV-MAIOR, igual ao primeiro (Docker, aplicação de exemplo, mesma instance profile, as três zonas, mesmo security group), só que com t3.medium, dois níveis acima. Conectei na nova instância com o mesmo script, abri o tail -f e, com o ambiente pronto, fiz o deploy do zip certo.

Com os dois terminais lado a lado, a diferença ficou clara. O log do ambiente pequeno estava parado no docker compose build. O do ambiente maior chegou à mesma linha e, em cerca de um minuto e meio, avançou e concluiu o deploy. O build deve soltar o log e avançar em cerca de 2 minutos, e essa instância tem 4 GB de memória.

Ao abrir a URL do ambiente maior, a aplicação da BIA respondeu.

Checklist

• Instance profile do ambiente com policy de SSM para entrar na EC2 sem chave SSH.
• CloudShell aberto, projeto clonado e conexão feita pelo script com o ID da instância.
• tail -f /var/log/eb-engine.log rodando antes de iniciar o deploy.
• Zip com Dockerfile ou Dockerrun.aws.json na raiz, não dentro de uma pasta.
• Erro explícito conferido tanto no log quanto na aba Events.
• Deploy parado no docker compose build tratado como falta de recurso: confirmar a última linha do log e as métricas da instância.
• Novo ambiente com instância maior para comparar os dois logs.

Troubleshooting é isso: ir ao local onde o erro nasce e ler. Na Formação AWS eu aprofundo esses assuntos na prática.