Runners-do-gitlab-ci.md

+Os scripts do **gitlab-ci** escritos pelo desenvolvedor precisam de uma máquina para interpretá-los e executá-los, e pra isso existem os **Runners**.
+
+Os **Runners** são aplicações que interpretam e executam as pipelines do **gitlab-ci**.<br>
+Eles são instalados em uma máquina externa a do **GitLab**, e configurados na página do projeto para se encarregarem de executar os scripts de CI/CD do mesmo.
+
+Sempre que a execução do CI/CD do projeto em questão for engatilhada (seja por conta de uma mudança nova, ou de uma abertura de PR), o **GitLab** irá buscar por qualquer um dos **Runners** que estão configurados no projeto e disponíveis, e irá utilizá-lo para interpretar o arquivo **gitlab-ci.yml** e executá-lo.
+
+Um Runner possui uma série de atributos, que são definidos em sua configuração, sendo os principais deles:
+
+### Descrição
+Uma descrição simples do Runner, indicando informações gerais como qual a máquina em que ele está rodando, qual o sistema operacional, e qual a sua finalidade, para fins de documentação.
+
+### Tags
+Um runner pode ter uma série de tags, que são identificadores extras do runner, e podem ser referenciados no **gitlab-ci.yml** para especificar quais runners devem rodar certos jobs.
+
+Para exemplificar, digamos que o desenvolvedor tenha um Runner instalado em uma máquina linux, e outro instalado em uma máquina windows.<br>
+Ele poderia indetificar estes runners com as task `linux` e `windows`, respectivamente.<br>
+E então, no **gitlab-ci.yml**, poderia especificar qual runner usar nos jobs desta forma:
+
+```yml
+test on linux:
+  tags:
+    - linux
+  stage: test
+  script:
+    - test application...
+test on windows:
+  tags:
+    - windows
+  stage: test
+  script:
+    - test application...
+```
+
+O valor `tags` do job fará com que o **GitLab** busque um Runner que tenha aquela tag específica para lidar com aquele job.
+
+Caso não tenha nenhum Runner disponível com a tag, o job falhará.
+
+### Executor
+
+Os executores são a parte principal dos Runners, eles definirão de que maneira as pipelines serão executadas.
+
+Cada Runner possui apenas um executor, e o gitlab-ci possui uma série de [executores possíveis](https://docs.gitlab.com/runner/executors/), mas existem dois executores principais básicos:
+
+#### Shell
+O executor **shell** vai rodar os comandos dos jobs da pipeline na própria máquina aonde o Runner está instalado.
+
+Este executor é preferido quando o Runner está instalado na mesma máquina aonde o servidor será lançado.
+
+Digamos, por exemplo, que temos um job que sobe um servidor de testes.<br>
+Poderíamos instalar um Runner na própria máquina deste servidor, e no **gitlab-ci.yml** colocar toda a lógica para subí-lo.
+
+Como o executor **shell** roda os comandos na própria máquina, ao final da pipeline, o servidor estará rodando!
+
+> :warning: **AVISO:** A grande maioria dos nossos Runners específicos do gitlab-ci são instalados nas máquinas de testes do laboratório, que ficam na SeTIC<br>
+Por isso, visto que este executor fará comandos diretamente na máquina, este executor só poderá ser utilizado com a autorização e monitoramento do administrador do laboratório!
+
+#### Docker
+O executor **docker** vai rodar os comandos dos jobs da pipeline em um **contâiner docker**.
+
+A imagem que o Runner utilizará deverá ser especificada no próprio arquivo **gitlab-ci.yml**, no valor `image`, <br>
+este valor poderá ser colocado tanto na raiz do arquivo, para definir qual a imagem a ser utilizada para toda a pipeline, ou dentro de um job, para definir qual imagem aquele job específico deverá utilizar.<br>
+Ex.:
+```yml
+image: python
+
+stages:
+  - test
+
+test on ruby image:
+  image: ruby
+  stage: test
+  script:
+    - test application...
+```
+
+O Runner do gitlab irá pegar o valor especificado, e buscá-lo no **docker-hub**.<br>
+O [docker-hub](https://www.google.com/search?client=safari&rls=en&q=docker+hub&ie=UTF-8&oe=UTF-8) é um repositório para guardar imagens docker de todos os tipos, e é tido como o local padrão para persistência e busca de imagens públicas e privadas.
+
+Este executor é o mais indicado na maioria dos casos, visto que da liberdade ao desenvolvedor de usar quaisquer tecnologias que preferir, mas ele tem um porém:<br>
+Após a pipeline acabar, o contêiner docker será completamente apagado. Ou seja, qualquer ação que foi feita nele será removida completamente.
+
+Isso faz com que esse executor seja dificilmente utilizado em scripts de deploy, ou em situações aonde a persistência dos comandos executados seja importante.
\ No newline at end of file