CI e CD com Gitlab 🚀

 

CI e CD, ou Continuos integration e Continuos delivery (integração continua e entrega continua) são cada vez mais comuns no dia a dia do dev, meu primeiro contato com essa pratica foi usando serviços como Heroku e Netlify e desde então sempre quis "implantar meu próprio CI/CD", a alguns meses eu tive a oportunidade e foi uma tarefa bem legal e um pouco árdua, então resolvi criar esse post para ajudar outras pessoas que podem passar pelo mesmo que eu ou mesmo só querem saber como. Então vamos lá criar nosso sistema de CI e CD com Gitlab!

O que vamos precisar:

• Conta no Gitlab.
• Um repositório com algum projeto.
• Um servidor/maquina para rodar o runner/docker e/ou "receber" o projeto.

Conta no Gitlab 🆕

Primeiro passo é o mais obvio, vamos precisar de uma conta no Gitlab, caso você ainda não tenha, pode cria-la aqui.

Criando repositório no Gitlab 📁

Crie um projeto novo no Gitlab e suba algum projeto para que possamos fazer os teste, no meu caso, vou subir um projeto de exemplo, e caso você queira, pode usa-lo como teste também. Clique aqui para o projeto de teste.

Escolhendo e Configurando Runners 🔧

O Gitlab funciona de uma forma diferente do Github para parte de CI/CD, ele oferece o que é chamado de "Gitlab Runner", que é um serviço onde rodamos nossas tarefas(build, testes... Pense nele como uma maquina virtual onde faremos nossas tasks) e podemos enviar de volta pro Gitlab ou pra qualquer outro lugar, via ssh por exemplo.

Quanto ao runner, temos duas opções, a primeira é instalar o runner em uma maquina pessoal nossa e a segunda é utilizar um "shared runner", que como o nome diz, são runners compartilhados, eles são mantidos pelo Gitlab e rodam direto no Google Cloud Plataform, eles não tem limites para projetos gratuitos e open-source, mas tem um limite mensal de tempo para projetos privados, você pode ler mais sobre eles aqui, incluindo configurações e disponibilidade.

Escolhendo o Runner ☝

Como eu disse antes, podemos hospedar nosso próprio runner ou utilizar um compartilhado (que na maioria dos casos resolve muito bem), então vamos fazer os dois, primeiro vamos ao runner compartilhado (que já vem ativado por padrão), para isso, vamos até o repositório, e do lado esquerdo, vamos clicar em "Settings" e "CI / CD":

Sim, minha foto é do itachi de juliete

Na pagina que irá aparecer, vamos clicar em "Expand" na opção "Runners":

Aqui podemos ver as opções de runners que temos, como dito anteriormente, os shared runners já vem ativo por padrão, então não precisamos fazer mais nada aqui;

Hospedando e Configurando um Runner 🖥

(Caso você vá usar o shared runner, pule essa parte e vá direto para parte de configurar a chave ssh).

Vamos imaginar que você precise de um runner com configurações muito especificas no seu projeto ou queira algo mais privado mesmo, para isso a saída é hospedarmos nosso próprio runner em uma maquina nossa, e é o que vamos fazer agora, primeiro, vamos precisar de uma maquina para instalar o serviço do Gitlab runner e o docker para usarmos como executor do runner (é possível rodar sem o docker, mas não é o recomendado por vários motivos, você pode conferir isso aqui).

Caso não tenha o docker instalado, eu já fiz um post sobre a instalação dele, basta clicar aqui.

Vamos começar instalando o runner na maquina, o Gitlab Runner roda em linux, macos, freebsd e windows, porém aqui eu abordarei a instalação e configuração apenas no linux, você pode buscar ajuda para outros sistemas operacionais na documentação oficial.

Vamos começar adicionando o repositório oficial do Gitlab ao nosso sistema:

# Para Debian/Ubuntu/Mint  
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash 
# Para RHEL/CentOS/Fedora 
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

E agora, vamos instalar o runner: 

# For Debian/Ubuntu/Mint
sudo apt-get install gitlab-runner
# For RHEL/CentOS/Fedora
sudo yum install gitlab-runner

Após instalarmos, vamos registrar nosso runner, para isso vamos executar o comando:

sudo gitlab-runner register

Após executar o comando, veremos a seguinte mensagem:

Em coordinator URL vamos utilizar a url do Gitlab, então basta digitar: https://gitlab.com e dar enter.
Agora veremos a mensagem: "Please enter the gitlab-ci token for this runner:", O token referido na mensagem podemos encontrar nas configurações do nosso repositório > CI/CD > Runners (mostrado anteriormente aqui no post), e vamos em "Especific Runners", onde vamos copiar o token:

Basta colar o token no shell e dar enter.

Agora veremos a mensagem: "Please enter the gitlab-ci description for this runner:", aqui precisamos por uma descrição, que aparecerá no Gitlab para podermos identificar o runner (você pode ter mais de um), escolha uma descrição e pressione enter. 

Veremos a mensagem "Please enter the gitlab-ci tags for this runner (comma separated):", aqui podemos adicionar algumas tags para o nosso runner, não é requerido, você pode pular caso deseje.

Por ultimo, temos que escolher o nosso executor, que será onde toda nossa operação ira ocorrer, aqui eu recomendo utilizar o docker, para podermos isolar nosso build (principalmente se o runner esta rodando na mesma maquina que seus projeto(s)), então basta digitar docker e pressionar enter. 

Iremos para o ultimo dialogo, que é qual imagem iremos usar para o nosso container docker, no meu caso, escolhi node, pois estou fazendo build de uma aplicação Nodejs com express, e finalizamos a configuração do nosso runner:

Configurando sua chave SSH 🔒

Vamos precisar fazer acesso SSH do docker para nossa maquina, para podermos atualizar o repositório e reiniciar nosso gerenciador de processos, para isso precisaremos configurar nossa chave ssh, usuario e url do nosso servidor para tal acesso(aqui, estou supondo que você acesse seu servidor usando uma chave ssh, como é o caso da AWS por padrão, caso utilize usuário e senha, basta criar essas variáveis e modificar no arquivo). O Gitlab oferece uma forma segura de armazenarmos essas informações mais sensíveis (você não vai querer esses dados no seu arquivo .gitlab-ci.yml), para isso basta irmos até; Settings > CI/CD > Variables:

Vamos criar três variáveis;

    PRIVATE_KEY: a chave privada para o nosso acesso ssh, basta copiar o conteúdo do arquivo .pem e colar o conteúdo, preste atenção para não conter espaço ou quebra de linhas a mais, pois pode causar erro na hora de conectar.

    SERVER_USER: nome do usuário para acessar via ssh.

    SERVER_URL: url para o acesso ssh.

Basicamente esse é o formato das três variáveis:

Configurando Gitlab-ci ⚙️

Com o nosso runner configurado e rodando ou utilizando um shared runner, vamos configurar o nosso arquivo que fará a chamada e executará os comandos após cada push/merge na branch que vamos escolher. 

Para isso, vamos criar um arquivo chamado .gitlab-ci.yml na raiz do nosso projeto:

Agora vamos ao conteúdo do arquivo, vou mostrar toda estrutura e em seguida explico:

Link para o arquivo

Na primeira parte do arquivo, temos as variáveis, eu utilizei duas pra dar uma organizada, então como variáveis eu tenho o nome da pasta do projeto no servidor, para que eu possa navegar até ele, tenho os scripts que vou executar apos entrar na pasta; instalar novos pacotes e reiniciar o pm2(gerenciador de processos que utilizo pra manter a aplicação rodando).

Na segunda parte, em "stages", temos os passos que serão executados após um push/merge, nesse caso, eu criei apenas dois, um para teste e outro para fazer o deploy da aplicação;

O estagio de teste, eu basicamente instalo os pacotes da aplicação e rodo o script de test, que já existe no meu package.json, caso esse estagio seja bem sucedido, iremos para o próximo, caso contrario, ele interrompe o processo por aqui.

No nosso ultimo estagio, o de deploy, temos alguns scripts mais elaborados, isso por que após passarmos nos testes, precisamos atualizar nossa aplicação no servidor, instalar novos pacotes (caso exista) e reiniciar o nosso gerenciador de processos, porém, estamos dentro de um container docker, não temos acesso a nossa maquina onde roda nosso projeto, uma das melhores formas de nos conectarmos a nossa maquina é simplesmente usando SSH, vamos fazer tudo isso no nosso script de "before_script". Então, no nosso primeiro script no deploy, verificamos se no container já temos o ssh instalado, caso contrario, vamos instalar e em seguida, criamos uma pasta com o nome '.ssh' na pasta home (caso não exista), no terceiro passo nos carregamos as variáveis de ambiente necessárias para o acesso ssh, por ultimo nos adicionamos a opção "StrictHostKeyChecking" como "no" para que possamos ignorar um alerta bem comum de acesso ssh entre docker e uma maquina.

Após toda configuração do nosso ssh no "before_script", criamos nosso script que vai fazer a conexão ssh, acessar a pasta do projeto, fazer um pull para atualizar os arquivos, instalamos novos pacotes e reiniciamos o pm2 (tudo isso esta na nossa variável de scripts).

Por fim, na tag/chave "only", temos o valor "master", isso indica que esse processo só será executado quando receber um push/merge na branch master, obviamente, você pode configurar outra branch aqui, mas lembre-se de torna essa branch uma branch protegida, pois você precisa acessar suas variáveis sensíveis com a sua chave ssh. Para isso, basta ir nas configurações do repositório (Settings > Repository) e em "Protected Branchs" adicionar a branch desejada:

Vamos testar 🧪

Para concluir, basta testarmos, então, suba o repositório ou faça um push com o novo arquivo na branch que escolheu para o deploy (no meu caso, a master). Logo no index do nosso repositório, veremos algo como isso:

Clicando no ícone de "check", iremos ser direcionados para a nossa pagina com as Pipilines (Menu Lateral > CI/CD > Pipilines) e nela poderemos ver algumas informações sobre aquela tarefa executada, como o tempo, quais estágios foram executados etc:

Você pode clicar em um dos estágios para ver o log de tudo que foi executado também;

Conclusão 🎇

Essa é mais ou menos a configuração que costumo fazer quando preciso utilizar o CI/CD do Gitlab, espero que vocês tenham gostado e tenham entendido todo processo, foi um post bem extenso e levei um tempo para escrever tudo da melhor forma possível com exemplos e tentando explicar de forma mais detalhada possível, muito obrigado pela leitura, não se esqueça de conferir os vídeos no canal no youtube também: https://www.youtube.com/tuliocalil