1. Automatizando o registro de gitlab-runners ao lançar um EC2 com AutoScaling AWS (Isso não é um tutorial)

Ao lançar uma EC2 via AutoScaling, em um sistema onde os deploys são automáticos e podem ocorrer a qualquer hora do dia, exigirá a utilização de alguma solução, para que, se houver algum deploy em produção enquanto as instancias auto-lançadas estiverem ‘up’, elas também recebam a atualização de código.

No caso, iremos utilizar o Gitlab como exemplo, e veremos como adicionar um runner a uma instância que acabou de ser lançada, e para o Auto Scaling iremos usar a AWS como exemplo, porém guardando as diferenças entre plataformas, essa solução deve funcionar em todas com recursos semelhantes, mas ressaltando, o propósito desse artigo, não é ser um tutorial, mas sim apresentar um solução alternativa e gratuita para esse problema relativamente comum.

Na criação do LauchConfiguration na AWS, após selecionar a AMI a ser usada e selecionar o tipo da instância, iremos para a página de detalhes, nessa etapa, clicando em ‘Detalhes Avançados’ (Advanced Details), podemos ver a opção onde podemos inserir o ‘User data’.

Guarde essa informação, o ‘User data’, é script que será executado no sucesso do lançamento de sua EC2, e é nele onde nós iremos inserir o comando responsável por inserir um gitlab-runner dentro da sua EC2.

Agora indo para o Gitlab, para que um pipeline seja disparado, e executado com sucesso, ele precisa ser localizado por algum runner, o runner, será o responsável por executar os comandos definidos em sua configuração dentro de alguma máquina, virtual ou física, o runner serve como um ‘cara do deploy’, ele irá executar um série de comandos utilizando um usuário especifico, e esses comandos deverão corresponder aos comandos necessários para que sua aplicação venha a ficar ‘up’.

Para que o Gitlab saiba que existem pipelines atrelados a seu projeto, você irá precisar criar um arquivo de configuração, por padrão, esse arquivo deve se chamar ‘.gitlab-ci.yml’, veja o exemplo do arquivo:

stages:
  - deploy

projeto-homologacao:
  stage: deploy
  tags:
    - homolog
    - homologacao
    - projeto-homologacao
  environment:
    name: homologacao
  script:
    - cd /usr/share/nginx/html/projeto
    - git pull origin homologacao
    - composer update
  only:
    - homologacao
    - merge-request

projeto-producao:
  stage: deploy
  tags:
    - prod
    - producao
    - projeto-producao
  environment:
    name: producao
  script:
    - cd /usr/share/nginx/html/projeto
    - git pull origin master
    - composer update
  only:
    - master
    - merge-request

Esse arquivo, explica para o Gitlab, que, nosso projeto possui dois jobs, um para homologação, e outro para produção.

As tags, servem para identificar o job, e será usada pelo runner para saber que ele precisa entrar em execução.

O ambiente (environment), é usado para você localizar os seus pipelines dentro do Gitlab.

Os scripts, são os comandos que orunner irá executar em sua máquina, os scripta por padrão, serão executados pelo usuário ‘gitlab-runner’, que é criado em sua máquina ao instalar o runner usando a documentação oficial como referência (https://docs.gitlab.com/runner/install/), esse usuário pode ser alterado, porém caso não queira, de as permissões necessárias para ele na pasta de seu projeto dentro do servidor.

E os valores de ‘only’, são responsáveis por indicar quando o seu pipeline precisa ser disparado, existem uma série de condições, mas no exemplo usamos condições simples, merge-request, indicando para ser disparado apenas ao aceitar uma merge request em nosso projeto (equivalente ao pull request do Github), e apenas nas branchs homologacao e master, que simbolizam os nossos estágios de deploy em código.

Agora que entendemos como o arquivo de configuração de pipelines do Gitlab funciona de forma básica, iremos aprender a registrar um runner ao nosso projeto.

Para o runner se localizar, e saber onde ele deve entrar, iremos utilizar as tags de nossos estágios:

- homolog
- homologacao
- projeto-homologacao

E

- prod
- producao
- projeto-producao

Para iniciar o processo de automação de deploys, vá para tela de seu projeto clique ‘Configurações > CI / CD > Runners’, veja a opção ‘Set up a specific Runner manually’, haverá a url do Gitlab, no caso do CE ou EE, a sua url publica, ou localhost caso local, e, no caso do Gitlab Web, será exibido ‘https://gitlab.com’, e logo abaixo da url, haverá uma chave, essa chave, além das tags, será utilizada pelo runner para saber o que fazer.

Sabendo disso também, iremos para uma instancia ‘master’, do nosso AutoScaling, o termo ‘master’ aqui, serve para indicar a instância que servirá como base para as auto-lançáveis, e iremos fazer a configuração do seu projeto dentro dela, não irei tratar disso nesse artigo, cada serviço e produto vai ter uma configuração específica, e estamos tratando sobre como fazer deploys apenas, e nessa EC2 iremos fazer a instalação do gitlab-runner (https://docs.gitlab.com/runner/install/), você pode configurar diversas coisas extras na instalação, mas aqui usaremos o mais default possível.

Com o runner instalado, você irá precisar registrar ele, para isso, você pode rodar o comando ‘gitlab-runner register’, e ele irá te perguntar passo-a-passo os dados para fazer o registro, isso pode ser feito na EC2 master, pois você pode entrar, logar e preencher, mas, o mesmo não vai valer para um instância auto-lançada, então usaremos um comando não interativo, e aqui entra a importância da chave de runners do projeto, url e tags da pipelines:

sudo gitlab-runner register \
  --non-interactive \
  --url "https://gitlab.seuservidor.com.br/" \
  --registration-token "cole o token de runners do seu projeto" \
  --executor "shell" \
  --description "Seu projeto ${instance_id}" \
  --tag-list "prod,producao,projeto-producao" \
  --locked="false" \
  --access-level="not_protected"

Esse comando, irá registrar a máquina em questão para o seu projeto, e após isso, ele será disparado quando a branch ‘master’ aceitar um merge request, e irá executar os comandos, em ordem, que estão dentro da tag ‘scripts’ do stage correspondentes as tags informadas no comando a cima.

Voltando agora para a AWS, lembra do ‘User data’ ao criar um LauchConfiguration ? Agora iremos colocar este comando dentro dele, isso fará com que, sempre que uma EC2 for lançada via AutoScaling usando esse LauchConfiguration, ela registre um runner, que por sua vez, fará com que a instância em questão possa receber a atualização do código provida pela aceitação do merge.

Tratamos de forma superficial, uma solução para deploys em máquina AS, porém, existirão uma série, mas uma série mesmo, de detalhes a serem considerados, e levantarei alguns questionamentos, e estou me planejando para solucioná-los de forma explicativa também aqui no Medium quando tiver mais um tempinho livre.

Meu plano de vida não é ser escritor, apenas replicar e registrar um pouco do que eu estudo/pratico, e quem sabe ajudar alguém, então se estiver ruim, ou algo não faz muito sentido, me corrija, caso contrário, não me incomode.

Obrigado !