Victor Ricardo

Continuando do ponto em que paramos, crie uma nova imagem baseada em nosso ambiente web. Ela precisa refletir a configuração mais recente e atual possível, ou seja: apache + PHP instalados + página HTML de cadastro + salvamento dos dados informados remotamente via RDS … Para tanto, basta voltar ao post aqui referido. Nele ensino como fazê-lo em pouquíssimos passos.

https://automatesmachines.org/2022/01/20/aws-series-day-five-using-your-own-ami-or-custom-image/

Com isso, teremos duas imagens criadas, e pré-programadas para diferentes usos:

Guarde bem esta última, pois é a partir dela que garantiremos a alta disponibilidade da aplicação posteriormente.

>_ DRAW :: DESENHO

Alguns destaques importantes, além de breves percepções acerca da nossa infraestrutura:

• O retângulo maior representa a nuvem da AWS. Tudo o que está fora dele ou é a própria internet, ou são elementos de outras redes.
• Usuários comuns e clientes da aplicação estão liberados apenas para o tráfego web (portas: HTTP-80 / HTTPS-443)
• Todo esse fluxo de pacotes chega, necessariamente, primeiro no load balancer.
• Realizada a checagem de disponibilidade atual do ecossistema, é então liberado o encaminhamento para uma das instâncias EC2.
• Caso não haja recursos suficientes (memória e processamento) é sinalizado e autorizado a criação de novos para suprir a demanda atual.
• Uma vez terminada a interação do usuário, na forma de preenchimento de informações, e solicitado o armazenamento para uso imediato ou posterior, o banco de dados é acionado para esta função, e ocorre uma troca entre os serviços EC2 e RDS quase que instantaneamente.
• Computado tais dados, o usuário poderá seguir usando o restante da aplicação sem maiores problemas.
• Qualquer manutenção que porventura apareça no meio do caminho, esta deverá ser efetuada pela equipe de engenheiros na porta 22 do SSH, previamente liberada e prevista.

>_ LOAD BALANCER: HTTP E HTTPS

Localizado no painel de serviços EC2, percorrendo o caminho mostrado adiante, e depois movendo o cursor até o final da coluna esquerda, você encontrará um menu chamado Balanceamento de Carga. Expanda-o para abrir o submenu Load Balancers e por fim selecione a opção criar load balancer clicando com o botão direito:

HOME > EC2 > PAINEL > COLUNA ESQUERDA > BALANCEAMENTO > LOAD BALANCERS > CRIAR

Três tipos serão mostrados: (a) de aplicação (b) de rede e (c) de saída. Escolha o tipo aplicação:

O intuito aqui é que o mesmo fique em stand-by, escutando portas (80 e 443) e aguardando requisições. Sua interface, ou entrada, estará direcionada para o lado de fora da AWS, na prática sendo a internet ou qualquer outra rede de computadores. Somente após análise do LOAD BALANCER esse tráfego externo será redistribuído internamente, entre dois ou mais servidores.

Próxima seção de perguntas diz respeito às configurações de rede (VPC no caso da AWS):

Marque pelo menos duas regiões disponíveis da localidade atual (para mim: us-east-2, Ohio) Sem isso não há como garantir a continuidade e redundância da aplicação em nível de PRODUÇÃO.

Seguindo, temos o questionamento sobre o grupo de segurança a ser configurado … Crie um novo, para segmentar e controlar o acesso dos usuários.

Chamo a atenção para as capturas subsequentes, pois cada uma conta para o êxito do todo, não precisando assim reforçar que são extremamente importantes.

Muito bem, fato de número um para se tomar nota: quando falamos de roteamento envolvendo um load balancer, precisamos associá-lo a uma nomenclatura específica (sim 😕 mais uma!) Trata-se dos target groups, ou grupos-alvo em tradução livre. Seu objetivo é vigiar constantemente o estado mais recente de instâncias, endereços ip ou funções lambda. A ideia é simples, e serve para responder eventuais perguntas como: quem está livre? 🤔 quem está ocupado? 🤨 quem está ocioso há algum tempo?🧐

Segunda nota, e fato de número dois: health check ou verificação de saúde. Nome sugestivo e de fácil compreensão, diz respeito acerca da resposta obtida da raiz da aplicação web, na prática o barra ( / ) Se for HTTP 200, ok maravilha! Perfeito! Significa que o sistema está “vivo” e respondendo normalmente, sem nenhum tipo de demora, atraso ou erro. Agora se for o oposto, como por exemplo: HTTP 401 (não-autorizado); HTTP 403 (proibido); HTTP 404 (não-encontrado); HTTP 500 (erro interno); HTTP 502 (bad gateway); etc … Implica dizer que, algo errado não está certo! 😜 Então, por favor, descarte essa instância/ip/função e redirecione para as outras “saudáveis” !!!

Número três: registro dos alvos … Talvez o maior erro cometido pela maioria seja o fato de, apressadamente já selecionar aqui as instâncias que estão no ar, ou seja ligadas. Bom, quanto a isso o que posso afirmar é que não está errado, mas também não está totalmente certo. Recordem sempre: o que queremos é apontar numa única tacada todas as instâncias de um grupo. O que iria na contramão se optássemos pelo outro método: um clique, uma máquina (pensem no trabalho para +100 servidores) Então, somente por ora, vamos pular esta etapa. Siga em frente!

Revise suas configurações ao final da página. E aguarde o processo: