GitHub Actions: integrando e entregando código com segurança

Conhecendo a nuvem - Apresentação

Boas vindas à Alura, eu sou Vinicius Dias e vamos juntos neste curso sobre Entrega Contínua com GitHub Actions.

Audiodescrição: Vinicius é um homem branco, de cabelos escuros e curtos, com bigode e cavanhaque. Ele está vestindo uma camiseta azul escura, e a parede atrás dele é branca com iluminações em tons de roxo e rosa.

Com as ferramentas de qualidade e testes sendo executados de forma automática via GitHub Actions, e tendo dominado e praticado a integração contínua, agora é hora de fazer a entrega desse código previamente integrado. Ou seja, se nosso código pode ser mesclado de forma frequente e segura, graças às análises de qualidade, vamos também, de forma automatizada, colocar esse código integrado em algum ambiente produtivo. Pode ser um ambiente de homologação, testes ou até mesmo de produção.

Antes disso, porém, é necessário um ambiente. Para isso, utilizaremos um provedor de nuvem, a AWS. Para acompanhar bem este curso, é interessante termos conhecimentos sobre integração contínua, pois este curso é uma continuação da formação de integração e entrega contínua.

Além disso, seria ideal que, além de Git e GitHub Actions, tenhamos um conhecimento aprofundado do terminal, e familiaridade na execução de comandos, além de conhecimentos em Linux. Caso contrário, sem problemas, tudo que utilizarmos do sistema operacional será explicado, bem como conceitos de nuvem.

A recomendação é de que, após a finalização deste curso, nos aprofundemos nesses detalhes de nuvem, em pelo menos um dos provedores, pois o ambiente de entrega contínua muitas vezes está relacionado com o ambiente de nuvem.

Abordaremos diversos tópicos, nosso código integrado será compilado e colocado no ambiente produtivo de forma automatizada. Utilizaremos GitHub Actions para colocar nosso sistema em funcionamento. Conversaremos um pouco sobre downtime (tempo de inatividade).

Se, em algum momento desse processo surgir alguma dúvida ou algo não ficar claro, convidamos a abrir um tópico em nosso fórum. Temos uma comunidade ativa de alunos, moderadores e instrutores, e certamente alguém poderá ajudar. Também incentivamos a responder dúvidas abertas lá, pois é uma ótima forma de fixar o conteúdo. Para uma interação mais dinâmica, convidamos a participar do nosso servidor do Discord, onde, além de tirar dúvidas e responder questões de outras pessoas, podemos conversar e levantar questionamentos além do curso. É bastante interessante.

Já falamos bastante sobre o que vamos aprender. Vamos, efetivamente, começar a planejar como será nossa infraestrutura e onde colocaremos nosso código em funcionamento, onde acontecerá nossa entrega contínua.

Conhecendo a nuvem - Desenho da infraestrutura

Neste curso, vamos focar na parte de entrega contínua e até mesmo no deploy contínuo. A diferença entre eles é pequena, e já discutimos isso nos cursos teóricos sobre integração contínua e entrega contínua.

Recapitulando rapidamente e de forma simplificada, a entrega contínua consiste em colocar o resultado da integração contínua realizado nos cursos anteriores desta formação em um ambiente produtivo. Um ambiente produtivo é aquele que se assemelha ou é, de fato, um ambiente acessado diretamente pelo cliente, por uma equipe de produtos ou de qualidade, permitindo a execução do sistema com todas as funcionalidades integradas em um único local, a realização de testes manuais e acesso à funcionalidade em si.

Esse conceito de colocar uma aplicação em um servidor acessível por uma equipe de produtos ou de testes implica no conceito de entrega contínua. A entrega acontece após integração do nosso sistema, permitindo que ele seja acessado em um ambiente produtivo.

O deploy contínuo é uma etapa adicional. Após a entrega contínua, colocamos a aplicação no ar de forma automática e sem intervenção manual, permitindo que o cliente final a visualize. Em alguns cenários, não queremos o deploy contínuo, pois, antes de entregarmos a nova versão ao cliente, por exemplo, pode ser necessário fazer um anúncio, lançar versões em um período específico ou fornecer treinamento ao usuário final.

Podem existir motivos de negócio para não a não realização de um deploy. A entrega contínua é um detalhe técnico, e até esse ponto, precisamos ter automação. Ter ou não um deploy contínuo não é uma limitação técnica, e sim uma escolha de negócios. Nossa equipe de negócios ou de produtos pode querer um ambiente de homologação para unir as funcionalidades e lançar uma nova versão, por exemplo.

Vamos focar na parte técnica e no conceito. A prática que utilizamos para colocar no ambiente de homologação é idêntica à utilizada para colocar no ambiente de produção. O primeiro passo para atingir a entrega contínua é ter um ambiente onde nossa aplicação possa ser executada. Precisamos enviar o resultado da integração contínua, algum artefato gerado, para algum lugar, e então colocá-lo em execução.

Vamos discutir a infraestrutura da nossa aplicação, pois existem diversas formas de organizar e arquitetá-la. Vamos fazer isso da forma mais simples possível. Isso não significa que essa forma simples não se assemelha à realidade, pois muitas aplicações rodam exatamente dessa forma. No entanto, conforme a complexidade da aplicação, dos times envolvidos ou do número de acessos, a infraestrutura tende a se tornar mais complexa e robusta.

Começaremos de um ponto simples para praticar os conceitos de entrega contínua, que será o foco deste curso. Tudo que aplicarmos a essa infraestrutura servirá para as próximas. Trabalharemos com uma estrutura simples: o usuário acessando uma aplicação web, que será exposta pelo Gin, o framework que estamos usando nas aplicações em Go. Não é necessário saber sobre Go ou ser uma pessoa desenvolvedora para continuar com este curso. Qualquer modificação no código será bem explicada e mínima.

Essa aplicação web exposta ao usuário precisa acessar um banco de dados. Estamos utilizando Postgres nos testes, também usado pelo nosso ambiente de produção. Neste caso, não faz sentido utilizar bancos de dados diferentes. Temos o usuário acessando uma aplicação, que acessa um banco de dados. Em alguns cenários, a aplicação web e o servidor de banco de dados podem rodar na mesma máquina, mas em nossa infraestrutura, eles estarão separados.

Teremos uma máquina, um computador ou servidor executando a aplicação web, e outra máquina para o banco de dados. Isso não seria um problema para as práticas de entrega contínua, mas é interessante nos adaptarmos a ter mais de um contexto na infraestrutura.

Em uma infraestrutura mais próxima da realidade, essa separação existe. Se precisarmos aumentar os recursos da aplicação web devido a muitas requisições, mas o banco de dados não precisa de mais recursos, podemos aumentar os recursos da aplicação sem desperdiçar recursos com o banco de dados ocioso, e vice-versa. Separando os dois, conseguimos escalar e modificar os recursos de forma independente.

Esses dois servidores podem estar em qualquer lugar. Podemos contratar um servidor em uma hospedagem para a aplicação web e outro para o banco de dados, ou ambos no mesmo serviço de hospedagem. Podemos criar nosso próprio servidor em casa e disponibilizá-lo para a web, com dois computadores diferentes para cada um deles.

Utilizaremos um ambiente em nuvem para nos adaptarmos a um cenário mais comum, em que a integração e entrega contínua ocorrem em um ambiente mais maduro em relação à infraestrutura.

Embora a nuvem não seja necessariamente um sinal de maturidade, é comum que ambientes mais maduros nessa área estejam em nuvem.

Não se preocupe, vamos explicar o que é um ambiente de nuvem e Cloud Computing. Existem vários cursos na Alura sobre ambientes em nuvem, e utilizaremos a AWS. Em alguns momentos, podemos citar um curso ou outro, mas tudo que você precisará para este curso será feito junto, sem necessidade de conhecimentos prévios.

Se você já conhece a AWS, pode pular o "Para saber mais" e assistir rapidamente ao próximo vídeo, onde explicaremos nossa infraestrutura. A seguir, falaremos sobre os recursos da AWS que utilizaremos.

Conhecendo a nuvem - Planejamento com AWS

Vamos pensar em como colocar o desenho da infraestrutura em que vamos trabalhar em operação. Já mencionamos que utilizaremos a AWS, e nosso usuário precisará acessar algum serviço, ou servidor web, que deverá ser disponibilizado de alguma forma. Cada serviço de nuvem oferece algum produto ou serviço de computação, o que significa uma forma de criar um servidor de maneira "genérica".

É como se alugássemos um computador, uma "máquina virtual", para instalarmos o que quisermos, uma vez que não conseguiríamos criar um servidor físico instantaneamente. Por isso, criamos máquinas virtuais em ambientes de hospedagem, inclusive em nuvens. Criaremos, instalaremos e rodaremos nossa aplicação nessa máquina, faremos a configuração necessária e a colocaremos em funcionamento.

O mesmo poderia ser feito para o banco de dados, criando e configurando manualmente outra máquina virtual, instalando o Postgres, gerenciando e disponibilizando-o. No entanto, assim como um ambiente de nuvem fornece um serviço para a criação de máquinas virtuais, ele também oferece um serviço para gerenciar bancos de dados.

Vamos entender quais são esses serviços no ambiente AWS por meio de um diagrama simples: o usuário acessa o serviço de computação, que na AWS chamamos de EC2 (Elastic Cloud Computing, ou "computação em nuvem elástica") oferecido pela AWS e por outros provedores de nuvem, como Azure, Google Cloud Platform e Oracle, como serviços de gestão de máquinas virtuais de computação.

A diferença entre contratar um servidor em uma hospedagem e utilizar uma máquina virtual em nuvem é a facilidade de aumentar ou diminuir seus recursos, replicá-la e ter várias máquinas virtuais idênticas com as mesmas configurações. Esse tipo de tarefa é muito facilitado e, à medida em que avançamos nos estudos sobre nuvem, essas práticas se tornarão mais evidentes.

Por enquanto, utilizaremos um serviço para criação de uma máquina virtual na AWS, chamado EC2, onde teremos nossa aplicação web rodando e escutando conexões. E, para acesso ao banco de dados, poderíamos criar uma máquina EC2, instalar o Postgres, fazer todas as configurações.

Na AWS, esse serviço é chamado RDS (Relational Database Service, ou "serviço de banco de dados relacional"), que fornece um banco de dados relacional gerenciado automaticamente. Assim, além das facilidades de uma máquina virtual, temos:

• monitoramento específico do banco de dados;
• backup automático;
• réplicas de leitura;
• possibilidade de ter o banco de dados em diversas redes diferentes, aumentando a segurança.

Essas especificidades são discutidas em cursos específicos de EC2 e RDS, e os serviços que os provedores de nuvem oferecem trazem facilidades adicionais em cada área de utilização. Precisamos apenas de uma máquina? Há um serviço. Precisamos de um banco de dados? Há outro. Precisamos de um banco de dados não relacional? Existe um serviço. Precisamos de um serviço de cache? Existe algo disponível. Para cada detalhe, há um serviço que o provedor de nuvem oferece.

Para utilizar um provedor de nuvem, criamos uma conta na AWS, ou fazemos login. Para criar uma conta, é necessário fornecer um cartão de crédito, mas existe o conceito de free tier (nível gratuito) oferecido pela AWS. Se já tivermos uma conta na AWS, provavelmente conhecemos esse free tier e os detalhes de custos.

Em cursos específicos de AWS, explicamos a forma de cobrança e custos da AWS em mais detalhes.

Na AWS, basicamente pagamos pelo que utilizamos. Se tivermos várias máquinas virtuais ligadas o tempo todo, teremos uma cobrança mais alta. Se tivermos apenas uma máquina virtual ligada por poucas horas do dia, seremos cobrados de acordo com essa quantidade. O free tier normalmente funciona no primeiro ano de conta, com alguns limites.

Por exemplo, no EC2, podemos ter um tipo específico de máquina rodando gratuitamente durante todo o mês. No RDS, também podemos ter um tipo de banco de dados sem custo nos primeiros 12 meses. Outros serviços podem ser gratuitos para sempre, enquanto outros têm limites menores, dependendo da precificação.

Atenção! Criar uma conta na AWS apenas para este curso não trará custos, desde que sigamos as instruções adequadamente. Explicaremos sempre a parte que indica o uso gratuito. Para garantir que não haja custos futuros, ao final do curso, devemos excluir tudo o que criamos na AWS.

Vamos explorar o console da AWS: ele mostra todos os serviços utilizados recentemente. Podemos pesquisar o que queremos ou acessar uma lista de serviços. Por exemplo, podemos encontrar o EC2, um serviço de computação, na lista de serviços, ou então pesquisá-lo diretamente. O mesmo vale para o RDS. Se não soubermos o nome do serviço, podemos pesquisar por termos como "Database" para encontrar opções de bancos de dados, incluindo o RDS. Dessa forma, conseguimos acessar cada serviço da AWS.

Recomendação de formação relacionada: Começando na AWS com Lightsail, EC2, S3, VPC, RDS e DynamoDB: Aprenda os fundamentos de Cloud da Amazon Web Services.

Recapitulando, vamos rodar nossa aplicação utilizando uma máquina criada pelo EC2 e um banco de dados criado no RDS. Isso será utilizado para termos nosso ambiente de entrega contínua, sem a qual não conseguimos atingir o conceito de entrega contínua, e é justamente a criação dessa infraestrutura que abordaremos a seguir.

Sobre o curso GitHub Actions: integrando e entregando código com segurança

O curso GitHub Actions: integrando e entregando código com segurança possui 127 minutos de vídeos, em um total de 34 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:

• Conhecendo a nuvem
• Configurando a infra
• Configurando a infra
• Linux e sysadmin
• Melhoria da entrega contínua