E aí, pessoal?

Neste artigo, quero compartilhar com vocês as experiências que tive com Elastic Beanstalk. Inicialmente, gostaria de mostrar como subir uma aplicação simples, fazer deploy de novas versões e ter um overview do produto. Em um próximo artigo, vamos ver os tipos de deploy, como customizar as máquinas da nossa frota, monitorar e deixar um ambiente mais maduro para aguentar a porrada da produção.

Depois vamos ver uma maneira bem louca de automatizar isso, deployar esse código de infra e, aí sim, cobrir desde a subida de um ambiente de homologação até a produção automatizada e segura.

Missão: subir um ambiente que seja altamente disponível, fácil de deployar e seguro de escalar. Para ontem.

Observação: vamos considerar um cenário muito comum em startup, no qual não temos ninguém muito experiente em AWS, microservices (eles se reproduzem cara! Acredite, os devs adoram criar novos serviços) e nesse caso, tudo “muito bem configurado” e uma VPC para todos os ambientes, dev, homolog e prod. Olha que beleza! Tudo muito Serto, hein?! Hahaha

Vamos ajudar nisso aí!

Basicamente, o diálogo é esse:

– Cara, preciso subir uma aplicação web, tem que ter load balancer, auto scaling e deploy seguro. E tenho que fazer tudo isso hoje, rapidão.
– Por que, campeão?
– Os devs têm que iniciar logo o desenvolvimento de uma feature importante, e tá todo mundo pilhado, o que eu faço?

E a resposta é:

• Configura um environment padrãoZão no Beanstalk;
• Sobe o pacote (zipão maroto da aplicação);
• Espera uns 10 minutos para tudo subir e manda os devs TRAMPAREM (eles estavam achando que iria demorar o dia inteiro e já estavam sacando o smartphone pra mandar um PokemoGO, manja? Só que não! Aqui é zika mulek!).

Segue o jogo!

• Quando o ambiente estiver no ar e rodando o pacotão, clona esse environment e faz o de pré-produção;
• Se der certo clona novamente, ajusta as configurações com as variáveis de prod e abraço amigão! Tamo em prod!

Bom, essa é a melhor maneira de fazer? Não! Então, como é?

Existem alguns princípios que podem nortear decisões quanto à arquitetura, segurança etc. Segregar VPCs ou contas e mínimo acesso (security groups com acesso apenas ao indispensável para a solução rodar) são alguns deles. Deixar o ambiente de produção em uma conta separada também é uma boa, mas se não der, pelo menos deixe em uma VPC exclusiva.

Mas sabemos que muita gente está em um cenário mais simples e com menos recursos. Então, são esses que estamos buscando, o trapézi… kkk zueira, mas espero que tenham entendido.

Agora, é mão na massa! Vamos subir um ambiente no Beanstalk com os valores padrão e depois, analisar os aspectos mais importantes, ok?

1. Primeiro, faça o login na conta e encontre o dashboard do Beanstalk:

Services > Compute > ElasticBeanstalk

2. Crie uma aplicação:

3. Escolha um nome para a aplicação:

4. E aí temos dois tipos de ambientes para escolher: Web Application ou Worker. Depois veremos com mais detalhes, mas por hora vamos de Web Application:

5. Agora vamos escolher uma stack predefinida. Vamos de PythÃO com auto scaling e ELB para garantir a alta disponibilidade, certo champs?

6. Vou deixar o sampler application mesmo, para o que precisamos está ok. Na parte de “Deployment Preferences” vamos deixar do jeito que está. Daqui a pouco vemos isso melhor;

7. Vamos colocar um nome para o environment. E como é o primeiro, vamos fazer o de homolog. Veja que a URL que ele sugere já está em verde, e isso significa que está disponível e é esse endereço que usaremos para acessar, seja direto no nome ou por um registro que podemos criar em uma entrada de DNS:

8. Agora vamos configurar os aspectos voltados à instância e rede. Não vamos criar um RDS agora, e depois eu explico porquê.

9. Nessa sessão, temos os detalhes de configuração. Vamos deixar tudo padrão, com exceção da parte de EC2 key pair. Coloque a sua chave (crie uma, se não tiver) para você poder acessar a máquina depois;

10. Aqui surgem as tags. Lembre-se de que, por padrão, os nomes das máquinas sobem com o mesmo nome do env, para facilitar a identificação:

11. Agora, a configuração da VPC. Como estamos subindo uma versão sample, podemos deixar exposto para a internet, então veja que a opção “Associate Public IP Address” está marcada e a opção “ELB visibility” está como external;

12. Setando as permissões, deixa padrão:

13. Por fim, tem uma tela de review para você conferir antes de lançar o ambiente:

14. Agora, temos o nosso ambiente no ar e operando, e o dashboard fica mais ou menos assim:

Veja que agora temos um overview do ambiente que mostra o status (ok), a versão que está rodando (Sample Application), uns logs do Beanstalk (Recent Events), um menu à esquerda e o endereço do ambiente (http://app-correria-dev.us-east-1.elasticbeanstalk.com/), que é perfeitamente acessível da internet.

Pronto! Agora…

Segura um tempo aí!

Recapitulando: agora temos um ambiente no ar, acessível pela internet, com configuração de autoscaling, load balancer e tudo feito em menos de 20 min, facião?

– Sim champs, loko né?

Com isso em mãos, podemos entender melhor a ferramenta, como operá-la e algumas boas práticas para serem aplicadas aos ambientes de desenvolvimento, homologação e produção. Vamos para a próxima parte, então.

Fazendo alguns ajustes no ambiente para staging

Bem, acabamos de subir um ambiente para staging, e como usamos valores padrão para quase todos os parâmetros, certamente precisaremos rever algumas configurações para adequá-las à nossa necessidade.

Como a nossa ideia com esse ambiente é realizar testes com o nosso código novo, eu acho que uma máquina rodando já é o suficiente, certo? Mais do que isso seria desperdício, então, vamos ajustar assim: no dashboard, clique em Configuration e depois Scaling:

Depois de selecionar o grupo Scaling teremos essa imagem aqui:

Então, podemos ver algumas informações como quantas instâncias estão rodando no momento (= 1), e o número máximo que a nossa frota pode chegar (= 4). Vamos ajustar a sessão Auto Scaling colocando o valor máximo de uma máquina também, afinal é um ambiente de staging e não precisamos escalá-lo:

Podemos ver que conseguimos escolher em quais *AZs podemos subir as máquinas (neste caso está setado como ANY). Abaixo, temos o valor em segundos do Scaling cooldown, e na prática imagine o seguinte: quando configuramos o auto scaling, definimos também o que irá desencadear o evento de scaling. Vamos imaginar que para esse gatilho definimos que será o consumo médio de CPU.

Nesse caso, se a média atingir 70% de CPU o auto scaling deve ser trigado por um evento do CloudWatch (um alarme começará a soar), gerando um evento de scaling que vai subir uma máquina. Porém, quando a nossa máquina sobe, demora um pouco para ficar pronta em função da nossa aplicação, que leva quatro minutos para subir (muito, né?). Enquanto isso, esse alarme no CloudWatch continuará soando e o auto scaling continuará subindo máquina para garantir que a frota dê conta dessa demanda. Isso pode gerar um prejuízo, hein?

Tendo o Scaling cooldown bem configurado, o auto scaling irá esperar um tempo até a nova máquina subir e ficar pronta e ele vai saber se realmente vai precisar subir mais máquinas ou se a frota já está sendo capaz de atender.

Pronto, ajustamos o tamanho máximo da nossa frota de máquinas de acordo com o intuito do ambiente. Agora vamos verificar qual o gatilho que está sendo usado para esse scaling acontecer, quantas máquinas esse evento de scaling vai subir e o inverso também: qual o gatilho para o scaling down e quantas máquinas ele vai descer. Para isso, vamos olhar a sessão Scaling Trigger. Lá, vamos definir qual o gatilho e outros parâmetros. Como configuramos para ter no máximo uma máquina, esse passo é apenas demonstrativo, ok? Segue:

1. Vamos utilizar o consumo de CPU como  gatilho;
2. A estatística do trigger será a média de consumo do CPU;
3. A unidade de medida será porcentagem;
4. O período de coleta será no intervalo de 5 minutos;
5. O tempo que o pico de consumo deve durar para ser considerado uma “violação”;
6. O limite para que a frota seja aumentada, scaling up = 80% de consumo da CPU;
7. Subirá uma maquina por vez;
8. Quando a média do consumo voltar para 60%, diminua a frota;
9. Remova uma máquina por vez.

Pronto! Agora um ambiente de staging razoavelmente bem configurado e funcional, e quando você quiser testar uma nova versão só precisa fazer o upload do pacote via dashboard mesmo. Veja:

1. Clique em Upload and Deploy:

2. Selecione o zipão:

3. Escolha a versão nova e coloque um label:

4. Quando clicar em deploy você vai ver uma tela tipo essa:

5. E se der tudo certo, o dashboard ficará assim:

*Referência rápida para subir um pacote

E por hoje é isso! Conseguimos subir rapidamente um ambiente com autoscaling, loadbalancer e fácil de deployar. Claro que é algo bem simples, para começar. O próximo artigo vai ser interessante: vamos ver como podemos deployar a aplicação em produção e tipos de deploy, dentre outras coisas legais.

Um grande abraço e fiquem à vontade para fazer comentários, perguntas e sugestões nos campos abaixo. Até!

***

Artigo publicado originalmente em: http://www.concretesolutions.com.br/2016/11/17/como-usar-o-elastic-beanstalk/