Integração Contínua: automatize o deploy no Amazon ECS

Planejamento - Apresentação

Boas-vindas ao curso de Integração Contínua: automatize o deploy no Amazon ECS!

Me chamo Leonardo Sartorello e serei o seu instrutor ao longo deste treinamento.

Leonardo Sartorello é uma pessoa de pele clara, com olhos azuis e cabelos castanhos escuros e curto, e possui uma barba. Veste camiseta branca e lisa, e está sentado em uma cadeira preta. Ao fundo, há uma parede branca e lisa com uma iluminação azul gradiente.

Neste curso, vamos acompanhar o Bruno, que está faz um tempo na nossa empresa e avançando cada vez mais na sua carreira.

O que vamos aprender?

• Criar uma infra para contêineres
• Criar uma rotina de Entrega contínua
• Versionamento automático

Vamos aprender a criar uma infraestrutura para contêineres e uma rotina de entrega contínua para atualizar esses contêineres na infraestrutura. Isso aproveitando um versionamento automático dos contêineres.

Qual ferramenta vamos usar?

• GitHub
• AWS (Amazon Web Services)

Usaremos principalmente o GitHub, mais especificamente o GitHub Actions, como a ferramenta de CI/CD. Sendo CI a sigla para Continuous Integration ("Integração Contínua") e CD para Continuous Delivery ("Entrega Contínua").

E, também, vamos usar a AWS como provedora de cloud para nos dispor de toda infraestrutura que precisaremos ao longo do treinamento.

Para quem é esse curso?

São para pessoas que querem aprender mais sobre entrega contínua e já concluíram os cursos pré-requisitos para este treinamento. Esses cursos constam na página inicial deste treinamento, à direita.

Fazendo esse curso...

Vamos nos aprofundar mais em entrega contínua, veremos recursos interessantes sobre contêineres e, também, como funciona a infraestrutura de contêineres na AWS dentro de um sistema de cloud.

Vamos lá?

Planejamento - Verificando a Infra

Tarefas que já realizamos junto com o Bruno:

• Rotinas de integração de código
• entregas contínuas para aplicação

Trabalhamos junto com o Bruno e com o time de Devops em uma empresa grande, e já ajudamos a criar e configurar rotinas de integração de código e, também, em entregas contínuas para aplicação.

Porém, vamos ter que trocar as máquinas da nossa infraestrutura. Isto é, vamos parar de usar máquinas virtuais e mudaremos para contêineres Docker.

Para isso, começaremos analisando como a aplicação está sendo executada atualmente, e o que podemos aproveitar da infraestrutura atual para essa migração.

Essa infraestrutura foi criada em um curso anterior, que consta nos pré-requisitos para este treinamento.

Na página inicial do console da AWS, em "Visitado recentemente", clicaremos em "RDS" (Amazon Relational Database Service, em português "Serviço de banco de dados relacional da Amazon").

Será exibido o painel do RDS, em que na parte central da página temos os "Recursos" com uma frase que contém um link clicável escrito: "Instâncias de banco de dados (1/40)". Clicaremos nessa frase.

Na página seguinte, teremos somente um bando de dados rodando, sendo o que fizemos no curso anterior. Na tabela, temos a coluna "Identificador de banco de dados", em que selecionaremos "database-1".

Será exibida uma tela com o título "database-1", abaixo temos a seção "Resumo" com algumas informações do banco de dados. Entre esses campos temos o "Status" que consta como disponível, significa que está funcionando.

O que mais criamos no último curso? Temos as máquinas virtuais!

No campo de busca ao lado do ícone de lupa na parte superior da AWS digitaremos "EC2". Será exibida uma aba em que, à direita, selecionaremos a opção "ECS: Virtual Servers in the Cloud".

Assim, entraremos no painel do EC2 que contém uma seção "Recursos". Nela, temos uma mensagem "Você está usando os seguintes recursos do Amazon EC2 na Região Leste dos EUA (Ohio):" e abaixo temos algumas caixas com algumas opções, clicaremos na primeira, sendo "Instâncias (em execução)".

Na página exibida, temos o título "Instâncias" e abaixo uma tabela com algumas colunas, entre elas: Name, ID de instância, Estado da instância, Tipo da instância, etc.

Perceba que foi feito uma modificação, pois temos duas instâncias sendo executadas.

Não exibimos todas as colunas da tabela:

Essas instâncias estão rodando a mesma aplicação, porém o time de infraestrutura achou melhor duas do que somente uma instância. Assim, subiram outra instância para distribuir a carga e deixar a aplicação mais ágil para os nossos clientes.

Um detalhe importante é que a aplicação precisa se comunicar com o banco de dados. Vamos analisar como ela está fazendo isso.

À esquerda, em "Rede e segurança", clicaremos na opção "Security groups" ("Grupos de segurança").

No painel de "Grupos de segurança", temos uma tabela com o grupo que colocamos o nosso banco de dados sg-dfb047a8, sendo o grupo padrão (default).

Antes da coluna "Name" vamos selecionar o quadrado para expandir algumas abas abaixo. Arrastando a aba inferior para cima, temos as seguintes abas: “Detalhes”, “Regras de entrada”, “Regras de saída” e “Tags”.

Selecionamos a aba "Regras de entrada". Nela, temos uma regra de entrada, como podemos visualizar em "Regras de entrada (1/1)" que nos permite a comunicação com o PostgreSQL (banco de dados), na porta 5432. Podemos visualizar na coluna "Tipo" e "Intervalo de portas" da tabela.

Na coluna "Origem", consta que ele só pode vir do grupo de segurança em que estão as máquinas virtuais: launch-wizard-2. Vamos precisar nos atentar para fazer os contêineres Docker também se comunicarem através desse grupo de segurança com o banco de dados.

De forma geral, a nossa infraestrutura não mudou tanto. O time de infraestrutura inseriu uma máquina a mais para atender a demanda, mas ficou por isso.

Logo, ficamos com uma infraestrutura bem parecida e podemos começar as nossas alterações. Um detalhe importante é que por enquanto, ao iniciar a transição, não desligue as máquinas que estão funcionando.

À esquerda, em "Instâncias", selecionaremos "Instâncias". Essas máquinas estão atendendo os nossos clientes e não queremos deixá-los com um serviço indisponível.

Portanto, vamos deixar essas máquinas e no final do curso, se estivermos com tudo funcionando, podemos desligá-las.

Agora, montaremos um plano de ação do que precisamos fazer para subir o que desejamos.

Vamos lá?

Planejamento - Plano de ação

Agora que já verificamos se a infraestrutura está semelhante ao que deixamos anteriormente, podemos começar a planejar as alterações que faremos para usar o ECS (Elastic Compute Cloud).

Essas alterações nos trarão diversos benefícios, entre eles:

• Tamanho
• Velocidade de criação
• Segurança

Um dos benefícios é o tamanho reduzido da aplicação, porque temos somente o necessário dentro do contêiner. Outro é a velocidade de criação, justamente por ser menor que uma máquina virtual e, também, uma maior segurança, por termos menos aplicações rodando em segundo plano.

Com o Bruno, adiantamos parte do trabalho necessário. Isso porque a criação do contêiner está sendo feita de forma automática. Desse modo, podemos nos concentrar apenas em passar a infraestrutura de máquinas virtuais para contêineres.

Como a empresa já usa a AWS como provedora de recursos na nuvem, vamos migrar do Amazon EC2 para a Amazon ECS. Sabendo que no EC2 é onde se localizam as máquinas virtuais e no ECS ficará a nossa infraestrutura de contêineres.

A Amazon ECS também contém algumas vantagens, como, por exemplo, facilidade em escalar as aplicações entre várias máquinas. Isso nos permite ter uma infraestrutura elástica - que diminui e cresce conforme a necessidade, economizando custos.

Temos, também, a vantagem de configurar a infraestrutura de alta disponibilidade. Assim, ela não fica fora do ar mesmo ocorrendo imprevistos. Dessa forma, vamos preparar um plano para começarmos a usar essa infraestrutura.

Iniciaremos pelo ECS, que precisará se comunicar com o banco de dados já criado dentro do Amazon RDS (Amazon Relational Database Service, em português "Serviço de banco de dados relacional da Amazon").

Além disso, incluiremos um load balancer na frente do ECS. Atualmente, estamos rodando duas máquinas virtuais, porém, o que estamos fazendo é: uma parte dos clientes acessam uma máquina e a outra parte acessam a outra máquina.

Com o load balancer não precisamos fazer essa divisão, podemos fazer com que todos os clientes acessem somente uma máquina, sendo um balanceador de carga.

O balanceador de carga distribui as requisições entre os contêineres da aplicação. Desse modo, não temos nenhum problema em sobrecarregar um contêiner enquanto outro está parado.

Além disso, usaremos o ECS junto o Fargate. Isto é, ao invés de manusearmos as máquinas virtuais que formam o cluster em que será executada a aplicação, a AWS ficará responsável por isso com o Fargate.

Tudo o que precisaremos fazer é cuidar dos nossos contêineres. Isso porque a AWS cuidará das máquinas virtuais e vamos focar na aplicação e nos contêineres.

Por fim, o que vai acontecer com as máquinas virtuais? Podemos pegar as máquinas do EC2 e finalizar todas elas, restando apenas os contêineres.

Vamos lá?

Sobre o curso Integração Contínua: automatize o deploy no Amazon ECS

O curso Integração Contínua: automatize o deploy no Amazon ECS possui 128 minutos de vídeos, em um total de 45 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:

• Planejamento
• Infraestrutura do ECS
• Tarefa e AWS
• Alterando o ECS
• Alterando o Container