Início – BrenoCarvalho.Cloud

Veja como criar um ambiente de Blue/Green para um banco de dados RDS MySQL em produção e utilizar essa funcionalidade para upgrade do MySQL, reduzindo o downtime durante processo de upgrade de versão, possibilidade de rollback mais rápido entre outras possibilidades que irei comentar nesse post.

O Blue/Green deployment são dois ambientes, onde o ambiente Green (Ambiente de Teste) permanece sincronizado com o ambiente Blue (Ambiente de Produção) através de replicação lógica, possibilitando alterações e testes mais assertivos no ambiente Green sem afetar o banco em produção (Blue).

Vamos lá…

Para esse post, foi criado um banco de dados com a versão 8.0.28 (imagem abaixo) que será o Banco de Dados Blue e no momento da criação do Blue/Green Deployment iremos especificar a versão 8.0.32 para o Banco de dados Green com isso será possível simular um upgrade utilizando o recurso.

Banco de Dados MySQL com a versão 8.0.28

Com o banco de dados criado, vamos configurar o ambiente para funcionar como Blue/Green Deployment, acessando a console do RDS iremos selecionar o banco da dados e através do menu Action / Create Blue/Green Deployment iremos fazer as configurações:

Na próxima janela será configurado o Blue/Green deployment, inserindo o nome do ambiente, engine version (versão do banco de dados) e parameter group do banco de dados Green. Nesse ponto selecionamos a versão mais atual disponível.

Após selecionar as opções acima e finalizado o processo de criação do ambiente, que nessa demonstração demorou em torno de 16 minutos, será possível ver a seguinte estrutura abaixo na console do RDS:

Um ponto importante é que após a criação do Blue/Green Deployment, o endpoint de conexão continuará o mesmo, criando apenas um novo endpoint para acesso ao Banco de Dados Green. Como isso não seria necessário alterar os parametros de conexão da sua aplicação.
O banco de dados Green será um clone do banco de dados Blue, portanto, se o banco de dados Blue for MultiAZ e tiver replicas de leitura, o Green também terá essa mesma estrutura.

Com o ambiente Blue/Green criado, irei realizar o teste fazendo o “Switch over” do banco de dados Blue para o Green e com isso irei monitorar o tempo que irá demorar para fazer essa “virada”.
Para realizar o “Switch over” é muito muito simples, basta seguir os passos abaixo:

Clicando no opção Switch over irá carregar a janela abaixo com um sumário dos bancos de dados Blue e Green e também o Timeout setting onde você especificará o tempo limite para o switch over ocorrer. Caso o Switch over demore mais que o tempo especificado em Timeout setting, o procedimento não será concluido e nenhuma alteração será aplicada no ambiente.

Após clicar no botão Switch over, o processo será iniciado e a coluna status dos bancos de dados ficará conforme a image abaixo:

Após o Switch over o DB identifier dos bancos será alterado, o banco de dados que estava como Green assumirá como db-mysql1 e o banco de dados que era o Blue foi renomeado com db-mysql1-old1 como pode ser visto abaixo:

O procedimento demorou em torno de 2 minutos, nesse período toda a gravação (write) foi interrompida no banco, mas a leitura (read) continuou normalmente. Essa funcionalidade ficou sensacional! Não acham?

Aplicação em um cenário real

Imaginando um cenário em um ambiente de produção de uma empresa, onde é necessário fazer um upgrade de um banco de dados, mas com o menor tempo de indisponibilidade possível e a menor carga operacional. 
Essa funcionalidade seria uma ótima opção, pois o upgrade, testes e validações seriam realizados no banco de dados Green, finalizando essas etapas, seria necessário somente programar uma janela de manutenção para fazer o Switch over para colocar a nova versão em produção.

Observações

1 – Realizamos esses procedimentos em um banco de teste, mas em um banco de produção com maior volume gravação, o tempo para o Switch over poderá ser maior.

2 – No momento em que escrevo esse post, o Blue/Green deployment é compatível apenas com o Amazon Aurora com MySQL, RDS MariaDB e RDS MySQL…

Agora só nos resta aguardar essa funcionalidade ficar disponível para outras bancos de dados :).

Até breve!

Aprenda como publicar uma Aplicação Web na internet utilizando a nuvem AWS e com uma Arquitetura 100% Serverless, imagine não se preocupar, por exemplo, em atualizações de patches do sistema operacional, pois essa parte será abstraida pela AWS o que reduz a atuação da equipe responsável pela infraestrutura e no quesito segurança, temos uma redução da superfície de ataque.

Com essa arquitetura é possível dar um foco maior na sua aplicação e não se preocupar com a administração da infraestrutura, pois utilizaremos serviços que são altamente disponíveis e administrados pela própria AWS.
Para saber mais detalhes sobre o modelo de responsabilidade compartilhada, você poderá acessar o endereço:

https://aws.amazon.com/pt/compliance/shared-responsibility-model/

Utilizaremos os seguintes serviços:

Cloud Front
S3
IAM

CI/CD

Vamos lá…

Iniciaremos com os serviços que serão a base da infraestrutura na AWS 

Criaremos um Bucket no Amazon Simple Storage Service (Amazon S3) ou comumente chamado de S3 para armazenar os arquivos do Web Site, esse é um serviço de Storage na Nuvem da AWS para o armazenamento de objetos onde teremos escalabilidade, alta disponibilidade dos dados, segurança e performance.

S3 – Criação do Bucket

Na tela do Amazon S3, clique no botão laranja Create bucket:

Iremos criar um bucket S3 com as configurações padrões, ativando somente a opção ACLs enabled no Object Ownership e a criptografia padrão conforme as imagens abaixo:

CloudFront – Criar o distribution ID

Agora vamos para o Cloud Front que terá a função de disponibilizar o nosso site para o mundo, pois ele fará a entrega do conteúdo da aplicação.

O Cloud Front é uma CDN (Content Delivery Network) da AWS para entrega de conteúdo com alta velocidade e baixa latência devido a sua quantidade de (PoPs) Pontos de Presença espalhados pelo mundo.
Mais detalhes sobre esse serviço aqui: https://aws.amazon.com/pt/cloudfront/

Precisaremos criar um Distribution, ao acessar a página do Cloud Front, clique no botão laranja Create distribution:

Ao clicar no botão Create distribution você será direcionado para a página de criação, no primeiro bloco iremos inserir as configurações de Origin, selecionando o bucket que foi criado, a opção Origin access é exibida com algumas opções que iremos configurar conforme as imagens abaixo, visando maior sergurança e performance:

Na etapa de configuração do cache, no Default cache behavior e Cache key and origin requests deixaremos as configurações padrão:

No bloco Function associations, deixaremos o padrão (imagem abaixo), pois não utilizaremos essas configurações nessa demonstração.

Em Settings, podemos configurar a opção de performance, WAF (Web Application Firewall), nome de domínios (CNAME), certificado e versão do HTTP.

Para essa demonstração específica configuraremos o Default root object como index.html, mas dependendo de como a sua aplicação foi construída, pode não ser necessário informar o index.html.

Finalizado a infraestrutura base, seguiremos para o deploy da aplicação…

Deploy da Aplicação

Simularemos uma esteira de CI/CD utilizando o Gitlab para realizar os ajustes na infraestrutura base que criamos anteriormente e o deploy da aplicação (Web Site). O intuito é automatizar esse processo e ganhar agilidade nos deploys.

Obs.: É importante lembrar que as etapas demonstradas a partir desse momento, podem ser realizadas manualmente, desde o upload dos arquivos para o S3 até os ajustes no Cloud Front.

Crie um novo projeto no Gitlab e insira as variáveis (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_DEFAULT_REGION) para que o Gitlab tenha acesso ao nosso ambiente AWS e consigar realizar o deploy da aplicação (Web Site) conforme imagem abaixo:

Configurações de CI/CD do Projeto do Gitlab

Esse projeto possui uma aplicação web simples para essa demonstração, mas também é possível utilizar a mesma infraestrutura com aplicações em Node.js, React, entre outras, utilizando o arquivo serverless.yml que deixarei disponível nesse projeto.
Iremos focar nos arquivos destacados em vermelho na imagem abaixo:

Na pasta www estão os arquivos que serão enviados para o Bucket S3.
No arquivo .gitlab-ci.yml definimos as ações que serão tomadas, a ordem de execução, em qual condição e os recursos necessários.
Segue abaixo os comandos básicos necessários para fazer o download do projeto para a sua máquina e enviar as alterações para o Gitlab:

# 1- Clonar o projeto com o comando abaixo:
git clone git@gitlab.com:devops-breno/serverless_website.git
# 2 - Faça as alterações necessárias no projeto e envie para o repositório executando os comandos abaixo:
git add .
git commit -m "Novo WebSite Estático"
git origin push main

Após executar os comandos, você poderá acompanhar a execução do Job no menu CI/CD / Jobs, se tiver sucesso no deploy, você irá visualizar uma tela conforme imagem abaixo:

Recebendo a mensagem Job succeeded, o deploy foi realizado com sucesso e você poderá acessar o endereço do Cloud Front para teste conforme abaixo:

Acessando o endereço, será possível acessar a página de exemplo com a arquitetura serverless do ambiente:

Pronto! Agora temos uma Aplicação Web 100% Serverless na AWS.
O link abaixo é referente ao site publicado nesse post:

https://d2uhz4c1bwszas.cloudfront.net

Link para download do projeto utilizado:
https://github.com/BrenoACarvalho/ServerlessWebSite

Até breve! 🙂

Categoria: Início

Aplicações Web com Arquitetura Serverless na AWS

S3 – Criação do Bucket

CloudFront – Criar o distribution ID

Deploy da Aplicação