AWS SERIES: FINAL … LAB: (testing) A PRODUCTION ENVIRONMENT-or-hello-world-cloud-infrastructure
Onze dias depois e cá estamos … Na verdade, dependendo de quando você chegou talvez seja bem menos … Quero dizer, atrasados lendo numa única tacada possa ser questão de algumas horas (…) Apressados devorando o conteúdo para pôr logo em prática, não sei 🤔 talvez uns poucos minutos?! (…) Assíduos seguidores do BLOG com certeza, e com propriedade, quase dois meses inteiros pois foi quando saiu o primeiro artigo dessa série sobre AWS. Perdidos e desnorteados 😬 confiram o que estou falando a seguir:
https://automatesmachines.org/2021/12/17/aws-series-nuvem-ou-cloud-computing/
Bem, não importando em qual perfil você se encaixa, o fato é que hoje veremos a integridade de uma aplicação web hospedada na nuvem, e que portanto “não para” (muitas aspas aqui) nunca. Em outros termos, a mesma não é interrompida jamais, garantindo assim uma disponibilidade de quase 99,9% (de novo, muitas aspas) aos usuários e clientes.
Dito isso, vamos à console (https://aws.amazon.com/pt/console/) Tenha em mente que o nosso objetivo aqui será acompanhar/validar a infraestrutura proposta e que foi implantada seguindo posts anteriores a esse. Dessa forma, nos concentraremos apenas, e tão somente, em duas telas. São elas: (1-a) Grupos de auto scaling e (2-b) Instâncias. Uma vez em (A) percebam que máquinas t2.micro são criadas e apagadas o tempo todo, ou seja, constantemente. Mas por que Victor? Lembram do nosso LOAD BALANCER e sua política de saúde para o grupo de instâncias? Pois é. Ele mesmo, em pessoa. É o próprio que está agindo e executando isso: iniciando e encerrando, iniciando e encerrando … Quando ele nota que determinada máquina está demorando a responder e não obtém o código HTTP 200 (OK), transcorrido 30 segundos de intervalo, o mesmo entende que aquela não está mais saudável e portanto a encerra, providenciando logo em seguida uma substituta “saudável”, zerada, e nova.
Vejam as minhas capturas de tela, e depois comparem às suas respectivas:
E então? Gostaram? 😎 Sei disso, sei disso … Mas peraí, e a aplicação? Como é que fica nisso tudo? Será que devo acessá-la por qualquer um dos IPs dessas máquinas executando? E agora Victor? Pra todas essas perguntas a resposta é NÃO. Lembre-se do nosso diagrama: partimos sempre do pressuposto que a chegada, ou entrada se preferir, ocorre por intermédio do balanceador de carga. Ele quem dita as regras, e muitas vezes nem sabemos para qual instância acaba indo todo o tráfego vindo de fora. Mas voltando ao questionamento inicial, o correto é ir navegando pelo nome de dns do LB … Para tanto, basta visualizá-lo em Balanceamento de carga > Load balancers
Depois é só copiar e colar CTRL-C + CTRL-V no seu browser favorito e pronto! Veja o resultado a seguir:
>_ ERROR 504 GATEWAY TIMED OUT
Errata: caso ainda não tenha visualizado a tela da aplicação, saiba que foi por minha causa (…) Negligenciei uma etapa e portanto faltou um passo importantíssimo: que é marcar o grupo de segurança padrão da VPC. Sem ele, é como se o LB e as EC2 estivessem em redes totalmente diferentes, e por tabela, não havendo roteamento entres os mesmos. Porém, sendo muito fácil de contorná-lo, bastando que vá até EC2 > Balanceamento de carga > Load balancers > Segurança > Editar grupos > Selecionar LB-acesso-regras + default
>_ TROUBLESHOOT
Links úteis para resolver eventuais “outros” erros do HTTP e afins …
https://sigopt.com/blog/the-case-of-the-mysterious-aws-elb-504-errors/
http://harish11g.blogspot.com/2012/07/aws-elastic-load-balancing-elb-amazon.html
https://medium.com/tenable-techblog/lessons-from-aws-nlb-timeouts-5028a8f65dda
https://docs.aws.amazon.com/autoscaling/ec2/userguide/healthcheck.html
https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html
Te vejo por aí 😉 Até mais!
