Alojamento de GitLab Runner, numa máquina que é sua
Um runner autogerido em Praga ou na Covilhã com o disco todo só para ele, de modo que a cache de camadas do Docker ainda lá está na segunda pipeline do dia e a fatura não se mexe quando a compilação se mexe.
Para quem é
Uma equipa que compra minutos de computação
A suite de testes cresceu, a pipeline ficou mais longa e a fatura subiu - e a única alavanca que o plano oferece é comprar mais exatamente dos mesmos minutos.
Uma pipeline que quer a mesma máquina duas vezes
Cada job arranca com o disco vazio. A imagem base é descarregada outra vez, as dependências são obtidas outra vez, e enviar a cache demora mais do que o passo que ela devia poupar.
Um repositório sujeito a uma regra de residência
O código, os artefactos e as chaves de deploy passam todos pelo runner, e "uma frota partilhada, algures" é a resposta que o seu auditor continua a rodear a vermelho.
O que um runner autogerido lhe devolve
- Uma cache de camadas Docker quente em NVMe local, para que a segunda pipeline do dia comece onde a primeira acabou em vez de partir de um disco vazio.
- Qualquer executor que queira - docker, shell, docker-autoscaler, instance ou kubernetes - escolhido por runner e não atribuído por um plano.
- A sua própria concorrência, definida como um número no config.toml em vez de comprada como o escalão seguinte.
- Modo privilegiado quando precisa mesmo de Docker-in-Docker, algo que nenhuma frota partilhada alguma vez lhe dará.
- Um IPv4 de saída estático do AS204057, para que um destino de deploy, um espelho de pacotes ou a firewall de uma base de dados possa autorizar o runner pelo endereço.
- O que a compilação realmente precisa no host: uma toolchain antiga, um SDK licenciado, ou um conjunto de fixtures que ninguém quer descarregar uma vez por job.
Dimensionado pelo que a pipeline faz de facto
O GitLab não publica requisitos de hardware para o runner em si, e não é um descuido: o processo do runner é pequeno e a compilação não é. O número que interessa é o job. Parta do job mais pesado que corre hoje, multiplique pela concorrência que quer e seja generoso com o disco - a cache de camadas e o espaço de trabalho é o que o enche, e um disco cheio faz falhar uma pipeline de uma forma que parece um teste partido. Uma coisa que um host mensual fixo não faz é desaparecer numa semana calma: os minutos alojados não custam nada quando ninguém faz push, e isto custa o mesmo. Compensa a partir do ponto em que a pipeline corre quase todos os dias.
Como instalar o GitLab Runner num host novo
Debian ou Ubuntu, a partir de um servidor limpo, pela ordem que o GitLab documenta. Tudo o que se segue é a sequência deles, não a nossa.
-
Adicionar o repositório oficial de pacotes
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" -o script.deb.sh less script.deb.sh sudo bash script.deb.shO GitLab distribui o repositório como um script de instalação e pede que o leia antes de o correr, e é por isso que as instruções deles o descarregam primeiro em vez de o passarem diretamente a uma shell.
-
Instalar o runner
sudo apt install gitlab-runnerO pacote cria um utilizador de sistema gitlab-runner cuja pasta pessoal é criada vazia, sem ficheiros de esqueleto. Para fixar uma versão, instale gitlab-runner e gitlab-runner-helper-images juntos na mesma versão - desde a 17.7.1 andam aos pares, e nomear apenas um falha com um erro de dependências.
-
Instalar o Docker, se os jobs correrem em contentores
sudo apt install docker.io sudo systemctl enable --now dockerO executor docker fala com um Docker Engine local pela API v1.25, portanto o daemon tem de estar no próprio host do runner. O pacote da distribuição chega para começar; o repositório do próprio Docker traz as versões mais recentes se alguma compilação precisar delas.
-
Registar o runner
sudo gitlab-runner register \ --non-interactive \ --url "https://gitlab.com/" \ --token "$RUNNER_TOKEN" \ --executor "docker" \ --docker-image alpine:latest \ --docker-pull-policy "if-not-present" \ --description "docker-runner"Crie primeiro o runner no GitLab, em Settings, depois CI/CD, depois Runners, e ele devolve um token de autenticação que começa por glrt- e que vai em --token. As etiquetas do job e a opção de jobs sem etiqueta definem-se nesse mesmo formulário: com tokens de autenticação pertencem ao runner, não ao comando register. O fluxo anterior com --registration-token está obsoleto e previsto para remoção no GitLab 20.0.
-
Definir a concorrência e arrancar
sudo sed -i "s/^concurrent = .*/concurrent = 4/" /etc/gitlab-runner/config.toml sudo gitlab-runner restart sudo gitlab-runner statusO config.toml fica em /etc/gitlab-runner quando o runner corre como root. concurrent é um teto sobre todos os runners registados neste host, não uma definição por runner, e cada runner pode ter por baixo um limite próprio mais pequeno.
-
Prová-lo com um job
stages: [test] smoke: stage: test tags: [docker-runner] script: - cat /etc/os-release - echo "built on $CI_RUNNER_DESCRIPTION"Faça commit disso como .gitlab-ci.yml, faça push, e o job deve aterrar no seu host em poucos segundos. Se ficar em fila, as etiquetas não correspondem às que definiu na interface, ou o runner está bloqueado noutro projeto.
Verificado na documentação oficial em 2026-08-15 — ler a fonte
O que não somos
- Não somos o GitLab. O GitLab, o GitLab CI/CD e o GitLab Runner são deles, e nada nesta página tem o aval deles. O que vendemos é a máquina onde um runner corre.
- Esta página não é sobre alojar o próprio GitLab. Uma instância GitLab autogerida é uma caixa maior e outra conversa - pergunte e dimensionamos uma, mas não é o que está aqui orçamentado.
- Não escrevemos o seu .gitlab-ci.yml. A pipeline é sua; o host, a rede e o endereço são nossos.
- O runner não é gerido por si a não ser que peça. Instala-o você, ou acrescenta o nosso serviço de administração e mantemo-lo atualizado, registado e vigiado.
- A sua subscrição do GitLab continua a ser do GitLab. Um runner autogerido não consome os minutos de computação deles, que é o objetivo, mas também não substitui as licenças de utilizador.
As partes que as equipas descobrem tarde
- O fluxo do token de registo está de saída. Um runner criado na interface devolve um token de autenticação glrt- que o gitlab-runner register aceita como --token, e --registration-token está previsto para remoção no GitLab 20.0.
- As etiquetas foram com ele. Com um token de autenticação, as etiquetas do job, a opção sem etiqueta e o bloqueio pertencem ao objeto runner que criou na interface, portanto as opções que antes as definiam na linha de comandos já não decidem nada.
- Fixar uma versão significa fixar dois pacotes. Desde a 17.7.1, uma versão explícita do gitlab-runner exige também gitlab-runner-helper-images na mesma versão, ou o apt recusa a instalação.
- check_interval está por omissão em 3 segundos. Num host com muitos runners registados isso é imenso sondeio; suba-o antes de culpar a rede.
- O Docker-in-Docker exige modo privilegiado, o que na prática dá root do host ao job. Se a pipeline só constrói imagens, um construtor sem root como o Kaniko ou o Buildah é a troca mais barata.
- Os artefactos e as caches continuam a viajar para o GitLab a não ser que aponte a cache para o seu próprio bucket compatível com S3. Num runner que mudou para a UE de propósito, esse costuma ser o último salto que falta mudar.
Minutos de CI alojados contra um runner seu
| Minutos de CI alojados pelo fornecedor | Um runner na DCXV | |
|---|---|---|
| O que paga | Cada minuto de cada job, enquanto o projeto existir | Um host mensal fixo, faça a pipeline o que fizer nesse mês |
| Uma compilação que fica mais lenta | Custa mais em cada mês que continue lenta | Não custa mais nada - a máquina já está paga |
| Cache de camadas Docker | Fria em cada job a não ser que a envie e a descarregue você mesmo | Quente em NVMe local, entre jobs e entre dias |
| Concorrência | Um escalão de plano que se sobe | Um número que define no seu próprio ficheiro de configuração |
| Onde aterra o checkout | Uma frota partilhada, muitas vezes numa região que não consegue fixar | Uma máquina em Praga ou na Covilhã, sob contrato cipriota |
| Endereço de saída | Uma gama partilhada enorme que nada consegue autorizar | Um IPv4 estático do AS204057, seu para autorizar |
| O que a máquina pode conter | O que a imagem do runner por acaso traga | Qualquer toolchain, licença ou conjunto de fixtures que instale uma vez |
Como isto arranca no seu host
Diga-nos o que faz a pipeline
O job mais pesado que corre hoje, quantos quer em simultâneo, e se constrói imagens de contentor. Isso chega para dimensionar um host sem adivinhar.
Entregamos-lhe a máquina
Praga ou Covilhã, acesso root e um IPv4 estático, em menos de dez minutos. Traga a sua própria imagem se o runner já vier lá dentro.
Siga o passo a passo desta página
É a sequência do fabricante, tirada da documentação atual e não de um artigo de blogue, e demora poucos minutos num host limpo.
Faça um snapshot e acrescente o segundo
Faça um snapshot assim que a primeira pipeline estiver verde, para que a máquina seguinte seja um restauro e não uma reconstrução. Um conjunto cresce acrescentando hosts, não tornando um enorme.
Porquê escolher-nos
- Instalações certificadas Tier III, SLA da instalação de 99,982 %
- Rede própria, AS204057, IPv4 e IPv6
- Suporte 24/7/365 com cerca de 10 minutos de resposta média
- Empresa cipriota, jurisdição da UE, conforme o RGPD desde 2007
FAQ
- Qual é a diferença entre um runner partilhado e um autogerido?
Um runner partilhado é a máquina do GitLab e paga pelos minutos que ela dedica ao seu job. Um runner autogerido é a sua máquina: instala nela o gitlab-runner, regista-a no seu projeto, grupo ou instância, e não consome minutos de computação nenhuns. Os namespaces do plano gratuito do GitLab recebem 400 minutos de computação por mês, e uma pipeline movimentada gasta-os em dias
- Como instalo e registo o GitLab Runner?
Adicione o repositório apt deles a partir do script de instalação em packages.gitlab.com, instale o pacote gitlab-runner e depois corra gitlab-runner register em modo não interativo com o token de autenticação que o GitLab lhe dá quando cria o runner na interface. A sequência completa com os comandos exatos está nesta página, tirada da documentação deles e não de um artigo de blogue
- Ainda se regista um runner com o token de registo?
Não, e é esta a mudança que estraga a maioria dos guias antigos. Crie primeiro o runner na interface do GitLab e ela devolve um token de autenticação que começa por glrt-, que o gitlab-runner register aceita como --token. O antigo fluxo com --registration-token está obsoleto e previsto para remoção no GitLab 20.0. As etiquetas do job, a opção sem etiqueta e o bloqueio pertencem agora ao objeto runner que criou na interface, não ao comando register
- De que tamanho de servidor precisa um GitLab Runner?
O GitLab não publica requisitos de hardware para o runner em si, porque o processo do runner é pequeno e a sua compilação não é. Dimensione pelo job mais pesado multiplicado pela concorrência que quer. Na prática 4 vCPU, 8 GB e 120 GB de NVMe levam dois ou três jobs de cada vez; 8 vCPU, 16 GB e 240 GB levam seis a oito. Seja generoso com o disco - a cache de camadas Docker e o espaço de trabalho é o que o enche
- Preciso de Docker no host do runner?
Só se usar o executor docker, o que quase toda a gente faz. Ele fala com um Docker Engine local pela API v1.25, portanto o daemon tem de estar instalado no próprio host do runner. O executor shell não precisa de Docker nenhum, e os executores instance e docker-autoscaler criam máquinas noutro sítio
- Podem vários runners partilhar um host?
Sim, e é essa a forma normal. Registe tantos quantos quiser na mesma instalação; a definição concurrent em /etc/gitlab-runner/config.toml é um teto para todos eles, e cada runner pode ter por baixo um limite próprio mais pequeno. Atenção ao check_interval, que está por omissão em 3 segundos e passa a ser muito sondeio assim que um host leva uma dúzia de runners
Se precisar de assistência ou tiver perguntas adicionais, por favor contacte os gestores ou escreva para a equipa de suporte em support@dcxv.com
Pronto para começar?
Faturação mensal, sem taxa de instalação, sem fidelização