Boas-vindas ao curso Integração Contínua: Rollback e teste de carga. Eu sou o Leonardo Sartorello e serei o seu instrutor ao longo deste treinamento.
Autodescrição: Sou branco, tenho cabelos e barba castanhos escuros e olhos azuis. Estou usando uma camiseta azul-escura e atrás de mim há uma parede com fundo azul-claro.
Neste curso, vamos acompanhar o Bruno, que faz parte da nossa empresa e está avançando cada vez mais na sua carreira, agora especificamente na área de dev.
Vamos garantir a aplicação em produção utilizando uma técnica chamada Rollback. Aprenderemos a criar uma supraestrutura automaticamente utilizando código. Por fim, vamos realizar um teste de carga utilizando a estrutura que criamos.
Usaremos principalmente o GitHub, mais especificamente o GitHub Actions. Além do AWS, que vai prover toda infraestrutura que precisaremos ao longo do treinamento.
Lembrando que infraestrutura na AWS pode gerar custos, mas sempre optaremos pela opção com menor custo possível.
Esse curso é para você que já completou o curso Integração Contínua: automatize o deploy no Amazon ECS e quer aprender recursos novos e avançados na área de integração e deploy contínuo.
Aprenderemos como funciona o Rollback, como utilizá-lo para garantir que nossa aplicação está funcionando no cloud, atendendo nossos clientes.
Também vamos descobrir como criar uma infraestrutura utilizando a infraestrutura como código, automatizando esse processo com uma rotina de entrega contínua.
Por meio da infraestrutura realizamos o teste de carga que além de mostrar se a aplicação funciona ou não, também mostra seu desempenho e como atenderá os clientes.
Vamos lá?
Esse curso é uma continuidade do Integração Contínua: automatize o deploy no Amazon ECS, vamos utilizar o projeto que foi desenvolvido nessa formação.
Clicando em "Projeto base", localizado no menu lateral esquerdo, você poderá baixar esse projeto em zip ou acessar o link do repositório no GitHub.
Vamos começar falando com o nosso Dev, Bruno. Agora que atualizamos o processo de criação do container e seus sistemas de versões, não devemos ter problemas com aplicação, afinal, ela está sendo testada antes de chegar na criação do container.
Porém, o que acontece se mexermos em algo que mude a criação do container? Nesse caso basta testá-lo também.
Mas e se a mudança for em alguma parte da aplicação que não aparece nos testes e, ao mesmo tempo, quebre a aplicação quando colocada no ECS?
Embora pareça improvável, isso pode acontecer, inclusive com essa aplicação. Com isso em mente, decidimos trazer essa dica de CI/CD.
Para isso, seria interessante ter uma forma de testar se a aplicação está rodando corretamente e respondendo às requisições. Caso não, podemos voltar para uma versão mais antiga em que tudo funciona corretamente.
A boa notícia é que essa funcionalidade existe e se chama Rollback. Ela é uma parte muito importante dos deploy automatizados.
Com o sistema de versionamento dos containers funcionando, basta voltarmos para o container que estávamos usando antes da atualização. Para isso, podemos modificar novamente a tarefa para o container antigo, porém, precisaremos encontrar uma forma de salvar essa versão antiga para substituir no campo de container.
Há uma forma mais simples de realizar isso, na qual não precisamos salvar nenhum valor de container, nem modificar o arquivo da tarefa. Podemos fazer uma cópia da tarefa antiga e só subi-lá novamente em caso de problemas.
Para fazer isso, acessamos o repositório. Clicamos na pasta ".github/workflows" e em seguida em"ECS.yml".
Podemos editar esse arquivo de duas formas. Clicando no botão identificado pelo ícone de lápis, localizado na lateral direita da tela ou clicando no botão ao lado, identificado por uma seta para baixo, e selecionando a opção "Edit this file".
Queremos fazer a cópia da nossa tarefa antiga, ou seja, sem nenhuma alteração. Então, vamos checar os steps
e ver onde podemos fazer isso.
Nosso primeiro step
é name: configurando credenciais da AWS
, isso significa que não temos o arquivo de tarefas nesse passo.
O próximo é "name: Obtendo arquivo da tarefa", é aqui é encontramos o arquivo de tarefa.
Para fazer uma cópia, abaixo dele, damos enter para abrir espaço no código. Feito isso, vamos criar o novo passo.
Definimos name: copia do task-definition
. Em seguida, na linha de baixo, definimos o que deve ser executado. Para fazermos uma cópia, temos que fazer como no Linux, ou seja, com o comando cp
, o nome do arquivo original seguido pelo nome do arquivo que será salvo.
Para saber o nome do arquivo original, checamos o run
do comando anterior. Descobrimos que é task-definition.json
, copiamos e colamos no código.
O nome que vamos definir para a cópia será task-definition.json.old
, mas se você preferir, pode usar task-definition.bak
, que faz referência ao backup.
// código omitido
- name: copia do task-definition
run: cp task-definition.json task-definition.json.old
Realizamos a cópia. Agora, descendo a página até o final, na lateral esquerda da página, clicamos no botão verde "Start commit" e depois em "Commit changes" para salvar as modificações.
Na próxima aula faremos a requisição. Até lá!
Agora que já salvamos a tarefa antiga, podemos começar a trabalhar com o Rollback. Ele pode ser dividido em duas partes:
- Verificação
- Rollback da versão
Para a verificação, precisamos realizar uma requisição. Para isso, podemos usar um comando como o Wget ou encontrar uma rotina que faça isso.
Nesse caso usaremos um comando, afinal, quando não estamos trabalhando com usuários, senhas ou plataformas proprietárias como aws os comandos são mais garantidos, pois não tendem ter alterações.
Sendo assim, vamos começar a montar nossa requisição. Abrimos o arquivo ECS.yml
e para editá-lo clicamos no botão identificado pelo ícone de lápis, localizado na lateral direita da tela ou no botão ao lado, identificado por uma seta para baixo, e selecionando a opção "Edit this file".
A requisição vai ser a última etapa do nosso processo, pois se analisarmos o código notamos que a última parte do processo atual é o Deploy Amazon ECS task definition
, que está atualizando nosso container. A partir disso, poderemos fazer a requisição para testá-lo.
No fim do código, começamos abrindo um novo passo, já que a requisição não pode ser feita com o passo anterior.
Para isso definimos -name:
seguido do nome Requisição
. Damos enter e definimos o run:
, que irá rodar o comando wget
para fazer a requisição.
Agora, precisamos definir uma URL que essa requisição será repassada. Para isso, acessamos o console da aws, digitamos na barra de pesquisa "EC2" e clicamos na primeira opção que aparece na tela.
Embora estamos usando o ECS para nosso container, nossa aplicação tem um balanceador de carga que fica no EC2.
Somos direcionados para uma nova página. No menu lateral esquerdo, descemos até encontrar a categoria "Balanceamento de carga", nela clicamos no botão "Load balancers". Outra forma de acessá-lo é no menu central da página, na categoria "Recursos".
Feito isso, conseguimos visualizar todos os Load balancers que temos na área que estamos utilizando, nesse caso, a área "Leste dos EUA (Ohio) us-east-2".
Visualizamos o nome do nosso Load balancer seguido do DNS name, ou seja, o que estamos procurando, o endereço da aplicação.
Copiamos o endereço LB-API-Go-908865819.us-east-2.elb.amazonaws.com
, voltamos para o repositório e colamos após o comando wget
.
Essa aplicação tem alguns detalhes que precisamos ter cuidado. Ela não pode ser acessada na porta padrão 80, ela precisa ser acessada a partir da porta 8000. Sendo assim, especificamos a porta adicionando no código :8000/
.
Se acessarmos o endereço da forma como está vamos ser direcionados para o balanceador de carga 8000/, que é nossa aplicação. Porém, ela não responde no /
. Nesse caso, podemos usar /bruno
, assim nossa API responderá para o nosso dev.
// código omitido
- name: Requisição
run: wget LB-API-Go-908865819.us-east-2.elb.amazonaws.com:8000/bruno
Feito isso, nossa requisição está pronta.
Mas, o que acontece se a requisição der erro? O padrão do GitHub Actions é cancelar toda rotina. Isso significa que tudo o que tiver abaixo da requisição não será executado, como o Rollback.
Para evitar que isso aconteça e permitir sua execução, logo após o name
, abrimos uma nova linha e colocamos a tag especial continue-on-error:
e selecionamos a opção true
.
// código omitido
continue-on-error: true
Embora no passo anterior definimos wait-for-service-stability
, ou seja, esperar pela estabilidade do nosso serviço, pode acontecer do balanceador de carga não ter cadastrado nosso container para começar a enviar as requisições a cada 10 segundos, conforme definimos.
Para ter certeza que ele já está cadastrado, podemos esperar para fazer a requisição. Para isso podemos utilizar uma rotina ou um comando. Novamente optamos pelo comando, pois sabemos que ele não muda. Sendo assim, antes de wget
colocamos o sleep 30s
.
Agora precisamos definir algo para que o wget
não faça parte do comando sleep
, o que ocasionaria um erro. Então, entre eles, adicionamos ;
, dessa forma ele vai executar o primeiro comando e depois o segundo.
// código omitido
- name: Requisição
continue-on-error: true
run: sleep 30s ; wget LB-API-Go-908865819.us-east-2.elb.amazonaws.com:8000/bruno
Assim, criamos um passo que faz a requisição e mesmo que de erro ele ignora e continua executando nossa rotina e após esperar 30 segundos, fará a requisição.
O que falta agora é retornar a tarefa anterior. Vamos lá?
O curso Integração Contínua: Rollback e teste de carga possui 123 minutos de vídeos, em um total de 47 atividades. Gostou? Conheça nossos outros cursos de Builds em DevOps, ou leia nossos artigos de DevOps.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
Impulsione a sua carreira com os melhores cursos e faça parte da maior comunidade tech.
1 ano de Alura
Assine o PLUS e garanta:
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
No Discord, você tem acesso a eventos exclusivos, grupos de estudos e mentorias com especialistas de diferentes áreas.
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
Acelere o seu aprendizado com a IA da Alura e prepare-se para o mercado internacional.
1 ano de Alura
Todos os benefícios do PLUS e mais vantagens exclusivas:
Luri é nossa inteligência artificial que tira dúvidas, dá exemplos práticos, corrige exercícios e ajuda a mergulhar ainda mais durante as aulas. Você pode conversar com a Luri até 100 mensagens por semana.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Transforme a sua jornada com benefícios exclusivos e evolua ainda mais na sua carreira.
1 ano de Alura
Todos os benefícios do PRO e mais vantagens exclusivas:
Mensagens ilimitadas para estudar com a Luri, a IA da Alura, disponível 24hs para tirar suas dúvidas, dar exemplos práticos, corrigir exercícios e impulsionar seus estudos.
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.