Concrete Logo
Hamburger button

Como usar o Elastic Beanstalk

  • Blog
  • 17 de Novembro de 2016
Share

E aí, pessoal? De boas nas lagoas?

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 post, 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 loka 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. Simbora? Hoje vamo frenético, vamo na pegada bruxão, monstrão BIIIIRRRLLLL

birrrlll

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í 😉

gif-piratas-do-caribe

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 é:

1. Configura um environment padrãoZão no Beanstalk;

2. Sobe o pacote (zipão maroto da aplicação);

3. Espera uns 10 min  para tudo subir e manda os devs TRAMPAREM (eles estavam achando que iria demorar o dia inteiro e já estavam sacando o celPhoNe pra mandar um PokemoGO, manja? Só que não, aqui é Zika mulek!).

A 90-year-old heavy metal fan makes the rock hand-sign as she attends the 24th heavy metal Wacken Open Air (WOA) Festival 2013 in Wacken, northern Germany on August 1, 2013. With some 80,000 festival visitors it attracts all kinds of metal music fans, such as fans of black metal, death metal, power metal, thrash metal, gothic metal, folk metal and even metalcore, nu metal and hard rock from around the world. (Axel Heimken/Getty Images)

Foto: Axel Heimken/Getty Images

bebe-mamadeira

Segue o jogo!

4. Quando o ambiente estiver no ar e rodando o pacotão, clona esse environment e faz o de pré-produção;

5. 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, enfim. 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…, kkkk 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

image18

2- Crie uma aplicação;

image04

3- Escolha um nome para a aplicação;

image13

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;

image21

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

image23

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;

image07

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;

image25

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

image16

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;

image05

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;

image06

11- Agora sim, 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;

image10

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

image26

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

image27

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

image28

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 (https://app-correria-dev.us-east-1.elasticbeanstalk.com/), que é perfeitamente acessível da internet.

image19

Pronto! Agora…

now-wait-a-minute

Segura um tempo aí!

bebe-em-duvida

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:

image20

Depois de selecionar o grupo Scaling teremos essa imagem aqui:

image30

Aqui, 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:

image12

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:

image22

image29

– Vamos utilizar o consumo de CPU como  gatilho;

– A estatística do trigger será a média de consumo do CPU;

– A unidade de medida será porcentagem;

– O período de coleta será no intervalo de 5 minutos;

– O tempo que o pico de consumo deve durar para ser considerado uma “violação”;

– O limite para que a frota seja aumentada, scaling up = 80% de consumo da CPU;

– Subirá uma maquina por vez;

– Quando a média do consumo voltar para 60% diminua a frota;

– 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:

image08

2- Selecione o zipão:

image24

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

image15

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

image17

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

image01

*Referência rápida para subir um pacote: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create-deploy-python-flask.html

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  post vai ser maneiro, 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é!

Trabalha com DevOps e quer fazer parte do nosso time? Clique aqui